Ошибка запуска службы в Linux: диагностика и способы исправления

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

Ошибка service failed to start в Linux (чаще всего в системах на базе systemd) означает, что менеджер служб не смог успешно запустить фоновый процесс (демон). Это состояние отображается в выводе команды systemctl status как active (failed) или inactive (dead). Типичный вывод:

● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2026-02-17 10:30:00 MSK; 1min 30s ago
  Process: 1234 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=1/FAILURE)

В данном примере служба ssh завершилась с кодом ошибки 1/FAILURE на этапе ExecStartPre (предварительный скрипт). Конкретная причина всегда указывается в логах, которые необходимо изучать.

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

Ошибка запуска службы может быть вызвана следующими распространёнными причинами:

1. Синтаксическая ошибка в конфигурационном файле службы (.service). Неправильные параметры, отсутствие разделов, опечатки.
2. Отсутствие или недоступность исполняемого файла/скрипта, указанного в ExecStart или ExecStartPre. Файл может быть удалён, перемещён или иметь неверные права.
3. Недостаточно прав для запуска. Служба может требовать привилегий (RootDirectory=, CapabilityBoundingSet=), или пользователь, от которого она запускается (User=), не существует/не имеет доступа.
4. Конфликт ресурсов. Служба пытается занять уже используемый сетевой порт, файл, сокет или другой системный ресурс.
5. Невыполненные зависимости. Указанные в Requires= или After= службы не запущены или завершились с ошибкой.
6. Ошибка в самом приложении. Программа, которую запускает служба, падает сразу после старта из-за неправильных параметров, повреждённых конфигов, отсутствия библиотек.
7. Проблемы с сессией или окружением. Служба запускается в чистом окружении systemd, отсутствуют переменные, которые есть в пользовательской сессии.

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

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

Получите детальные логи службы, которые покажут точную причину сбоя.

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

   journalctl -u имя_службы -b
   

3. Ищите строки с Failed, Error, permission denied, No such file or directory, Address already in use. Часто последние 10-20 строк лога содержат ключевую информацию.

Пример вывода для failing-службы:

Feb 17 10:30:01 host systemd[1]: Starting My App Service...
Feb 17 10:30:01 host myapp[1234]: Error: Cannot open config file /etc/myapp/config.yaml: No such file or directory
Feb 17 10:30:01 host systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
Feb 17 10:30:01 host systemd[1]: myapp.service: Failed with result 'exit-code'.

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

Убедитесь, что конфиг службы синтаксически корректен и пути верны.

1. Просмотрите текущую конфигурацию:

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

2. Проверьте синтаксис файла (если вы его редактировали). Для systemd нет встроенного валидатора, но можно проверить, загружается ли он:

   systemctl daemon-reload
   

   Если команда завершится без ошибок, синтаксис, скорее всего, верен.
3. Внимательно проверьте пути в директивах:
   • ExecStart= — абсолютный путь к исполняемому файлу или скрипту.
   • WorkingDirectory= — рабочая директория (должна существовать).
   • ConfigFile= или аналогичные параметры вашего приложения — указывают ли они на существующие файлы?

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

Удостоверьтесь, что бинарник/скрипт, который должна запустить служба, существует и доступен.

1. Найдите путь из ExecStart в конфиге.
2. Проверьте существование файла:

   ls -la /полный/путь/к/исполняемому_файлу
   

3. Проверьте права:
   • Файл должен иметь биты выполнения (x) для пользователя/группы, от которой запускается служба (по умолчанию — root).
   • Пример правильных прав: -rwxr-xr-x или -rwx--x--x.
   • Если служба запускается от отдельного пользователя (директива User=), убедитесь, что у этого пользователя есть права на выполнение файла.

Способ 4: Диагностика зависимостей и конфликтов

Убедитесь, что все необходимые службы запущены, и нет конфликтов ресурсов.

1. Просмотрите зависимости в конфиге (Requires=, After=, Wants=). Для каждой зависимой службы выполните:

   systemctl status имя_зависимой_службы
   

   Она должна быть в состоянии active (running).
2. Если служба использует сетевой порт, проверьте, не занят ли он:

   sudo ss -tulpn | grep :номер_порта
   

   Если порт уже занят другой службой, измените порт в конфиге вашей службы или остановите конфликтующий процесс.
3. Проверьте, не пытается ли служба дважды занять один и тот же ресурс (например, сокет в /run/).

Способ 5: Запуск вручную для диагностики

Запустите команду, указанную в ExecStart, вручную от того же пользователя, что и служба. Это покажет ошибки напрямую в терминале.

1. Определите пользователя (User= в конфиге, если нет — по умолчанию root).
2. Если служба запускается от не-root пользователя, переключитесь на него:

   sudo -u имя_пользователя -i
   

3. Выполните команду из ExecStart вручную, добавив ключи отладки, если нужно (например, --verbose).
4. Ошибка, которая в логах systemd может быть сжата, при ручном запуске часто выводится подробно.

Способ 6: Пересоздание юнитов и очистка состояния

Если служба была удалена/перемещена, или state systemd "застрял".

1. Удалите и пересоздайте символические ссылки на юнит:

   sudo systemctl daemon-reload
   sudo systemctl reset-failed имя_службы  # сбрасывает состояние failed
   

2. Попробуйте запустить снова:

   sudo systemctl start имя_службы
   

3. Для служб, которые были полностью удалены, убедитесь, что нет "зомби"-файлов в /etc/systemd/system/ или /lib/systemd/system/. Удалите старые файлы и повторите daemon-reload.

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

• Всегда используйте systemctl daemon-reload после ручного редактирования файлов служб в /etc/systemd/system/ или /lib/systemd/system/.
• Проверяйте конфигурационные файлы приложений, на которые ссылается служба (например, nginx -t для Nginx, postgresql -t для PostgreSQL).
• Не запускайте службы от root без необходимости. Указывайте конкретного пользователя/группу в User= и Group=. Это уменьшает риски безопасности и проблемы с правами.
• Следите за обновлениями системы. Обновления пакетов могут изменять конфигурационные файлы служб или исполняемые файлы. После обновления проверяйте статус критичных служб.
• Используйте systemctl status и journalctl как первые команды при любом сбое — они дают 80% информации о проблеме.