Журналы systemd: journalctl по-человечески

Как найти в журнале причину падения службы, отфильтровать нужное по времени и уровню и не дать логам съесть весь диск.

Обновлено 23 августа 2026 г.

Почти всё, что происходит в системе, попадает в журнал systemd. Служба не стартует, машина перезагрузилась сама, сайт отдаёт 502 — ответ обычно уже записан, надо только уметь спросить.

Пять команд, которых хватает

journalctl -u nginx -n 50 --no-pager      # последние 50 строк одной службы
journalctl -u nginx -f                    # следить в реальном времени
journalctl -p err -b                      # только ошибки с момента загрузки
journalctl --since "10 min ago"           # всё за последние десять минут
journalctl -b -1 -e                       # журнал предыдущей загрузки, конец файла

Последняя особенно ценна после внезапной перезагрузки: -b -1 открывает прошлый сеанс, и в конце видно, была ли это паника ядра, работа OOM killer или чистое выключение.

Уровни в -p: emerg, alert, crit, err, warning, notice, info, debug. Указанный уровень включает все более важные.

Разбор упавшей службы

systemctl status myapp
journalctl -u myapp --since today -p warning

systemctl status даёт код выхода и последние строки, journalctl — полную картину. Смотрите на:

Main process exited, code=exited, status=1 — приложение само завершилось с ошибкой, причина строкой выше;
Failed to start ... Permission denied — права на файл, каталог или порт ниже 1024;
Killed process ... (java) total-vm... от ядра — сработал OOM killer, читайте Кончилась память;
Start request repeated too quickly — служба падает в цикле, systemd перестал её поднимать; чините причину и делайте systemctl reset-failed myapp.

Список всего, что сломано в системе, — systemctl --failed.

Фильтры, которые экономят время

journalctl --since "2026-08-22 03:00" --until "2026-08-22 04:00"
journalctl -u nginx -u php-fpm            # несколько служб сразу
journalctl _PID=1432                      # по конкретному процессу
journalctl -k                             # только сообщения ядра
journalctl -u sshd | grep "Failed password" | tail -20

Комбинируйте с grep, но помните: journalctl без --no-pager открывает постраничный просмотр, выход — q.

Чтобы журнал не съел диск

По умолчанию журнал растёт до 10 % раздела. На VDS-1 с диском 40 ГБ это четыре гигабайта — заметно.

journalctl --disk-usage
journalctl --vacuum-size=200M
journalctl --vacuum-time=14d

Постоянное ограничение — в /etc/systemd/journald.conf:

[Journal]
SystemMaxUse=300M
MaxRetentionSec=1month

Затем systemctl restart systemd-journald.

Частые ошибки

Читать журнал без -u. Общий поток забит служебными записями, и нужная строка теряется. Всегда сужайте до службы или уровня.
Терять историю после перезагрузки. Если каталог /var/log/journal не создан, журнал живёт только в памяти. Создайте его: mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal.
Искать там ошибки приложений. Nginx, PostgreSQL и подобные пишут ещё и в свои файлы в /var/log. Если в журнале пусто, загляните туда.

Когда диск переполнился, journalctl может отказаться работать до освобождения места. Разбор такой ситуации — в статье Кончилось место на диске.