служба не работает ресурсы процессы cgroup

Too many tasks: упор в предел TasksMax

Сообщение о слишком большом числе задач или отказ вида «Resource temporarily unavailable» при создании процесса означают упор в TasksMax=. Предел считает процессы и потоки вместе и задаётся на трёх уровнях: у службы, у среза и в общих настройках systemd.

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

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

Предел службы слишком мал для её работы

Многопоточные серверы и службы с пулом рабочих процессов легко упираются в значение по умолчанию.
Упор в предел среза, а не службы

Срез (system.slice или свой) имеет собственный предел, и он ограничивает все службы внутри. Поднятие предела у службы тут не поможет.
Утечка процессов или потоков

Если число задач растёт монотонно, предел лишь обозначает момент отказа. Поднятие значения отложит сбой на несколько часов.
Общий предел systemd занижен

Значение DefaultTasksMax= в system.conf действует на все службы, у которых свой предел не задан.

Диагностика

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

Строка Tasks показывает текущее число и предел рядом.

systemctl status myapp.service --no-pager | grep -i tasks

Кто на машине создал больше всего задач.

systemd-cgtop -1 --order=tasks | head -12

Общесистемный предел числа процессов: при упоре в него отказывают все службы.

cat /proc/sys/kernel/pid_max

Решение

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

1. Предел службы слишком мал для её работы

Почему происходит: Многопоточные серверы и службы с пулом рабочих процессов легко упираются в значение по умолчанию.

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

Посмотрите предел и текущее число задач.

systemctl show myapp.service -p TasksMax -p TasksCurrent
systemctl status myapp.service --no-pager | grep -i tasks

Как исправить

Поднимите предел в переопределении unit-файла.

sudo systemctl edit myapp.service   # [Service]\nTasksMax=4096

2. Упор в предел среза, а не службы

Почему происходит: Срез (system.slice или свой) имеет собственный предел, и он ограничивает все службы внутри. Поднятие предела у службы тут не поможет.

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

Посмотрите пределы среза.

systemctl show system.slice -p TasksMax -p TasksCurrent
systemd-cgtop -1 --order=tasks | head

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

3. Утечка процессов или потоков

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

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

Посмотрите число задач в динамике.

PID=$(systemctl show -p MainPID --value myapp.service); ls /proc/$PID/task | wc -l
ps -L -p $PID | wc -l

Как исправить: Разбирайтесь с программой: обычно это незакрытые рабочие потоки или порождённые и не собранные дочерние процессы.

4. Общий предел systemd занижен

Почему происходит: Значение DefaultTasksMax= в system.conf действует на все службы, у которых свой предел не задан.

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

Посмотрите общее значение.

systemctl show -p DefaultTasksMax
grep -r DefaultTasksMax /etc/systemd/system.conf /etc/systemd/system.conf.d/ 2>/dev/null

Как исправить: Поднимите общее значение в /etc/systemd/system.conf.d/ и перезагрузите конфигурацию менеджера: systemctl daemon-reexec.

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

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

● myapp.service - My application
     Active: active (running) since Mon 2026-09-15 08:00:01 MSK; 5h ago
      Tasks: 512 (limit: 512)

myapp[1200]: error: failed to spawn worker: resource temporarily unavailable
systemd[1]: myapp.service: Trying to enqueue job myapp.service/restart/replace

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

Failed with result 'resources' Состояние resources: systemd не смог выделить ресурсы для запуска службы. Чем отличается от кодов 200-й группы и что проверять.
status=219/CGROUP в systemd Код 219/CGROUP: не удалось создать или настроить контрольную группу службы. Причины на уровне системы и контейнеров.
Too many open files в журнале службы Служба исчерпала лимит файловых дескрипторов. Как правильно поднять LimitNOFILE и когда дело в утечке.
Ограничение среза душит службу Предел у службы поднят, а упор остаётся: ограничение действует на уровне среза.
Служба не создаёт потоки: упор в предел Ошибка создания потока: исчерпан TasksMax или системный предел процессов. Как посчитать нужное значение.
Cannot allocate memory в журнале службы Не удалось выделить память: предел службы, память машины, настройка overcommit, исчерпанные области отображения.
Disk quota exceeded для службы Место на разделе есть, а запись отклоняется: исчерпана дисковая квота пользователя или группы.
Docker и kubelet: несовпадение драйвера cgroup Драйвер контрольных групп Docker не совпадает с systemd: предупреждения, нестабильная работа контейнеров, проблемы с kubelet.

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

Источники

systemd.resource-control(5)
TasksMax= и DefaultTasksMax=. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено на unit с TasksMax=1 и службой, порождающей рабочие процессы. собственная проверка, systemd 255
сверено 15 сентября 2026