De acordo com a documentação do kernel , /proc/sys/file-max
é o número máximo total total de descritores de arquivo que o kernel alocará antes de ser bloqueado. Este é o limite do kernel, não o usuário atual. Assim, você pode abrir o 590432, desde que esteja sozinho em um sistema inativo (modo de usuário único, sem daemons em execução).
Observe que a documentação está desatualizada: o arquivo está proc/sys/fs/file-max
há muito tempo. Obrigado a Martin Jambon por apontar isso.
A diferença entre os limites suave e rígido é respondida aqui, no SE . Você pode aumentar ou diminuir um limite flexível como um usuário comum, desde que não ultrapasse o limite máximo. Você também pode diminuir um limite rígido (mas não pode aumentá-lo novamente para esse processo). Como superusuário, você pode aumentar e diminuir os limites rígido e flexível. O esquema de limite duplo é usado para impor políticas de sistema, mas também permite que usuários comuns definam limites temporários para eles mesmos e depois os alterem.
Observe que, se você tentar reduzir um limite rígido abaixo do limite flexível (e você não for o superusuário), EINVAL
retornará (Argumento inválido).
Portanto, no seu caso particular, ulimit
(que é o mesmo que ulimit -Sf
) diz que você não tem um limite flexível para o tamanho dos arquivos gravados pelo shell e seus subprocessos . (essa é provavelmente uma boa ideia na maioria dos casos)
Sua outra invocação, ulimit -Hn
relata o -n
limite (número máximo de descritores de arquivos abertos), não o -f
limite, e é por isso que o limite flexível parece mais alto que o limite rígido. Se você entrar, ulimit -Hf
você também terá 'ilimitado'.
/proc/sys/fs/file-max
.