De acordo com a documentação do kernel , /proc/sys/file-max
é o número máximo, total e global de descritores de arquivos que o kernel irá alocar antes de asfixiar. Este é o limite do kernel, não do usuário atual. Então você pode abrir o 590432, desde que esteja sozinho em um sistema ocioso (modo de usuário único, sem daemons em execução).
Observe que a documentação está desatualizada: o arquivo foi proc/sys/fs/file-max
por um longo tempo. Obrigado a Martin Jambon por apontar isso.
A diferença entre os limites de hardware e software é respondida aqui, em SE . Você pode aumentar ou diminuir um limite suave como um usuário comum, desde que você 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 de hardware e software. O esquema de limite duplo é usado para impor políticas do sistema, mas também permite que usuários comuns definam limites temporários para si mesmos e, posteriormente, os alterem.
Observe que, se você tentar diminuir um limite máximo abaixo do limite flexível (e não for o superusuário), receberá EINVAL
de volta (Argumento inválido).
Assim, no seu caso particular, ulimit
(que é o mesmo que ulimit -Sf
) diz que você não tem um limite flexível no tamanho dos arquivos escritos pelo shell e seus subprocessos . (provavelmente é uma boa ideia na maioria dos casos)
Sua outra chamada, ulimit -Hn
, informa sobre o -n
limit (número máximo de descritores de arquivos abertos), não o -f
limit, e é por isso que o limite virtual parece maior que o limite rígido. Se você inserir ulimit -Hf
, também receberá "ilimitado".