SystemdDoctor
мешает работе частое сигналы остановка таймауты

signal=TERM (status=15/TERM) в systemd

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

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

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

  1. Обычная остановка или перезапуск по команде

    Это штатное поведение: systemctl stop и systemctl restart посылают TERM. Запись в журнале появится вместе со строкой «Stopping…».

  2. Служба остановлена вместе с зависимостью

    При PartOf= или BindsTo= остановка одной службы тянет за собой другие. Обновление пакета тоже перезапускает связанные службы.

  3. Не уложилась в таймаут запуска

    Если служба не сообщила о готовности за TimeoutStartSec=, systemd прекращает запуск и посылает TERM. В журнале рядом будет строка про таймаут.

  4. Сработал сторожевой таймер

    При заданном WatchdogSec= служба обязана регулярно отчитываться. Пропустив срок, она получает сигнал и обычно перезапускается.

Диагностика

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

Контекст важнее сигнала: рядом будет «Stopping», «Timed out» или «Watchdog timeout».

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

Уточняет, был ли TERM следствием таймаута или сторожевого таймера.

systemctl show myapp.service -p Result -p TimeoutStartSec -p WatchdogSec

Кто и когда вызывал systemctl: помогает найти источник неожиданной остановки.

journalctl _COMM=systemctl --since "1 hour ago" --no-pager | tail -20

Решение

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

1. Обычная остановка или перезапуск по команде
Почему происходит
Это штатное поведение: systemctl stop и systemctl restart посылают TERM. Запись в журнале появится вместе со строкой «Stopping…».
Как проверить
Посмотрите, была ли команда остановки. 
journalctl -u myapp.service -n 30 --no-pager | grep -iE "stopping|stopped|deactivat"
Как исправить
Ничего исправлять не нужно. Если остановка неожиданная, ищите, кто её вызвал: обновление пакета, сценарий обслуживания, перезагрузка зависимости.
2. Служба остановлена вместе с зависимостью
Почему происходит
При PartOf= или BindsTo= остановка одной службы тянет за собой другие. Обновление пакета тоже перезапускает связанные службы.
Как проверить
Посмотрите обратные зависимости. 
systemctl list-dependencies --reverse myapp.service --no-pager
Как исправить
Если связь нежелательна, поправьте зависимости: Wants= вместо Requires=, отсутствие PartOf=.
3. Не уложилась в таймаут запуска
Почему происходит
Если служба не сообщила о готовности за TimeoutStartSec=, systemd прекращает запуск и посылает TERM. В журнале рядом будет строка про таймаут.
Как проверить
Поищите строку про таймаут и посмотрите значение параметра. 
journalctl -u myapp.service -n 40 --no-pager | grep -i timeout
systemctl show myapp.service -p TimeoutStartSec -p Type
Как исправить
Для медленно стартующих служб поднимите TimeoutStartSec=. Если Type=notify, убедитесь, что программа действительно умеет сообщать о готовности — иначе таймаут будет всегда.
4. Сработал сторожевой таймер
Почему происходит
При заданном WatchdogSec= служба обязана регулярно отчитываться. Пропустив срок, она получает сигнал и обычно перезапускается.
Как проверить
Посмотрите параметр и записи про watchdog. 
systemctl show myapp.service -p WatchdogSec
journalctl -u myapp.service --no-pager | grep -i watchdog
Как исправить
Либо программа должна отчитываться чаще, либо срок стоит увеличить. Отключать сторожевой таймер, чтобы скрыть подвисания, не стоит.

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

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

× myapp.service - My application
     Active: failed (Result: timeout) since Mon 2026-09-15 14:02:44 MSK; 5s ago
   Main PID: 13200 (code=killed, signal=TERM)

systemd[1]: myapp.service: start operation timed out. Terminating.
systemd[1]: myapp.service: Main process exited, code=killed, status=15/TERM
systemd[1]: myapp.service: Failed with result 'timeout'.

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

  • Failed with result 'timeout' Состояние timeout: служба не уложилась в отведённое время при запуске, остановке или перезагрузке настроек.
  • signal=KILL (status=9/KILL) в systemd Процесс службы убит сигналом KILL. Кто мог его послать: OOM-killer, таймаут остановки systemd, администратор.
  • Failed with result 'watchdog' Состояние watchdog: служба не прислала отметку сторожевому таймеру за отведённое время. Настройка WatchdogSec и разбор.
  • Job for … failed because a timeout was exceeded Задание на запуск прервано по таймауту. Как отличить медленный старт от заблокированного и правильно настроить TimeoutStartSec.
  • A start job is running: загрузка висит на одной службе Загрузка останавливается с обратным отсчётом: служба не укладывается в таймаут. Как найти виновника и не ждать.
  • nginx 504 Gateway Time-out: upstream timed out nginx не дождался ответа приложения. Разбор таймаутов proxy_read_timeout и fastcgi_read_timeout, поиск медленных мест.
  • signal=INT и signal=QUIT в systemd Процесс службы завершён сигналом INT или QUIT. Кто их посылает службам и почему это обычно не systemd.
  • signal=SEGV (status=11/SEGV) в systemd Процесс службы завершён сигналом SEGV: обращение к недопустимой памяти. Как собрать дамп и что смотреть.

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

Источники

  • systemd.kill(5)
    Порядок посылки сигналов при остановке службы.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • systemd.service(5)
    TimeoutStartSec=, WatchdogSec= и их последствия.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено на Type=notify без вызова sd_notify и на обычной остановке командой.     собственная проверка, systemd 255
    сверено 15 сентября 2026