systemd-failed-to-start: причины и методы исправления ошибки запуска

Что означает ошибка systemd-failed-to-start

Ошибка Failed to start — это общий статус, который systemd присваивает службе (юниту), когда процесс её запуска завершился с ненулевым кодом возврата, превысил заданный таймаут или столкнулся с критической проблемой при инициализации. В выводе команды systemctl status она выглядит как:

● some-service.service - Some Service Description
   Loaded: loaded (/etc/systemd/system/some-service.service; enabled; vendor preset: enabled)
   Active: **failed** (Result: exit-code) since Thu 2026-02-15 10:30:00 MSK; 1min 30s ago
  Process: 1234 ExecStart=/usr/bin/some-service (code=exited, status=1/FAILURE)

Ключевые флаги: Active: failed и Result: exit-code (или timeout). Эта ошибка блокирует работу сервиса и может помешать загрузке системы, если юнит критичен.

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

Причины носят конкретный технический характер:

1. Некорректный конфигурационный файл юнита (.service). Ошибки в секциях [Service] (неверный путь в ExecStart, ExecStartPre), [Install] или синтаксис.
2. Недостаток прав доступа. Служба пытается прочитать/записать в каталог, к которому у неё нет прав (например, /var/log/app/), или запускается от неправильного пользователя (User=).
3. Конфликт ресурсов. Порт уже занят другим процессом, недостаточно памяти (OOM Killer), не хватает дескрипторов файлов.
4. Зависимости не выполнены. Указанные в Requires= или After= службы не запустились или завершились с ошибкой.
5. Повреждение бинарного файла или зависимостей приложения. Файл, указанный в ExecStart, отсутствует, неисправен или не может загрузить нужные библиотеки.
6. Превышение таймаута. Приложение долго не отвечает на запросы инициализации, и systemd убивает его по истечении TimeoutStartSec= (по умолчанию 90 сек).

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

Способ 1: Анализ логов службы через journalctl

Это первый и самый важный шаг. Логи systemd содержат детальный вывод программы.

1. Узнайте точное имя службы (например, nginx.service).
2. Выполните команду для просмотра логов за текущую загрузку:

   journalctl -u nginx.service -b --no-pager
   

3. Внимательно изучите последние 20-30 строк. Ищите слова Failed, Error, (code=exited, status=...), Permission denied, No such file or directory.
4. Если лог обширный, фильтруйте по уровню ошибки:

   journalctl -u nginx.service -b -p err --no-pager
   

💡 Совет: Добавьте флаг -e для открытия лога сразу в конце, или -f для отслеживания в реальном времени при перезапуске службы.

Способ 2: Проверка и исправление конфигурационного файла

Ошибки в юнит-файле — частая причина.

1. Найдите файл службы:

   systemctl status nginx.service | grep Loaded
   # Вывод: Loaded: loaded (/etc/systemd/system/nginx.service; enabled; ...)
   

2. Проверьте синтаксис:

   sudo systemd-analyze verify /etc/systemd/system/nginx.service
   

   Команда покажет строку с ошибкой, если она есть (например, "Invalid command 'Execstar', not part of a unit configuration").
3. Откройте файл в редакторе (sudo nano /etc/systemd/system/nginx.service) и проверьте:
   • Пути в ExecStart, ExecStartPre: существуют ли они? (which some-binary или ls -la /path/to/file)
   • Права на исполняемый файл (ls -l /usr/bin/some-binary — должен быть -rwxr-xr-x).
   • Секцию [Service]: правильно ли указаны User= и Group=? Существует ли такой пользователь/группа?
   • Директиву WorkingDirectory=: существует ли каталог?
4. После исправлений выполните:

   sudo systemctl daemon-reload
   

Способ 3: Проверка зависимостей и конфликтов портов/ресурсов

1. Проверьте, не занят ли порт (если служба сетевая):

   sudo ss -tulpn | grep :80  # Замените 80 на порт вашей службы
   

   Если порт занят другим процессом, найдите и остановите его или измените порт в конфиге службы.
2. Проверьте, все ли требуемые службы работают:

   systemctl list-dependencies nginx.service --reverse
   

   Это покажет, какие службы зависят от nginx. Убедитесь, что они в состоянии active (running).
3. Проверьте наличие свободных ресурсов:

   free -h        # Память
   df -h /var     # Дисковое пространство (особенно для логов)
   ulimit -n      # Лимит дескрипторов файлов (может быть мал)
   

   Недостаток любого ресурса может привести к падению службы при старте.

Способ 4: Восстановление из пакета или ручная переустановка

Если служба установлена из пакетного менеджера (apt, dnf, yum), её конфигурация могла быть повреждена.

1. Debian/Ubuntu:

   sudo apt update
   sudo apt install --reinstall nginx  # Замените nginx на имя пакета
   

   Это восстановит файлы из /usr/share/doc/nginx/examples/ или оригинальные конфиги в /etc/.
2. RHEL/CentOS/Fedora:

   sudo dnf reinstall nginx
   

3. После переустановки не перезаписывайте свои кастомные настройки в /etc/nginx/nginx.conf (если они были), если пакетный менеджер спросит. Сравните старый и новый файлы конфигурации юнита (/lib/systemd/system/nginx.service vs /etc/systemd/system/nginx.service). Часто правильнее скопировать свои правки в новый оригинальный файл, а не использовать старый повреждённый.

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

• Всегда проверяйте синтаксис конфигурационных файлов службы и самого приложения (например, nginx -t) перед перезагрузкой systemd.
• Используйте systemctl daemon-reload после любого изменения файла юнита в /etc/systemd/system/ или /lib/systemd/system/.
• Настраивайте разумные таймауты (TimeoutStartSec=, TimeoutStopSec=) для долгих служб, чтобы избежать ложных срабатываний.
• Следите за правами на каталоги, с которыми работает служба (/var/log/, /var/lib/, /run/). Рекомендуется создавать отдельного пользователя/группу для каждой службы.
• Периодически проверяйте логи на предмет предупреждений (journalctl -u <служба>.service -p warning) до того, как они превратятся в ошибки.

Способ N: Откат к предыдущей рабочей конфигурации (если используется Git)

Если конфигурационные файлы службы находятся под контролем версий (что хорошая практика):

1. Определите, когда служба последний раз работала:

   sudo journalctl -u nginx.service -b --no-pager | grep -i "started\|failed"
   

2. Найдите коммит, после которого начались сбои:

   cd /etc/systemd/system/
   git log --oneline -p -- nginx.service
   

3. Временно верните предыдущую версию файла:

   sudo git checkout <хэш_коммита> -- nginx.service
   sudo systemctl daemon-reload
   sudo systemctl restart nginx.service
   

4. Если это помогло, проанализируйте, какие именно изменения сломали службу, и внесите их более аккуратно.

Способ N+1: Запуск службы вручную для отладки

Иногда systemd "затыкает" вывод ошибки. Запустите исполняемый файл напрямую от того же пользователя, под которым работает служба.

1. Узнайте пользователя из юнит-файла (User=) или из лога.
2. Выполните:

   sudo -u <пользователь> /usr/bin/some-service --verbose
   # или, если служба запускает скрипт:
   sudo -u <пользователь> /bin/bash -x /path/to/startup-script.sh
   

   Флаги --verbose или -x (для bash) дадут подробный вывод. Часто ошибка становится очевидной при прямом запуске.