Observe que o limite está no valor dos descritores de arquivo recém-criados (como em open()
/ socket()
/ pipe()
e assim por diante nunca retornará um número maior que n-1
se o limite tiver sido definido como n
e dup2(1, n or n+1...)
falharão), não no número de arquivos atualmente abertos ou descritores de arquivos.
Com efeito, a partir do instante em que o limite for definido como n
, isso evitará que o processo abra mais de n
arquivos, mas se os descritores de arquivo acima de n
já tiverem sido criados antes do limite ser reduzido então o processo pode ter mais de n
arquivos abertos.
Exemplo:
$ limit descriptors 10000 # ulimit -n 10000 in bash
$ perl -MBSD::Resource -MPOSIX -e '
dup2(1,$_) for (2000..4000);
setrlimit(RLIMIT_NOFILE, 1024, 1024);
exec zsh'
zsh$ ls /proc/$$/fd | wc -w
2009
zsh$ readlink /proc/$$/fd/3000
/dev/pts/1
zsh$ repeat 100 exec {a}>&1
zsh$ ls /proc/$$/fd | wc -w
2109
zsh$ grep files /proc/$$/limits
Max open files 1024 1024 files
No momento em que zsh
foi executado, o processo tinha fds de 2000 a 4000 abertos para /dev/pts/1
. No entanto, o limite de fd foi 1024.
Já tinha 2009 fds, mas ainda conseguiu criar mais 100.