fs.file-max
sysctl показывает, сколько файловых дескрипторов может быть выделено для всей системы, тогда как ограничения ресурсов ulimit
относятся к каждому процессу (или к каждому UID). Первый описан в 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.
Rlimit из 1024 файлов явно нигде не установлен; он жестко запрограммирован в ядре как значение по умолчанию для pid 1, в 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 }, \
...
}
который ссылается на INR_OPEN_CUR
и INR_OPEN_MAX
из 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 */
Другие процессы просто наследуют ограничение от init
(или что-то еще, pid 1).
Почему /proc/1/limits
limit в отчете Debian 1024 является как мягким, так и жестким ограничением nfile? Я не знаю: ни исходники sysvinit, ни патчи ядра Debian не меняют его. Это могут быть сценарии initramfs. (Я запускаю Arch, который имеет значение по умолчанию 1024/4096.)