Фоновые процессы и автозапуск: systemd unit и journalctl

4. Поиск ошибок запуска в журнале journalctl

Фоновые службы не имеют собственного терминала, поэтому стандартные потоки вывода (stdout) и ошибок (stderr) перехватывает системный журнал. Для чтения этих записей используется утилита journalctl.

Посмотрим, как выглядит диагностика типового сбоя на практике. Допустим, в конфигурации сервиса была допущена опечатка в пути к исполняемому файлу. Откройте юнит через sudo nano /etc/systemd/system/devops-demo.service и временно измените в ExecStart путь к несуществующему файлу, например /home/student/devops-demo/.venv/bin/python-broken. Сохраните изменения и примените их:

sudo systemctl daemon-reload
sudo systemctl restart devops-demo

Обратите внимание: сама команда restart может выполниться без единой ошибки и вернуться в командную строку с нулевым кодом. В нашем юните не указан параметр Type=, поэтому systemd использует тип запуска по умолчанию — simple. При таком типе менеджер считает запуск принятым сразу после создания процесса, ещё до того, как система попытается выполнить саму команду по указанному пути. Успешное завершение systemctl restart говорит лишь о том, что запрос на перезапуск принят, но не доказывает, что приложение действительно работает.

Проверим фактическое состояние службы:

systemctl status devops-demo

В строке Active: вместо ожидаемого active (running) отобразится failed (Result: exit-code) либо промежуточное состояние activating (auto-restart), пока действует правило Restart=on-failure. В подробностях процесса появится статус завершения (code=exited, status=203/EXEC).

Чтобы увидеть причину сбоя полностью, запросим журнал сервиса через journalctl:

journalctl -u devops-demo -n 50 --no-pager

Флаг -u devops-demo отбирает сообщения конкретного юнита. Флаг -n 50 ограничивает вывод последними 50 строками. Флаг --no-pager отключает интерактивный просмотрщик, выводя текст прямо в поток терминала без необходимости нажимать q для выхода.

В выводе журнала отобразится сообщение ядра о неудачной попытке запуска:

Failed at step EXEC spawning /home/student/devops-demo/.venv/bin/python-broken: No such file or directory

Код ошибки 203/EXEC означает, что systemd попытался запустить процесс, но исполняемый файл по указанному пути не найден или к нему нет прав на выполнение.

Теперь вернём сервис в рабочее состояние. Откройте /etc/systemd/system/devops-demo.service, восстановите исходный путь /home/student/devops-demo/.venv/bin/python, сохраните файл и выполните полный цикл обновления:

sudo systemctl daemon-reload
sudo systemctl restart devops-demo

Убедимся, что служба восстановилась и отвечает на запросы:

systemctl status devops-demo
curl http://127.0.0.1:8000/health

Статус снова показывает active (running), а curl возвращает штатный ответ веб-сервера. Любая правка параметров юнита на диске всегда требует вызова daemon-reload, иначе systemd продолжит использовать кэшированную конфигурацию из оперативной памяти.