Служба systemd не запускается: короткий маршрут диагностики
С каких команд начать, если служба systemd перешла в failed, и как найти причину в конфигурации и журнале.
- Состояниеsystemctl status: результат запуска
- КонфигурацияКоманда, пользователь и рабочий каталог
- Журналjournalctl: ошибка и события перед ней
Служба перешла в failed. Повторный restart иногда помогает, но не объясняет, что произошло, а при постоянном сбое лишь добавляет одинаковые записи в журнал. Сначала посмотрим состояние, параметры запуска и первое сообщение об ошибке. Уже после исправления проверим и процесс, и само приложение.
Три команды для начала
systemctl status demo.service --no-pager -l
systemctl cat demo.service
journalctl -u demo.service --since today -n 100 --no-pagerПервая команда показывает состояние и краткую сводку. Вторая помогает увидеть основной unit и дополнительные настройки. Третья даёт события конкретной службы за понятный период. Если событий мало, проверьте загрузку системы и время инцидента, а не увеличивайте вывод до всего журнала сервера.
Сверяем окружение процесса
Сравните пользователя службы, рабочий каталог, путь к программе и расположение конфигурации. Команда, успешно выполненная из интерактивной оболочки, может зависеть от другого PATH, прав доступа или текущего каталога. Проверять нужно тот сценарий запуска, который описан unit-файлом.
В журнале сначала ищите первое осмысленное сообщение об ошибке. Последующие сообщения о повторных попытках часто являются следствием. Для журнала могут потребоваться дополнительные права; не изменяйте владельцев системных каталогов только ради удобства чтения.
Перезапуск после исправления
# Только если изменён unit-файл:
sudo systemctl daemon-reload
sudo systemctl restart demo.service
systemctl is-active demo.serviceАктивное состояние — промежуточная проверка. Дополнительно откройте рабочий endpoint или выполните прикладную операцию, затем проверьте новые сообщения журнала. Успешный запуск процесса не доказывает, что он подключился к базе или начал обслуживать запросы.
Оставьте короткую запись об инциденте: когда произошёл сбой, что стало причиной, что изменили и как проверили. При повторении она сэкономит время. Пароли, токены и персональные данные из журнала в эту заметку не переносите.