O fs.file-max
sysctl mostra quantas alças de arquivos podem ser alocadas em todo o sistema , enquanto ulimit
de limites de recursos são por processo (ou per-process UID). O primeiro é descrito em Documentation/sysctl/fs.txt:90
:
file-max & file-nr: The value in file-max denotes the maximum number of file- handles that the Linux kernel will allocate. When you get lots of error messages about running out of file handles, you might want to increase this limit.
Os 1024 arquivos rlimit não são explicitamente definidos em qualquer lugar; ele é codificado no kernel como o valor padrão para o pid 1, em include/asm-generic/resource.h:81
:
/* * boot-time rlimit defaults for the init task: */ #define INIT_RLIMITS \ { \ ... [RLIMIT_NOFILE] = { INR_OPEN_CUR, INR_OPEN_MAX }, \ ... }
que faz referência a INR_OPEN_CUR
e INR_OPEN_MAX
de include/linux/fs.h:26
:
#define INR_OPEN_CUR 1024 /* Initial setting for nfile rlimits */ #define INR_OPEN_MAX 4096 /* Hard limit for nfile rlimits */
Outros processos simplesmente herdam o limite de init
(ou seja o que for pid 1).
Por que o /proc/1/limits
no Debian relata 1024 como um limite de arquivo mole e hard ? Eu não sei: nem os fontes sysvinit nem os patches do kernel do Debian mudam isso. Pode ser os scripts initramfs, talvez. (Eu corro Arch, que tem o padrão 1024/4096).