Too many open files: проверяем лимит работающего процесса
Ошибка может относиться к одному процессу, хотя свободная память и место на диске ещё есть. Инструкция для Ubuntu 24.04 показывает, где прочитать действующий лимит и как отличить его от настроек текущего терминала.
В этой статье
Приложение перестало открывать файлы или принимать соединения и сообщает Too many open files. Свободные гигабайты на диске здесь могут ни при чём. В Linux файловые дескрипторы используются не только для обычных файлов, но и для сокетов, каналов и других объектов. Сначала нужно проверить процесс, который получил ошибку, а не увеличивать все ограничения на сервере.
Применимость: Ubuntu 24.04 LTS, утилита prlimit из util-linux 2.39.3, GNU coreutils 9.4 и доступная файловая система proc. Проверено по документации 26 сентября 2026 года. Все команды ниже читают состояние. Изменение лимитов, конфигурации и перезапуск служб в эту инструкцию не входят. Для чтения чужого процесса могут потребоваться разрешённые администратором права; отказ доступа не следует обходить изменением защиты.
Найдите процесс, к которому относится ошибка
Идентификатор берут из сообщения приложения, журнала или проверенного списка процессов. У сервиса могут быть главный процесс и несколько рабочих: ошибка одного рабочего не означает, что ограничение исчерпал главный. После перезапуска идентификаторы меняются, а старый номер со временем может получить другая программа.
Во всех командах PID — заглушка. Вместо неё подставьте проверенный числовой идентификатор нужного процесса, без угловых скобок. Выполняйте команды в той среде, где виден этот процесс. Номер внутри контейнера и номер на хосте могут различаться. Если процесс уже завершился, его текущее состояние прочитать нельзя; остаются журналы и ранее собранные показатели.
prlimit --pid PID --nofile
Здесь у параметра --nofile нет знака равенства и числового значения: команда показывает ограничение, не устанавливая новое. Не копируйте вместо неё примеры с --nofile=... из инструкции по настройке — они меняют состояние.
В результате найдите строку NOFILE и столбцы SOFT и HARD. Мягкий предел действует сейчас, жёсткий задаёт потолок для его обычного повышения самим непривилегированным процессом. Строго говоря, предел ограничивает номер нового дескриптора: он на единицу больше максимально допустимого номера. Поэтому число открытых объектов полезно для диагностики, но не является точным универсальным счётчиком «оставшихся мест».
Те же сведения можно прочитать в списке ограничений процесса:
cat /proc/PID/limits
Нужна строка Max open files. Это действующее состояние, а не только намерение из конфигурационного файла. Значение, прочитанное командой ulimit -n в вашем терминале, относится к этой оболочке и само по себе ничего не доказывает о давно работающем серверном процессе.
Посмотрите, какие объекты остаются открытыми
ls -l /proc/PID/fd
Каталог содержит ссылки с числовыми именами. Обычный путь указывает на файл, запись вида socket:[...] — на сокет, pipe:[...] — на канал. Встречаются и анонимные объекты ядра. Это не список файлов, занимающих место на диске: сотни сетевых соединений тоже используют дескрипторы.
Для просмотра только номеров без расшифровки целей используйте:
ls -1 /proc/PID/fd
Это снимок меняющегося состояния. Пока команда читает каталог, программа может открывать и закрывать объекты. Сообщение об исчезнувшей ссылке не обязательно означает повреждение системы. При отказе доступа или отсутствии каталога нельзя трактовать пустой результат как ноль открытых дескрипторов.
При большом количестве объектов вывод может оказаться длинным и создать дополнительную работу. Не запускайте частые обходы всех процессов на загруженном сервере. Для первого разбора достаточно выбранного процесса и нескольких разнесённых во времени наблюдений. Перед передачей вывода уберите чувствительные имена файлов: они могут раскрывать структуру проекта или данные клиентов.
Сопоставьте ошибку, предел и момент наблюдения
В условном примере мягкий предел равен 1024, а в момент сбоя почти все доступные номера заняты. Это повод искать, какие операции удерживают дескрипторы: соединения с внешним сервисом, незакрытые файлы, растущий пул клиентов. Если после завершения нагрузки количество возвращается к обычному уровню, картина отличается от непрерывного роста при стабильной нагрузке.
Одного позднего снимка недостаточно. Ошибка могла возникнуть на кратком пике, после которого приложение закрыло часть объектов. И наоборот, большой текущий список без ошибок не доказывает утечку. Нужны время события, правильный процесс и динамика относительно его обычной работы.
Ошибка EMFILE связана с пределом дескрипторов процесса. ENFILE относится к системному пределу открытых файлов; это другой уровень диагностики. Текст приложения может скрывать исходный код ошибки, поэтому при возможности сохраните полное сообщение. Бездумное увеличение лимита одного процесса не является решением системной проблемы и может лишь отложить проявление утечки.
В тестовой среде Ubuntu 24.04.3 с util-linux 2.39.3 чтение через prlimit выполнено для отдельного дочернего процесса: получены оба предела 16384. Чтение его каталога proc в этой среде оказалось недоступно, поэтому полный сценарий просмотра дескрипторов на стенде не подтверждён. Команды чтения каталога сверены с документацией Linux и GNU coreutils; их результат на вашем сервере зависит в том числе от пространства процессов и прав.
Для следующего этапа разбирательства сохраните время ошибки, идентификатор и роль процесса, действующие пределы и характер открытых объектов. Эти данные позволяют решить, нужен ли пересмотр нагрузки и пула соединений, исправление утечки или обоснованное изменение конфигурации. Повышать предел до выяснения причины эта инструкция не предлагает.
The application stopped opening files or accepting connections and reports Too many open files. Free gigabytes on the disk may have nothing to do with this. In Linux, file descriptors are used not only for regular files but also for sockets, channels, and other objects. First, check the process that received the error rather than increasing all limits on the server.
Applicability: Ubuntu 24.04 LTS, utility prlimit from util-linux 2.39.3, GNU coreutils 9.4, and the accessible file system proc. Verified via documentation on September 26, 2026. All commands below read the state. Changing limits, configuration, or restarting services is outside the scope of this instruction. Reading another process may require administrator-granted permissions; access denial should not be bypassed by modifying security settings.
Find the process associated with the error
Obtain the identifier from the application message, log, or a verified process list. A service may have a main process and several worker processes: an error in one worker does not mean the main process has exhausted its limit. After a restart, identifiers change, and the old number may eventually be assigned to a different program.
In all teams, PID is a placeholder. Replace it with a verified numeric identifier for the required process, without angle brackets. Run the commands in the environment where this process is visible. The process ID inside the container and the ID on the host may differ. If the process has already terminated, its current state cannot be read; only logs and previously collected metrics remain.
prlimit --pid PID --nofile
Here, the parameter --nofile has no equals sign or numeric value: the command displays the limit without setting a new one. Do not copy examples with --nofile=... from the configuration instructions instead, as they change the state.
As a result, find the line NOFILE and the columns SOFT and HARD. The soft limit is currently active, while the hard limit sets the ceiling for its normal increase by the unprivileged process itself. Strictly speaking, the limit restricts the number of the new descriptor: it is one greater than the maximum allowed number. Therefore, the count of open objects is useful for diagnostics but is not an exact universal counter of "remaining slots."
The same information can be read in the process limits list:
cat /proc/PID/limits
You need the string Max open files. This is the actual runtime state, not just an intention from a configuration file. The value read by the command ulimit -n in your terminal applies only to that shell and proves nothing about a long-running server process.
Check which objects remain open
ls -l /proc/PID/fd
The directory contains entries with numeric names. A standard path points to a file, an entry like socket:[...] points to a socket, and pipe:[...] points to a pipe. You may also encounter anonymous kernel objects. This is not a list of files consuming disk space: hundreds of network connections also use file descriptors.
To view only the numbers without decoding their purposes, use:
ls -1 /proc/PID/fd
This is a snapshot of a changing state. While the team reads the catalog, the program may open and close objects. A message about a missing link does not necessarily indicate system corruption. If access fails or the catalog is unavailable, do not interpret an empty result as zero open file descriptors.
With a large number of objects, the output can become lengthy and create extra work. Do not run frequent scans of all processes on a busy server. For an initial analysis, a selected process and a few observations spaced over time are sufficient. Before sharing the output, remove sensitive file names: they may reveal the project structure or client data.
Match the error, the limit, and the observation moment
In a conditional example, the soft limit is 1024, and at the moment of failure, almost all available numbers are in use. This is a reason to investigate which operations are holding the descriptors: connections to external services, unclosed files, or a growing client pool. If the count returns to normal after the load ends, the picture differs from continuous growth under stable load.
A single late snapshot is insufficient. The error could have occurred during a brief spike, after which the application closed some objects. Conversely, a large current list without errors does not prove a leak. You need the event time, the correct process, and the dynamics relative to its normal operation.
The error EMFILE relates to the process file descriptor limit. ENFILE refers to the system-wide limit on open files; this is a different diagnostic level. Application text may hide the original error code, so if possible, save the full message. Thoughtlessly increasing the limit for a single process is not a solution to a system problem and may only delay the manifestation of a leak.
In the Ubuntu 24.04.3 test environment with util-linux 2.39.3, reading via prlimit was performed for a separate child process: both limits of 16384 were retrieved. Reading its directory proc in this environment proved inaccessible, so the full descriptor viewing scenario on the test stand remains unconfirmed. Directory reading commands were cross-checked against Linux and GNU coreutils documentation; their result on your server depends, among other factors, on process space and permissions.
For the next stage of the investigation, save the error timestamp, process identifier, and process role, along with the active limits and the nature of the open objects. These data points help determine whether a load review and connection pool adjustment, a leak fix, or a justified configuration change is needed. This instruction does not recommend raising the limit before the cause is identified.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.