Failed with result 'timeout'
Состояние timeout значит, что systemd прекратил ждать. Ждать он может запуска (TimeoutStartSec=), остановки (TimeoutStopSec=) или готовности от Type=notify. Первым делом надо понять, какое именно ожидание истекло — дальше разбор совсем разный.
Что это значит
Строка в журнале это уточняет: «start operation timed out» — не уложился запуск, «stop operation timed out» — остановка, «State 'stop-sigterm' timed out» — программа не отреагировала на сигнал завершения.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Type=notify, а программа не сообщает о готовностиПри этом типе systemd ждёт вызова sd_notify с READY=1. Программа, которая так не умеет, будет работать, но запуск всё равно закончится таймаутом, после чего её убьют.
-
Запуск действительно медленный
Базы данных с большим объёмом, службы с прогревом кеша и восстановлением журналов стартуют минутами. Значение по умолчанию (90 секунд) им мало.
-
Программа не реагирует на сигнал завершения
При остановке systemd посылает TERM и ждёт
TimeoutStopSec=. Программа, игнорирующая сигнал или подвисшая на записи данных, добивается KILL, а результат помечается таймаутом. -
Служба ждёт чего-то внешнего
Ожидание сети, монтирования, ответа базы или недоступного сервера имён легко съедает весь таймаут. Запуск при этом не «медленный», а заблокированный.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Строка с таймаутом называет операцию: 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Решение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
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
- Почему происходит
- Базы данных с большим объёмом, службы с прогревом кеша и восстановлением журналов стартуют минутами. Значение по умолчанию (90 секунд) им мало.
- Как проверить
-
Посмотрите значение таймаута и сколько занимает запуск в норме.
systemctl show myapp.service -p TimeoutStartSec systemd-analyze blame | head -10
- Как исправить
-
Увеличьте
TimeoutStartSec=до реального времени запуска с запасом. Для служб, где время непредсказуемо, допустимоinfinity, но тогда нужен внешний контроль.
- Почему происходит
- При остановке systemd посылает TERM и ждёт
TimeoutStopSec=. Программа, игнорирующая сигнал или подвисшая на записи данных, добивается KILL, а результат помечается таймаутом.
- Как проверить
-
Поищите в журнале строку про таймаут остановки.
journalctl -u myapp.service -n 40 --no-pager | grep -iE "stop|timed out|SIGKILL"
- Как исправить
-
Увеличьте
TimeoutStopSec=до времени корректного завершения и убедитесь, что программа обрабатывает TERM. Если ей нужен другой сигнал, укажитеKillSignal=.
- Почему происходит
- Ожидание сети, монтирования, ответа базы или недоступного сервера имён легко съедает весь таймаут. Запуск при этом не «медленный», а заблокированный.
- Как проверить
-
Посмотрите, чем занята служба в момент ожидания.
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 (Ubuntu 24.04)
Воспроизведено на Type=notify без sd_notify и на программе, игнорирующей TERM.