■ space · прозаическая полоса

ШЕСТЬ, КАК КАРТОЧКИ

лестница -p, по убыванию — journalctl -p warning..alert берёт диапазон · -p err — рабочая лошадка

ПОЧЕМУ БЫ ПРОСТО НЕ ЧИТАТЬ /var/log/syslog?

Старый Linux-логинг писал текстовые файлы в /var/log — syslog, auth.log, messages. systemd replaced that with systemd заменил это на the journal: бинарный, индексированный лог под управлением . Plain grep cannot read it; journalctl — единственная парадная дверь, а взамен вы получаете фильтрацию по сервису, времени, загрузке и важности без регэксной гимнастики.

Ментальная модель: журнал хранит всё, а journalctl запрашивает. Сервису не нужен собственный файл лога — всё, что он пишет в stdout/stderr под systemd, автоматически попадает в журнал. volatile (хранится в /run, стирается при перезагрузке), потому что /var/log/journal не существует. Почините один раз:

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

проверка: ls /var/log/journal → каталог есть — загрузки накапливаются, а не стираются

СТРОКИ, СЛЕЖЕНИЕ, ЮНИТЫ

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

journalctl -n 100                      # last 100 lines of everything
journalctl -u nginx -n 100             # last 100 lines from one unit
journalctl -n 100 --no-pager           # print and exit — perfect for piping

— это is journalctl's tail -f от journalctl — стримит новые записи по мере появления. Вот команда для второго терминала, пока вы перезапускаете сервис в первом: systemctl restart nginx в одной панели, journalctl -u nginx -f в другой — и причина краша сама объявится за секунды.

journalctl -f                    # everything, live
journalctl -u sshd -f            # just the SSH daemon, live
journalctl -u ollama -f -n 50    # live, but start with the last 50 lines

фильтрует по systemd-юниту — один, несколько или вариант точного совпадения: filters by systemd unit — one, several, or the exact-match alternative:

journalctl -u nginx                    # one unit, all history
journalctl -u nginx -u redis           # several units at once
journalctl _SYSTEMD_UNIT=nginx.service # exact match

-u <сервис> не показывает ничего, хотя сервис явно работает? Юниты могут плодить юниты-помощники, в которых оседает интересный вывод — падающее веб-приложение иногда логирует в systemctl list-units --type=service | grep -i <guess>. Тот же приём для таймеров (systemctl list-timers показывает имена) и для всего, что работает под systemd --user, добавьте --user: journalctl --user -u pipewire -n 50.

ВРЕМЯ И ВАЖНОСТЬ

--since and --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

-p фильтрует по приоритету по лестнице syslog, показанной выше. Когда машина «ведёт себя странно», journalctl -p err -b --since today — самая быстрая проверка здравомыслия: отвечает на «а что-нибудь реально падает?» без шума рутинных info-строк.

journalctl -p err -b                    # errors only, since this boot
journalctl -p warning..alert -u nginx   # a range of severities

ЗАГРУЗКИ

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

journalctl -b                 # current boot only
journalctl -b -1              # previous boot
journalctl -b -1 -u sshd      # why SSH died last time
journalctl --list-boots       # index of stored boots

ДИСК

Проверьте, сколько стоит журнал, и поставьте потолок — один vacuum сейчас, одна строка конфига навсегда:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # keep newest 500 MB
sudo journalctl --vacuum-time=30d      # keep newest 30 days

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

08КАКОЙ ЛОГ СНАЧАЛА?

• journalctl — поведение приложений и сервисов. Всё, чем управляет systemd, здесь: индексировано и фильтруется. Остановка по умолчанию первая.
• journalctl -k / — ядро и железо: OOM-убийства, сбросы USB, ошибки диска. Если процесс умер загадочно, ищите OOM-киллера здесь, прежде чем винить приложение. — kernel and hardware: OOM kills, USB resets, disk errors. If a process died mysteriously, look for the OOM killer here before blaming the app.
• — только для приложений, которые сами ведут файловые логи (access-логи nginx, PostgreSQL). И даже тогда ошибки старта обычно всё равно оседают в журнале. — only for apps that do their own file logging (nginx access logs, PostgreSQL). Even then, startup errors usually still land in the journal.

Тот же поток распространяется и на локальные AI-сервисы — когда юнит ollama serve буксует, journalctl -u ollama -n 100 сразу показывает провал загрузки модели. Вот и вся шпаргалка: -u для юнита, -f чтобы следить, -n для строк, --since для времени, -p для важности, -b для загрузок. Шесть опций покрывают почти любой лог-вопрос, который задаст вам Linux-машина — а когда вопрос в том, почему systemd-сервис не стартует, эти

конец шпаргалки · ничего не скачано · всё локально