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

Failed with result 'timeout'

Состояние timeout значит, что systemd прекратил ждать. Ждать он может запуска (TimeoutStartSec=), остановки (TimeoutStopSec=) или готовности от Type=notify. Первым делом надо понять, какое именно ожидание истекло — дальше разбор совсем разный.

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

Строка в журнале это уточняет: «start operation timed out» — не уложился запуск, «stop operation timed out» — остановка, «State 'stop-sigterm' timed out» — программа не отреагировала на сигнал завершения.

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

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

  1. Type=notify, а программа не сообщает о готовности

    При этом типе systemd ждёт вызова sd_notify с READY=1. Программа, которая так не умеет, будет работать, но запуск всё равно закончится таймаутом, после чего её убьют.

  2. Запуск действительно медленный

    Базы данных с большим объёмом, службы с прогревом кеша и восстановлением журналов стартуют минутами. Значение по умолчанию (90 секунд) им мало.

  3. Программа не реагирует на сигнал завершения

    При остановке systemd посылает TERM и ждёт TimeoutStopSec=. Программа, игнорирующая сигнал или подвисшая на записи данных, добивается KILL, а результат помечается таймаутом.

  4. Служба ждёт чего-то внешнего

    Ожидание сети, монтирования, ответа базы или недоступного сервера имён легко съедает весь таймаут. Запуск при этом не «медленный», а заблокированный.

Диагностика

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

Строка с таймаутом называет операцию: start, stop или состояние вроде stop-sigterm.

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

Все таймауты службы и её тип в одном выводе.

systemctl show myapp.service -p Type -p TimeoutStartSec -p TimeoutStopSec -p WatchdogSec

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

systemd-analyze blame | head -15

Решение

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

1. Type=notify, а программа не сообщает о готовности
Почему происходит
При этом типе systemd ждёт вызова sd_notify с READY=1. Программа, которая так не умеет, будет работать, но запуск всё равно закончится таймаутом, после чего её убьют.
Как проверить
Посмотрите тип службы и умеет ли программа отчитываться.
systemctl show myapp.service -p Type -p NotifyAccess -p TimeoutStartSec
journalctl -u myapp.service -n 30 --no-pager | grep -i "timed out"
Как исправить
Смените тип на simple или exec, если программа не поддерживает уведомления. Для служб на systemd-библиотеке проверьте, что NotifyAccess= позволяет отчитываться нужному процессу.
Type=exec
2. Запуск действительно медленный
Почему происходит
Базы данных с большим объёмом, службы с прогревом кеша и восстановлением журналов стартуют минутами. Значение по умолчанию (90 секунд) им мало.
Как проверить
Посмотрите значение таймаута и сколько занимает запуск в норме.
systemctl show myapp.service -p TimeoutStartSec
systemd-analyze blame | head -10
Как исправить
Увеличьте TimeoutStartSec= до реального времени запуска с запасом. Для служб, где время непредсказуемо, допустимо infinity, но тогда нужен внешний контроль.
3. Программа не реагирует на сигнал завершения
Почему происходит
При остановке systemd посылает TERM и ждёт TimeoutStopSec=. Программа, игнорирующая сигнал или подвисшая на записи данных, добивается KILL, а результат помечается таймаутом.
Как проверить
Поищите в журнале строку про таймаут остановки.
journalctl -u myapp.service -n 40 --no-pager | grep -iE "stop|timed out|SIGKILL"
Как исправить
Увеличьте TimeoutStopSec= до времени корректного завершения и убедитесь, что программа обрабатывает TERM. Если ей нужен другой сигнал, укажите KillSignal=.
4. Служба ждёт чего-то внешнего
Почему происходит
Ожидание сети, монтирования, ответа базы или недоступного сервера имён легко съедает весь таймаут. Запуск при этом не «медленный», а заблокированный.
Как проверить
Посмотрите, чем занята служба в момент ожидания.
systemctl list-jobs
sudo ss -tnp | grep myapp
Как исправить
Уберите блокирующую зависимость: добавьте After=network-online.target там, где нужна сеть, или RequiresMountsFor= для каталога на отдельном разделе.

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

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

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

systemd[1]: myapp.service: start operation timed out. Terminating.
systemd[1]: myapp.service: Failed with result 'timeout'.
systemd[1]: Failed to start myapp.service - My application.

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

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

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

Источники

  • systemd.service(5)
    TimeoutStartSec=, TimeoutStopSec= и значение timeout в таблице Result.
    официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено на Type=notify без sd_notify и на программе, игнорирующей TERM.
    собственная проверка, systemd 255
    сверено 15 сентября 2026