Journalctl: как найти причину сбоя сервиса по журналу systemd

Начните диагностику с конкретного сервиса и интервала времени: journalctl -u app.service --since ... --until .... Затем уточните загрузку системы и приоритет сообщений. Такой порядок помогает восстановить цепочку событий, не потеряв обычную запись, которая объясняет последующую ошибку.

В примере Mentoring.digital app.service служит условным именем. Замените его на существующий unit. Приведённые команды читают состояние и журнал; перезапускать сервис для этого не требуется.

Уточняем имя и состояние unit

systemctl status app.service --no-pager
journalctl -u app.service -n 100 --no-pager

Первая команда показывает состояние unit и доступный фрагмент последних сообщений. Вторая читает журнал выбранного сервиса. Статус failed сам по себе не объясняет причину: ищите сообщения приложения и systemd рядом с моментом остановки.

Для пользовательского сервиса нужны соответствующие команды systemctl --user и journalctl --user -u .... Нельзя считать системный и пользовательский unit одним объектом только из-за одинакового имени.

Ограничиваем время и загрузку

journalctl -u app.service   --since "2026-10-28 08:50:00"   --until "2026-10-28 09:10:00"   --no-pager

journalctl --list-boots
journalctl -b -1 -u app.service --no-pager

Даты здесь иллюстрируют условное окно диагностики. Учитывайте часовой пояс сервера и формат времени в сообщениях приложения. Если проблема была до перезагрузки, фильтр только текущей загрузки её не покажет. Значение -b -1 выбирает предыдущую загрузку, если её записи доступны.

Не делайте вывод о работоспособности только по пустой выдаче. Возможно, выбран другой unit, период, пользовательский журнал или журнал предыдущей загрузки уже не сохранился.

Когда помогает фильтр приоритета

journalctl -u app.service -p warning --no-pager
journalctl -u app.service -f

Приоритет warning включает предупреждения и более серьёзные уровни, а не только записи с одним точным уровнем. Но приложение может писать важное диагностическое сообщение как info. Поэтому сначала посмотрите полный контекст нужного интервала, а затем сужайте выборку.

Опция -f продолжает показывать новые записи. Она не запускает приложение и не исправляет неисправность. Завершите наблюдение Ctrl+C, когда собраны нужные события.

Как читать найденную последовательность

Предположим, в учебном случае сначала появилась ошибка открытия конфигурации, затем выход процесса, затем попытка повторного запуска. Причиной для дальнейшей проверки будет путь к файлу и права его чтения. Само сообщение о перезапуске является следствием, а не достаточным объяснением.

В реальной диагностике сохраните точное время, unit, версию развертывания и несколько соседних сообщений. Если журнал нужен для передачи коллеге, удалите токены, персональные данные и другие секреты. Не публикуйте полный лог без просмотра содержимого.

Если журнала нет

Проверьте права текущего пользователя, существование unit, направление stdout/stderr и политику хранения журнала. Приложение может писать в отдельный файл или систему сбора логов. Ограничения доступа и отсутствие сохранённых записей следует различать.

Не меняйте конфигурацию journald и не очищайте журнал ради этой проверки. Если нужны новые настройки хранения, оформите отдельное изменение с оценкой объёма и срока хранения.

Потренировать диагностику сервисов можно на курсах Linux. Разобрать последовательность событий конкретного сбоя помогут наставники по Linux.