Перейти к содержанию

Почему служба не запускается: порядок диагностики

Если служба не стартует, первая задача — не «починить systemd», а определить реальную причину: неверную конфигурацию, отсутствие исполняемого файла, ошибку прав, диск, сеть, лимиты или несовместимость библиотеки.

Снимок проблемы

systemctl --failed --no-pager
systemctl status ИМЯ.service --no-pager --full
journalctl -b -u ИМЯ.service --no-pager -n 150
systemctl show ИМЯ.service -p Result -p ExecMainStatus -p NRestarts
systemctl cat ИМЯ.service

Замените ИМЯ.service на unit реально установленной службы. Убедитесь, что вы читаете журнал текущей загрузки (-b), а для воспроизведения исторического события при необходимости выбирайте прошлую загрузку с journalctl --list-boots.

Логика поиска

  1. Unit существует? systemctl list-unit-files | grep ....
  2. Запрещён ли запуск? systemctl is-enabled может показывать masked; при этом ручной запуск невозможен.
  3. Есть ли исполняемый файл? Изучите ExecStart через systemctl cat.
  4. Корректны ли права? Пользователь и группа unit должны иметь доступ к бинарному файлу, каталогу, сертификатам и данным.
  5. Есть ли свободное место? df -hT, df -i, findmnt.
  6. Есть ли сеть? ip route, resolvectl, iptables -S.
  7. Не вмешивается ли SELinux? Узнайте фактический режим (getenforce, если команда есть) и сообщения аудита.
  8. Работает ли зависимость? Используйте systemctl list-dependencies.

Чего делать не стоит

  • Сразу запускать сервис под root вместо специализированного пользователя.
  • Отключать iptables, SELinux и sysctl целиком.
  • Удалять каталог состояния приложения с накопленными данными.
  • Убирать Requires=, After= и Condition... без понимания последствий.
  • Постоянно перезапускать аварийную службу до заполнения диска логами.

После исправления

systemctl daemon-reload    # только если менялся unit/drop-in
systemctl restart ИМЯ.service
systemctl status ИМЯ.service --no-pager --full
journalctl -b -u ИМЯ.service --no-pager -n 80

restart прерывает действующие соединения. Если нужен бесшовный reload и unit его поддерживает, сначала проверьте CanReload, а затем используйте reload по документированной процедуре приложения.

Таблица характерных кодов

Код Что проверять
203/EXEC Путь к бинарному файлу, формат, исполняемые биты
200/CHDIR WorkingDirectory и его доступность
217/USER Учётная запись, NSS, права
216/GROUP Существование группы и её доступность
Result=timeout Причина зависания, readiness protocol, внешние зависимости
Result=exit-code stdout/stderr приложения, код ExecMainStatus

См. создание unit, журналы, ожидание сети.