The fs.file-max
sysctl shows how many file handles can be allocated system-wide, while ulimit
resource limits are per-process (or per-UID). The former is described in 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.
The 1024 files rlimit is not explicitly set anywhere; it's hardcoded into the kernel as the default value for pid 1, at 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 }, \
...
}
which references INR_OPEN_CUR
and INR_OPEN_MAX
from 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 */
Other processes simply inherit the limit from init
(or whatever is pid 1).
Why does /proc/1/limits
on Debian report 1024 as both soft and hard nfile limit? I don't know: neither the sysvinit sources nor Debian kernel patches change it. It could be the initramfs scripts, maybe. (I run Arch, which has the 1024/4096 default.)