Как найти нужную ошибку в journalctl

Полный системный журнал редко помогает с первого взгляда. В нём перемешаны сообщения разных процессов, перезапуски и фоновые события. Начните с узкого вопроса: что происходило с конкретным сервисом в момент сбоя?

Выбрать сервис и интервал

В примере имя unit — nginx.service. Для своего приложения подставьте его имя. Временные границы без явного часового пояса интерпретируются в локальном времени системы.

sudo journalctl -u nginx.service \
  --since '2026-09-09 10:00:00' \
  --until '2026-09-09 10:10:00' \
  --no-pager

Если журнал пуст, проверьте временной пояс, имя сервиса и права доступа. Пустой результат не всегда означает отсутствие проблемы.

Наблюдать воспроизведение

sudo journalctl -u nginx.service -n 50 -f

Теперь выполните запрос, вызывающий ошибку, и сопоставьте его с новыми записями. Ctrl+C завершает просмотр, а не останавливает сервис.

Ограничить загрузкой системы

Флаг -b выбирает текущую загрузку. Для списка сохранённых загрузок используйте journalctl --list-boots. Предыдущие записи доступны только если они сохранились: настройки хранения и ротация имеют значение.

Не отфильтровать причину

Фильтр -p err полезен для быстрого обзора, но рядом с ошибкой часто лежит контекст уровня info или warning. Сначала найдите момент, затем изучите соседние сообщения без фильтра приоритета.

Nginx может писать подробные access- и error-логи в отдельные файлы. Journalctl в таком случае покажет запуск и остановку unit, но не каждый запрос. Перед выводом «логов нет» проверьте конфигурацию логирования самого приложения.