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

signal=XCPU и signal=XFSZ в systemd

Эти два сигнала посылает ядро, когда процесс вышел за жёсткие пределы ресурсов, заданные в unit-файле: XCPU — превышено процессорное время из LimitCPU=, XFSZ — попытка превысить размер файла из LimitFSIZE=. Оба случая означают, что предел задан теснее реальных потребностей службы.

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

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

  1. Превышен предел процессорного времени

    LimitCPU= ограничивает суммарное процессорное время процесса, а не его долю. Для постоянно работающей службы такой предел рано или поздно исчерпается — и она будет умирать раз в сутки или раз в неделю с аккуратной регулярностью.

  2. Превышен предел размера файла

    LimitFSIZE= запрещает создавать файлы больше указанного размера. Служба, ведущая собственный журнал или базу, упирается в него при росте файла.

  3. Пределы унаследованы из шаблона unit-файла

    Ограничения переносят из чужих примеров, не сопоставляя с потребностями своей службы. Особенно часто так попадает LimitCPU=.

Диагностика

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

Пределы и фактический расход процессорного времени.

systemctl show myapp.service | grep -E "^Limit(CPU|FSIZE)|CPUUsage"

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

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

Решение

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

1. Превышен предел процессорного времени
Почему происходит
LimitCPU= ограничивает суммарное процессорное время процесса, а не его долю. Для постоянно работающей службы такой предел рано или поздно исчерпается — и она будет умирать раз в сутки или раз в неделю с аккуратной регулярностью.
Как проверить
Посмотрите предел и потреблённое время. 
systemctl show myapp.service -p LimitCPU -p CPUUsageNSec
Как исправить
Для длительно работающих служб LimitCPU= обычно не нужен: уберите его, а долю процессора ограничивайте через CPUQuota=, которая не копит расход. 
CPUQuota=80%
2. Превышен предел размера файла
Почему происходит
LimitFSIZE= запрещает создавать файлы больше указанного размера. Служба, ведущая собственный журнал или базу, упирается в него при росте файла.
Как проверить
Посмотрите предел и размеры файлов службы. 
systemctl show myapp.service -p LimitFSIZE
sudo du -ah /var/lib/myapp | sort -h | tail -5
Как исправить
Поднимите предел или настройте ротацию файлов. Предел размера файла удобен как страховка от бесконтрольного роста, но его значение должно быть с запасом.
3. Пределы унаследованы из шаблона unit-файла
Почему происходит
Ограничения переносят из чужих примеров, не сопоставляя с потребностями своей службы. Особенно часто так попадает LimitCPU=.
Как проверить
Посмотрите все пределы службы разом. 
systemctl show myapp.service | grep ^Limit
Как исправить
Оставьте только те пределы, которые вы можете обосновать числом. Остальные уберите: непонятный предел опаснее отсутствующего.

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

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

× worker.service - Background worker
     Active: failed (Result: signal) since Mon 2026-09-15 18:00:12 MSK; 5s ago
   Main PID: 18900 (code=killed, signal=XCPU)

systemd[1]: worker.service: Main process exited, code=killed, status=24/XCPU
systemd[1]: worker.service: Failed with result 'signal'.

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

  • status=205/LIMITS в systemd Код 205/LIMITS: systemd не смог применить ограничения ресурсов из Limit*=. Обычно значение недопустимо или превышает жёсткий предел.
  • Failed with result 'signal' Состояние signal: процесс службы завершён сигналом без сохранения дампа. Как узнать, каким сигналом и от кого.
  • No space left on device в журнале службы Нет места на устройстве: разбор по свободным блокам, по inode, по журналу systemd и по удалённым, но открытым файлам.
  • status=204/MEMORY в systemd Код 204/MEMORY: systemd не смог выделить память при подготовке запуска службы. Что проверять на машине и в unit-файле.
  • status=207/SIGNAL_MASK в systemd Код 207/SIGNAL_MASK: systemd не смог установить маску сигналов для нового процесса. Редкий код, признак проблем в окружении.
  • 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)
    LimitCPU= и LimitFSIZE=: жёсткие пределы и последствия их превышения.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • systemd.resource-control(5)
    CPUQuota= как правильная замена ограничению процессорного времени.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено на unit с LimitCPU=10 и LimitFSIZE=1M.     собственная проверка, systemd 255
    сверено 15 сентября 2026