Как найти нужную ошибку в журнале systemd через journalctl

Сообщение «сервис снова упал» трудно превратить в действие без времени и контекста. Журнал systemd помогает восстановить последовательность: что происходило до отказа, какая операция завершилась ошибкой и был ли последующий успешный запуск. Начинать лучше с узкого окна, которое действительно относится к инциденту.

Команда выводит сообщения выбранной службы за последние тридцать минут. Формат времени удобен для сопоставления с мониторингом. Проверяйте часовой пояс: отметка в браузерной панели и локальное время сервера могут различаться.

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

Затем для нужного случая можно выбрать предыдущую загрузку:

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

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

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

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

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

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

The message "service crashed again" is hard to act on without time and context. The systemd journal helps reconstruct the sequence: what happened before the failure, which operation ended in error, and whether a subsequent successful start occurred. Start with a narrow window that actually relates to the incident.

The command outputs messages from the selected service for the last thirty minutes. The time format is convenient for correlating with monitoring. Check the time zone: the timestamp in the browser panel and the server's local time may differ.

If the incident involved a reboot, distinguish the current journal from the previous one. View available boots:

Then, for the relevant case, you can select a previous boot:

This selection works only if saved records exist. If the journal is stored only in memory, data prior to the boot might not have been saved. Do not treat the absence of a previous boot as proof that the service was error-free at that time.

Filtering only for errors is convenient, but it can obscure the root cause. Before a failure, there may have been routine messages about configuration changes, dependency stops, or signal reception. First, read a small complete interval, then narrow the selection.

For example, an application reports an inability to open a socket. Previous lines may show which path it used and why it switched to this configuration option. A single last line without context leaves several equally plausible hypotheses.

Correlate the event with a specific action: an update, import, configuration change, or load increase. A time match is useful, but alone it does not prove causality. Check whether the same failure repeats under the same scenario and whether a record of successful recovery appeared afterward.

Do not clear or truncate the log during the initial review. Clearing does not fix the root cause and may destroy data needed for comparison. If disk space is low, rotation should be handled separately, taking storage requirements into account.

To support the investigation, prepare the service name, time range, time zone, and several related messages before and after the error. Remove tokens, personal data, and request content from the text if they appear in the log. After the fix, repeat the same scenario and verify that the error does not reappear. A useful summary is a sequence of events and a testable hypothesis, not an archive of all server logs.