Failed with result 'watchdog' — причины и решение

Что это значит

Механизм работает только с программами, которые его поддерживают: они вызывают sd_notify с WATCHDOG=1 не реже половины заданного срока. Включить WatchdogSec= для программы, которая так не умеет, значит обеспечить себе регулярные перезапуски на ровном месте.

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

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

Программа подвисла или сильно замедлилась

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

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

Параметр включили «для надёжности», а отметки никто не посылает. Служба будет перезапускаться строго по расписанию срока, что легко принять за сбой в самой программе.

Диагностика

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

История срабатываний: ровный интервал говорит о неподдержке, случайный — о настоящих подвисаниях.

journalctl -u myapp.service --no-pager | grep -i watchdog | tail -10

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

systemctl show myapp.service -p WatchdogSec -p WatchdogTimestamp -p NRestarts

Решение

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

1. Программа подвисла или сильно замедлилась

Почему происходит: Это тот случай, для которого сторожевой таймер и придуман: служба жива, но не работает — например заблокирована на обращении к базе или в бесконечном цикле.

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

Посмотрите, чем занята служба, и её загрузку до момента перезапуска.

journalctl -u myapp.service -n 50 --no-pager | grep -i watchdog
systemctl show myapp.service -p WatchdogSec -p WatchdogTimestamp

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

2. Срок слишком короткий для этой службы

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

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

Сравните срок с временем обработки самой долгой задачи.

systemctl show myapp.service -p WatchdogSec
journalctl -u myapp.service --no-pager | grep -iE "watchdog|took"

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

3. Программа не поддерживает сторожевой таймер

Почему происходит: Параметр включили «для надёжности», а отметки никто не посылает. Служба будет перезапускаться строго по расписанию срока, что легко принять за сбой в самой программе.

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

Проверьте регулярность перезапусков: ровный интервал — явный признак.

journalctl -u myapp.service --no-pager | grep -i "watchdog timeout" | tail -5
systemctl show myapp.service -p Type -p NotifyAccess

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

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

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

× myapp.service - My application
     Active: failed (Result: watchdog) since Mon 2026-09-15 20:30:44 MSK; 10s ago
   Main PID: 21200 (code=killed, signal=ABRT)

systemd[1]: myapp.service: Watchdog timeout (limit 30s)!
systemd[1]: myapp.service: Killing process 21200 (myapp) with signal SIGABRT.
systemd[1]: myapp.service: Failed with result 'watchdog'.

Сигнал ABRT здесь послан нарочно: так systemd получает дамп подвисшего процесса. Трассировка из дампа обычно показывает, на чём именно служба заблокировалась.

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

Failed with result 'timeout' Состояние timeout: служба не уложилась в отведённое время при запуске, остановке или перезагрузке настроек.
signal=ABRT (status=6/ABRT) в systemd Процесс службы завершён сигналом ABRT: программа сама прервала работу после внутренней проверки. Где искать причину.
Failed with result 'core-dump' Состояние core-dump: процесс службы аварийно завершился и сохранил дамп памяти. Как открыть дамп и прочитать трассировку.
Failed with result 'exec-condition' и condition failed Состояния exec-condition и condition failed: запуск не состоялся, потому что условие не выполнено. Это не сбой, а задуманное поведение.
Failed with result 'exit-code' Состояние exit-code: служба завершилась с ненулевым кодом. Что это сообщение значит и где искать настоящую причину.
Failed with result 'oom-kill' Состояние oom-kill: процесс службы убит из-за нехватки памяти. Как понять, упёрлись в предел службы или в память машины.
Failed with result 'protocol' Состояние protocol: служба нарушила договор со systemd. Обычно Type=notify без уведомления или Type=dbus без имени на шине.
Failed with result 'resources' Состояние resources: systemd не смог выделить ресурсы для запуска службы. Чем отличается от кодов 200-й группы и что проверять.

Источники

systemd.service(5)
WatchdogSec=, WatchdogSignal= и значение watchdog в таблице Result. официальная документация, systemd 255
сверено 15 сентября 2026
sd_notify(3)
Отметки WATCHDOG=1 со стороны программы. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено включением WatchdogSec=30 у службы без поддержки отметок: перезапуск ровно каждые 30 секунд. собственная проверка, systemd 255
сверено 15 сентября 2026