Шпаргалка по journalctl: следим и фильтруем логи Linux

journalctl в одной строке: journalctl -u <service> -f следит за логом живого сервиса, journalctl -u <service> -n 100 показывает последние 100 строк, а journalctl --since "1 hour ago" — всё недавнее. Этого хватает на 90 % ситуаций в духе «почему сервис лёг». Дальше в шпаргалке — паттерны под копипаст, избавляющие от перечитывания man-страницы в два часа ночи: фильтрация по юниту, времени, приоритету и загрузкам, плюс команды уборки, не дающие журналу съесть ваш диск. Каждая команда ниже работает как есть на любом дистрибутиве с systemd (Ubuntu, Debian, Fedora, Arch).

Что такое journalctl и почему нельзя просто читать /var/log/syslog?

Лог в старом стиле писал текстовые файлы в /var/log — syslog, auth.log, messages. systemd заменил всё это журналом: бинарным индексированным логом под управлением systemd-journald. Обычный grep его не читает; journalctl — единственный вход, зато взамен вы фильтруете по сервису, времени, загрузке и серьёзности без акробатики с регулярками.

Ментальная модель простая: журнал хранит всё, а journalctl — инструмент запросов. Сервису не нужен собственный файл лога — всё, что он пишет в stdout/stderr под systemd, автоматически попадает в журнал. Поэтому journalctl -u nginx работает, даже когда вы понятия не имеете, куда nginx настроил писать ошибки.

Одно «но»: на минимальных установках журнал бывает волатильным (лежит в /run, стирается при перезагрузке), потому что /var/log/journal не существует. Лечится один раз:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

Как посмотреть последние 100 строк лога?

-n ограничивает вывод N свежайшими строками (по умолчанию 10):

journalctl -n 100                      # последние 100 строк всего журнала
journalctl -u nginx -n 100             # последние 100 строк одного юнита
journalctl -n 100 --no-pager           # вывести и выйти — идеально для пайпа

--no-pager важнее, чем кажется: без него journalctl открывает less, и ваш скрипт, пайп или однострочник по ssh висит в ожидании нажатия клавиши. Любой команде, чей вывод уходит дальше по пайпу, нужен этот флаг.

Как следить за логами вживую, как tail -f?

Флаг -f — это journalctl-овский tail -f: он стримит новые записи по мере появления:

journalctl -f                    # всё, вживую
journalctl -u sshd -f            # только демон SSH, вживую
journalctl -u ollama -f -n 50    # вживую, но начать с последних 50 строк

Это команда для второго терминала, пока в первом вы перезапускаете сервис: systemctl restart nginx в одной панели, journalctl -u nginx -f в другой — и причина падения обычно объявляется сама за считанные секунды. Я гоняю ровно этот цикл на своём homelab каждый раз, когда контейнер или сервис начинает чудить.

Как показать логи конкретного сервиса?

-u фильтрует по юниту systemd:

journalctl -u nginx                    # один юнит, вся история
journalctl -u nginx -u redis           # несколько юнитов сразу
journalctl _SYSTEMD_UNIT=nginx.service # вариант с точным совпадением

Юнит может порождать вспомогательные юниты, где остаётся самый интересный вывод — падающее веб-приложение иногда пишет настоящую ошибку под другим юнитом. Если -u <service> ничего не показывает, а сервис явно работает, сначала найдите настоящее имя юнита:

systemctl list-units --type=service | grep -i <guess>

Тот же паттерн -u работает для таймеров (имена даёт systemctl list-timers) и пользовательских сервисов — для всего, что крутится под systemd --user, добавьте --user:

journalctl --user -u pipewire -n 50

Как отфильтровать логи по времени?

--since и --until принимают метки времени, но понимают и снисходительные относительные формулировки:

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

Соедините временное окно с юнитом — и разбор инцидента умещается в одну строку: «что логовала API между 09:00 и моментом, когда она упала?» Для одной машины это быстрее любого агрегатора логов.

Как показать только ошибки (или предупреждения)?

-p фильтрует по приоритету, используя имена серьёзностей syslog:

journalctl -p err -b              # только ошибки, с текущей загрузки
journalctl -p warning..alert -u nginx   # диапазон серьёзностей

Приоритеты по убыванию: emerg, alert, crit, err, warning, notice, info, debug. Когда машина «ведёт себя странно», journalctl -p err -b --since today — самая быстрая проверка на вменяемость: она отвечает на вопрос «тут вообще что-то падает?» без шума рутинных info-строк.

Как увидеть логи предыдущей загрузки?

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

journalctl -b                 # только текущая загрузка
journalctl -b -1              # предыдущая загрузка
journalctl -b -1 -u sshd      # почему SSH умер в прошлый раз
journalctl --list-boots       # индекс сохранённых загрузок

Самый полезный флаг для сценария «сломалось, перезагрузил, и теперь ошибки не видно» — ошибка всё ещё там, на одну загрузку назад.

Шпаргалка: флаги, которые стоит запомнить

Задача	Команда
Следить за сервисом вживую	`journalctl -u <svc> -f`
Последние 100 строк	`journalctl -n 100`
За последний час	`journalctl --since "1 hour ago"`
Ошибки этой загрузки	`journalctl -p err -b`
Предыдущая загрузка	`journalctl -b -1`
Место на диске под журнал	`journalctl --disk-usage`
Вывод для машинной обработки	`journalctl -o json-pretty`
Только сообщения ядра	`journalctl -k`

Как не дать журналу забить диск?

Сначала смотрим, сколько он стоит, потом ставим потолок:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # оставить свежайшие 500 МБ
sudo journalctl --vacuum-time=30d      # оставить последние 30 дней

Чтобы потолок стал постоянным, задайте SystemMaxUse=500M в секции [Journal] файла /etc/systemd/journald.conf, затем sudo systemctl restart systemd-journald. С потолком размера и фильтром по загрузкам журнал снова инструмент, а не медленная утечка диска.

journalctl vs dmesg vs /var/log — куда смотреть первым делом?

journalctl — поведение приложений и сервисов. Всё, чем управляет systemd, лежит здесь: индексировано и фильтруется. Отправная точка по умолчанию.
journalctl -k / dmesg — ядро и железо: OOM-убийства, сбросы USB, ошибки дисков. Если процесс умер без объяснений, ищите OOM killer здесь, прежде чем винить приложение.
/var/log/<app>/ — только для приложений с собственным файловым логом (access-логи nginx, PostgreSQL). И даже у них ошибки старта обычно всё равно попадают в журнал.

Тот же рабочий процесс распространяется на локальные ИИ-сервисы — когда юнит ollama serve зависает, journalctl -u ollama -n 100 сразу показывает провал загрузки модели, о чём подробнее в сравнении Ollama и LM Studio.

Вот и вся шпаргалка: -u — юнит, -f — следить, -n — строки, --since — время, -p — серьёзность, -b — загрузки. Шесть флагов покрывают почти любой вопрос к логам, который вам задаст машина с Linux.