Systemd Service Timeout: причины и 4 способа исправления

Что значит ошибка Systemd Service Timeout

Ошибка Failed to start <service_name>.service: Unit <service_name>.service entered the failed state. или Job for <service_name>.service timed out возникает, когда systemd не может запустить службу в течение времени, заданного параметром TimeoutStartSec (по умолчанию 90 секунд для простых служб). Systemd прерывает процесс запуска и помечает службу как failed.

Типичный вывод:

$ systemctl status nginx.service
● nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: failed (Result: timeout) since Thu 2026-02-17 10:30:00 MSK; 1min 30s ago
  Process: 1234 ExecStart=/usr/sbin/nginx -g daemon off; (code=exited, status=0/SUCCESS)
 Main PID: 1234 (code=exited, status=0/SUCCESS)

Feb 17 10:28:30 host systemd[1]: Starting The nginx HTTP and reverse proxy server...
Feb 17 10:30:00 host systemd[1]: nginx.service: Start operation timed out. Terminating.
Feb 17 10:30:00 host systemd[1]: nginx.service: Failed with result 'timeout'.
Feb 17 10:30:00 host systemd[1]: Failed to start The nginx HTTP and reverse proxy server.

Причины возникновения

1. Долгий запуск приложения. Служба физически требует больше времени, чем TimeoutStartSec (например, инициализация большого кэша, подключение к удалённой БД, обработка большого объёма данных при старте).
2. Неправильный Type= в юните. Для Type=simple systemd считает службу запущенной сразу после завершения команды ExecStart. Если процесс демона не демонизируется (не делает fork), а продолжает работать в том же процессе, systemd будет ждать его завершения и в итоге таймаутит. Нужен Type=notify или Type=forking.
3. Блокировка на ресурсах. Служба ждёт недоступный ресурс: сетевой интерфейс не поднят, диск не смонтирован, порт занят другим процессом, недостаточно прав на доступ к файлу.
4. Ошибка в скрипте инициализации (pre-start). Команды в ExecStartPre= зависают или выполняются очень долго.
5. Конфликт с другим процессом. Порт, который хочет занять служба, уже используется, и она не может корректно завершить инициализацию.

Способы решения

Способ 1: Диагностика через журнал (journalctl)

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

1. Посмотрите полный лог службы за последние минуты:

   journalctl -u <service_name>.service --since "5 minutes ago" -e
   

   
   Ключ -e перемотит к концу файла. Ищите строки, предшествующие Timed out starting. Там может быть ошибка подключения, недостаток памяти, permission denied.
2. Если логи не очень информативны, запустите службу в режиме отладки вручную, чтобы увидеть вывод в консоль:

   # Остановите службу
   sudo systemctl stop <service_name>
   
   # Запустите команду ExecStart напрямую (найдите её через `systemctl cat <service_name>`)
   sudo -u <user> <путь_к_исполняемому_файлу> <аргументы>
   
   # ИЛИ для скриптов
   sudo bash -x /путь/к/скрипту/запуска.sh
   

   
   Флаг -x в bash покажет каждую выполненную команду, что поможет найти зависший шаг.

💡 Совет: Если служба пишет логи в отдельный файл (а не в journald), проверьте и его: sudo tail -f /var/log/<service_name>/<service_name>.log.

Способ 2: Временное увеличение таймаута

Чтобы понять, проблема именно в времени запуска или в зависании, временно увеличьте лимит.

1. Создайте переопределение (drop-in) для службы:

   sudo systemctl edit <service_name>
   

   
   Откроется редактор. Вставьте:

   [Service]
   TimeoutStartSec=300
   

   
   Сохраните и закройте (для nano — Ctrl+X, Y, Enter).
2. Перезагрузите конфигурацию systemd и перезапустите службу:

   sudo systemctl daemon-reload
   sudo systemctl restart <service_name>
   

3. Проверьте статус:

   systemctl status <service_name>
   

   
   Если служба запустилась с таймаутом 300 секунд — проблема в долгом старте. Нужно оптимизировать процесс инициализации (уменьшить объём данных, которые она обрабатывает при старте, добавить асинхронную загрузку) и вернуть разумный таймаут (например, 60s).

Способ 3: Исправление типа службы (Type=)

Частая ошибка — использование Type=simple для служб, которые не демонизируются (не делают fork). Systemd ждёт, пока процесс завершится, а тот продолжает работать, и в итоге срабатывает таймаут.

1. Проверьте текущий тип:

   systemctl show <service_name> -p Type
   

   
   или

   systemctl cat <service_name> | grep ^Type
   

2. Определите правильный тип:
   • Type=forking — классический демон, который делает fork и родительский процесс завершается. Проверьте, есть ли в логах Started после запуска.
   • Type=notify — служба уведомляет systemd о готовности через sd_notify(0). Требует поддержки в приложении (часто в современных сервисах на Go, Node.js). Указан в документации ПО.
   • Type=oneshot — для скриптов, которые должны завершиться до того, как служба считается активной. Не подходит для долгих фоновых процессов.
3. Измените тип в юните (через systemctl edit или напрямую в файле .service):

   [Service]
   Type=forking
   # или Type=notify
   

4. Перезагрузите и перезапустите.

Способ 4: Анализ зависимостей и скриптов pre-start

Служба может зависнуть на этапе ExecStartPre= или из-за невыполнения условий After=/Requires=.

1. Проверьте все команды, выполняемые ДО основного запуска:

   systemctl cat <service_name> | grep ExecStartPre
   

   
   Запустите каждую из этих команд вручную. Если какая-то зависнет (например, ожидание ответа от базы данных, проверка диска) — это и есть причина.
2. Проверьте порядок запуска и зависимости:

   systemctl list-dependencies <service_name>
   

   
   Убедитесь, что все службы из Requires= и After= уже активны (systemctl status <dependent_service>). Возможно, нужно изменить порядок или добавить Wants= вместо Requires=, если зависимость не критична.
3. Если проблема в ExecStartPre= (например, ожидание сети), можно:
   • Исправить сам скрипт, добавив таймаут (timeout 30s <command>).
   • Убрать тяжёлую проверку из ExecStartPre= и перенести её в основной процесс службы, который уже будет иметь свой таймаут.

Профилактика

1. Оптимизируйте старт приложения. Разделите тяжёлую инициализацию на асинхронную (загрузка кэша в фоне после старта) и синхронную (только критичные для работы шаги).
2. Правильно выбирайте Type=. Изучайте документацию вашего ПО. Для современных приложений часто требуется Type=notify.
3. Устанавливайте адекватный TimeoutStartSec. Для простых веб-серверов 30-60 секунд обычно достаточно. Для сложных приложений (Java, базы данных) может потребоваться 120-300 секунд. Указывайте явно в юните, а не полагайтесь на значение по умолчанию.
4. Используйте Restart=on-failure. Это не решит таймаут, но поможет службе автоматически перезапуститься после временного сбоя, не требующего вмешательства администратора.
5. Мониторьте логи. Настройте алерты на systemctl status с состоянием failed или на частые сообщения Timed out starting в journalctl.

Статья подготовлена экспертами FixPedia. Если вы столкнулись с другими ошибками systemd, посмотрите наши руководства по диагностике через journalctl или управлению службами systemctl. Для ошибок, связанных с зависанием системы, см. справку по systemd-analyze.