служба не работает ограничения ресурсы limitnofile

status=205/LIMITS в systemd

Код 205/LIMITS появляется, когда systemd не сумел выставить пределы ресурсов из параметров Limit*=. Причина в значении: оно либо записано в непонятном виде, либо больше того, что позволяет система, либо его нельзя повысить без нужной возможности процесса.

Вероятные причины

По порядку: сверху то, что встречается чаще.

Значение больше жёсткого системного предела

Повышать мягкий предел можно свободно, а жёсткий — только с возможностью CAP_SYS_RESOURCE. Если служба уже отказалась от возможностей через CapabilityBoundingSet= или работает в контейнере, повышение не пройдёт.
Значение записано в неразбираемом виде

Пределы принимают число, infinity или пару «мягкий:жёсткий». Записи вроде LimitNOFILE=65535: или LimitCORE=unlimited systemd не понимает: unlimited — это синтаксис оболочки, а не unit-файла.
Ограничение противоречит другому параметру

Например LimitNICE= в сочетании с Nice= вне разрешённого диапазона или LimitRTPRIO= при отсутствии права на политику реального времени.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

В строке «Failed at step LIMITS spawning» видна причина отказа: недопустимый аргумент или отказ в доступе.

journalctl -xeu myapp.service --no-pager -n 30

Все действующие пределы и набор возможностей рядом — так проще заметить противоречие.

systemctl show myapp.service | grep -E "^Limit|^Capability"

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Значение больше жёсткого системного предела

Почему происходит: Повышать мягкий предел можно свободно, а жёсткий — только с возможностью CAP_SYS_RESOURCE. Если служба уже отказалась от возможностей через CapabilityBoundingSet= или работает в контейнере, повышение не пройдёт.

Как проверить

Сравните запрошенное значение с жёстким пределом системы.

systemctl show myapp.service -p LimitNOFILE -p CapabilityBoundingSet
cat /proc/sys/fs/nr_open

Как исправить: Либо снизьте значение до допустимого, либо поднимите системный предел (fs.nr_open и настройки в /etc/security/limits.conf для входа пользователей), либо оставьте службе CAP_SYS_RESOURCE.

2. Значение записано в неразбираемом виде

Почему происходит: Пределы принимают число, infinity или пару «мягкий:жёсткий». Записи вроде LimitNOFILE=65535: или LimitCORE=unlimited systemd не понимает: unlimited — это синтаксис оболочки, а не unit-файла.

Как проверить

Посмотрите действующие значения всех пределов службы.

systemctl show myapp.service | grep ^Limit

Как исправить: Приведите значение к допустимому виду: LimitNOFILE=65535, LimitCORE=infinity, LimitNPROC=1024:2048.

3. Ограничение противоречит другому параметру

Почему происходит: Например LimitNICE= в сочетании с Nice= вне разрешённого диапазона или LimitRTPRIO= при отсутствии права на политику реального времени.

Как проверить

Соберите вместе связанные параметры и сверьте их между собой.

systemctl show myapp.service -p Nice -p LimitNICE -p CPUSchedulingPolicy -p LimitRTPRIO

Как исправить: Уберите лишнее ограничение либо согласуйте значения: приоритеты и пределы должны допускать друг друга.

Пример вывода

Запрошен предел дескрипторов выше системного максимума. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

× myapp.service - My application
     Active: failed (Result: exit-code) since Mon 2026-09-14 15:11:03 MSK; 1s ago
    Process: 10120 ExecStart=/usr/local/bin/myapp (code=exited, status=205/LIMITS)

systemd[10120]: myapp.service: Failed at step LIMITS spawning /usr/local/bin/myapp: Operation not permitted
systemd[1]: myapp.service: Main process exited, code=exited, status=205/LIMITS

Связанные ошибки

Too many open files в журнале службы Служба исчерпала лимит файловых дескрипторов. Как правильно поднять LimitNOFILE и когда дело в утечке.
status=202/FDS в systemd Код 202/FDS: systemd не смог закрыть лишние файловые дескрипторы или настроить переданные. Причины и проверка.
status=214/SETSCHEDULER в systemd Код 214/SETSCHEDULER: не удалось применить политику планирования процессора из CPUSchedulingPolicy=. Обычно из-за прав или диапазона приоритета.
signal=XCPU и signal=XFSZ в systemd Процесс службы убит из-за превышения предела процессорного времени (XCPU) или размера файла (XFSZ) из LimitCPU и LimitFSIZE.
status=204/MEMORY в systemd Код 204/MEMORY: systemd не смог выделить память при подготовке запуска службы. Что проверять на машине и в unit-файле.
Cannot allocate memory в журнале службы Не удалось выделить память: предел службы, память машины, настройка overcommit, исчерпанные области отображения.
Disk quota exceeded для службы Место на разделе есть, а запись отклоняется: исчерпана дисковая квота пользователя или группы.
Elasticsearch: max virtual memory areas vm.max_map_count is too low Elasticsearch отказывается стартовать из-за заниженного vm.max_map_count. Как поднять значение и закрепить его.

Где встречается чаще всего

Источники

systemd.exec(5)
205 EXIT_LIMITS: не удалось настроить пределы ресурсов, см. LimitCPU= и родственные параметры. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено на unit с LimitNOFILE выше fs.nr_open и с LimitCORE=unlimited. собственная проверка, systemd 255
сверено 15 сентября 2026