Шпаргалка journalctl: хвости, фільтри й живий хвіст логів

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?

Старий логінг Linux писав текстові файли під /var/log — syslog, auth.log, messages. systemd замінив це журналом: бінарним, індексованим логом під керуванням systemd-journald. Звичайний grep його не читає; journalctl — єдині парадні двері, а натомість ви отримуєте фільтри за сервісом, часом, завантаженням і серйозністю без гімнастики з регулярками.

Ментальна модель проста: журнал зберігає все, а journalctl — інструмент запитів. Сервісу не потрібен власний лог-файл — усе, що він пише у stdout/stderr під керуванням systemd, автоматично потрапляє в журнал. Саме тому journalctl -u nginx працює, навіть коли ви гадки не маєте, куди nginx налаштував свій error log.

Одне застереження: у деяких мінімальних встановленнях журнал волатильний (зберігається у /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 чи dmesg чи /var/log — що перевіряти першим?

• journalctl — поведінка застосунків і сервісів. Усе, керує чим systemd, тут — індексоване й фільтроване. Стандартна перша зупинка.
• journalctl -k / dmesg — ядро і залізо: OOM-вбивства, скиди USB, помилки дисків. Якщо процес помер загадково, пошукайте OOM-кілера тут, перш ніж звинувачувати застосунок.
• /var/log/<app>/ — лише для застосунків, що самі ведуть свої файли (access-логи nginx, PostgreSQL). І навіть тоді помилки старту зазвичай потрапляють у журнал.

Той самий підхід поширюється на локальні AI-сервіси — коли юніт ollama serve завмирає, journalctl -u ollama -n 100 одразу показує збій завантаження моделі, як у порівнянні Ollama та LM Studio.

Ось і вся шпаргалка: -u для юніта, -f для стеження, -n для рядків, --since для часу, -p для серйозності, -b для завантажень. Шість прапорців покривають чи не кожне логове питання, яке вам поставить машина на Linux.