служба не работает cgroup контейнеры ресурсы

status=219/CGROUP в systemd

Код 219/CGROUP значит, что systemd не смог подготовить контрольную группу для службы. Это происходит до запуска программы и почти всегда указывает на проблему уровнем выше unit-файла: ограничения контейнера, смешанная иерархия cgroup, упор в предел числа групп.

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

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

Служба запускается в контейнере без доступа к иерархии cgroup

Внутри контейнера каталог /sys/fs/cgroup может быть подключён только для чтения или обрезан. Создать группу в такой иерархии нельзя.
Смешанная или устаревшая иерархия cgroup

На системах, где часть контроллеров работает по первой версии, а часть по второй, отдельные настройки ресурсов в unit-файле применить не удаётся.
Упор в предел числа задач или групп

При исчерпании TasksMax= у родительского среза или системного предела pids новую группу создать не выйдет.

Диагностика

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

Показывает шаг CGROUP и причину от ядра.

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

Срез, в котором создаётся группа, и связанные ограничения.

systemctl show myapp.service -p Slice -p TasksMax -p Delegate

Текущее дерево контрольных групп: видно, куда службу пытались поместить.

systemd-cgls --no-pager | head -40

Решение

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

1. Служба запускается в контейнере без доступа к иерархии cgroup

Почему происходит: Внутри контейнера каталог /sys/fs/cgroup может быть подключён только для чтения или обрезан. Создать группу в такой иерархии нельзя.

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

Посмотрите тип окружения и права на иерархию.

systemd-detect-virt
mount | grep cgroup
ls -ld /sys/fs/cgroup

Как исправить: Дайте контейнеру доступ к записи в свою ветку иерархии (в Docker это --cgroupns=private и доступная /sys/fs/cgroup) либо запускайте службу вне контейнера.

2. Смешанная или устаревшая иерархия cgroup

Почему происходит: На системах, где часть контроллеров работает по первой версии, а часть по второй, отдельные настройки ресурсов в unit-файле применить не удаётся.

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

Определите версию иерархии.

stat -fc %T /sys/fs/cgroup
systemd-detect-virt --container

Как исправить: Переведите систему на единую иерархию второй версии параметром ядра systemd.unified_cgroup_hierarchy=1 либо уберите настройки ресурсов, которые не поддерживаются текущей иерархией.

3. Упор в предел числа задач или групп

Почему происходит: При исчерпании TasksMax= у родительского среза или системного предела pids новую группу создать не выйдет.

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

Посмотрите пределы среза и общую загрузку.

systemctl show system.slice -p TasksMax -p TasksCurrent
systemd-cgtop -1 --depth=1

Как исправить: Поднимите TasksMax= у среза или разберитесь с процессом, который расплодил задачи.

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

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

× myapp.service - My application
     Active: failed (Result: exit-code) since Mon 2026-09-14 20:33:02 MSK; 1s ago
    Process: 19010 ExecStart=/usr/local/bin/myapp (code=exited, status=219/CGROUP)

systemd[1]: myapp.service: Failed to create cgroup /system.slice/myapp.service: Read-only file system
systemd[1]: myapp.service: Main process exited, code=exited, status=219/CGROUP

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

status=204/MEMORY в systemd Код 204/MEMORY: systemd не смог выделить память при подготовке запуска службы. Что проверять на машине и в unit-файле.
Too many tasks: упор в предел TasksMax Служба не может создать новый процесс: достигнут предел TasksMax. Где он задан и как поднять правильно.
Cannot allocate memory в журнале службы Не удалось выделить память: предел службы, память машины, настройка overcommit, исчерпанные области отображения.
Disk quota exceeded для службы Место на разделе есть, а запись отклоняется: исчерпана дисковая квота пользователя или группы.
Docker и kubelet: несовпадение драйвера cgroup Драйвер контрольных групп Docker не совпадает с systemd: предупреждения, нестабильная работа контейнеров, проблемы с kubelet.
Elasticsearch: max virtual memory areas vm.max_map_count is too low Elasticsearch отказывается стартовать из-за заниженного vm.max_map_count. Как поднять значение и закрепить его.
Failed to connect to bus: подключение к шине недоступно Команды systemctl не работают: нет подключения к шине. Разбор для контейнеров, сеансов по ssh и служб пользователя.
Failed with result 'resources' Состояние resources: systemd не смог выделить ресурсы для запуска службы. Чем отличается от кодов 200-й группы и что проверять.

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

docker.service 7

Источники

systemd.exec(5)
219 EXIT_CGROUP: не удалось настроить контрольную группу службы. официальная документация, systemd 255
сверено 15 сентября 2026
systemd.resource-control(5)
Иерархия cgroup и настройки ресурсов unit. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено в контейнере с /sys/fs/cgroup только для чтения. собственная проверка, systemd 255
сверено 15 сентября 2026