Ошибка systemd: служба не запускается — причины и решение

Что означает ошибка "Failed to start" в systemd

Когда systemd не может запустить службу, выводится сообщение:

Job for имя_службы.service failed because the control process exited with error code.
See 'systemctl status имя_службы.service' and 'journalctl -xe' for details.

Это означает, что управляющий процесс службы завершился с ненулевым кодом возврата или был убит сигналом. Ошибка возникает на этапе Start (не Load), то есть конфигурационный файл загружен, но выполнение основной команды (ExecStart) не удалось.

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

1. Ошибка в конфигурационном файле службы (.service): неверный путь к исполняемому файлу, опечатки в параметрах (ExecStart, User, WorkingDirectory).
2. Отсутствие зависимых служб или файлов: служба указана в Requires или After, но зависимая служба не активна или конфиг не загружен.
3. Недостаточно прав: служба настроена на запуск от пользователя без необходимых прав доступа к файлам, сокетам или портам.
4. Проблема с самим приложением: ошибка в коде, отсутствие библиотек, неверные аргументы командной строки.
5. Конфликт ресурсов: порт уже занят другим процессом, недостаточно памяти или места на диске.
6. Таймаут запуска: служба не уложилась в TimeoutStartSec (по умолчанию 90 секунд).

Способ 1: Анализ статуса и логов (базовый)

Самый важный шаг — получить детали ошибки из systemd.

1. Проверьте статус службы:

   systemctl status имя_службы
   

   
   В выводе ищите строки Active: failed (result: exit-code) и Process: ... ExecStart=.... Код завершения (например, code=exited, status=1/FAILURE) даст подсказку.
2. Изучите логи службы:

   journalctl -u имя_службы -n 50 --no-pager
   

   
   Это покажет последние 50 строк логов. Ищите Failed или error. Для более широкого контекста:

   journalctl -xe --no-pager | grep имя_службы
   

3. Если статус показывает control process exited с кодом, попробуйте запустить команду из ExecStart вручную (без sudo, если служба от обычного пользователя):

   /путь/к/исполняемому_файлу [аргументы]
   

   
   Это часто выводит ошибку сразу (например, "Permission denied" или "No such file").

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

Конфигурационные ошибки — частая причина.

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

   systemctl status имя_службы | grep Loaded
   

   
   Пример вывода: Loaded: loaded (/etc/systemd/system/имя_службы.service; enabled; vendor preset: enabled). Путь указан в скобках.
2. Откройте файл в текстовом редакторе (например, sudo nano /etc/systemd/system/имя_службы.service) и проверьте:
   • ExecStart: абсолютный путь к исполняемому файлу, аргументы корректны.
   • WorkingDirectory: директория существует и доступна.
   • User/Group: пользователь существует и имеет права.
   • PermissionsStartOnly: если true, то только ExecStartPre запускается с правами root.
   • Restart: если on-failure, systemd попытается перезапустить, но это не решит корневую проблему.
3. После изменений перезагрузите конфигурацию systemd:

   sudo systemctl daemon-reload
   

4. Проверьте синтаксис конфига:

   systemd-analyze verify /etc/systemd/system/имя_службы.service
   

   
   Команда покажет ошибки парсинга.

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

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

1. Посмотрите зависимости:

   systemctl list-dependencies имя_службы
   

   
   Убедитесь, что все Requires и Wants службы активны (active). Если какая-то зависимая служба в состоянии failed, исправьте её сначала.
2. Проверьте, не занят ли порт (если служба сетевой):

   sudo ss -tulpn | grep :порт
   

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

   df -h /путь/к/рабочей_директории
   free -h
   

Способ 4: Отладка приложения напрямую

Если проблема в самом приложении, а не в systemd.

1. Запустите приложение вручную с теми же аргументами, что в ExecStart. Добавьте опции отладки, если есть (например, --verbose, --debug).
2. Проверьте наличие библиотек:

   ldd /путь/к/исполняемому_файлу
   

   Все пути должны вести к существующим файлам. Отсутствующие библиотеки нужно установить.
3. Если приложение требует окружение (переменные среды), убедитесь, что они заданы в Environment или EnvironmentFile в конфиге службы. Для теста экспортируйте переменные вручную перед запуском.

Способ 5: Пересоздание службы или обновление ПО

Если служба устарела или конфиг повреждён.

1. Для стандартных пакетов (установленных через apt, dnf): переустановите пакет.

   sudo apt reinstall имя_пакета   # Debian/Ubuntu
   sudo dnf reinstall имя_пакета   # Fedora/CentOS
   

   
   Это восстановит оригинальный файл службы в /lib/systemd/system/.
2. Если вы создавали службу вручную, проверьте права на файл:

   ls -l /etc/systemd/system/имя_службы.service
   

   
   Должно быть -rw-r--r-- и владелец root. После правок не забудьте daemon-reload.
3. Обновите systemd и перезагрузите систему (если подозреваете системную проблему):

   sudo apt update && sudo apt upgrade systemd   # Debian/Ubuntu
   sudo dnf upgrade systemd                     # Fedora/CentOS
   

   
   После обновления выполните sudo systemctl daemon-reexec.

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

• Всегда проверяйте конфиги перед загрузкой: используйте systemd-analyze verify.
• Тестируйте команду вручную перед добавлением в службу.
• Указывайте абсолютные пути в ExecStart, WorkingDirectory.
• Настройте корректные права на файлы, которые использует служба.
• Мониторьте логи с помощью journalctl -u имя_службы -f в реальном времени при тестовом запуске.
• Устанавливайте разумные таймауты (TimeoutStartSec, TimeoutStopSec) для долгих операций.
• Используйте Type=oneshot для скриптов, которые завершаются, а не демонов.