Skip to content
VDS · Моніторинг і продуктивність

Логи systemd: journalctl простою мовою

Як знайти причину збою служби в лозі, відфільтрувати потрібне за часом і рівнем та не дати логам з'їсти весь диск.

Оновлено 23 серпня 2026 р.

Майже все, що відбувається в системі, потрапляє до журналу systemd. Сервіс не запускається, машина перезавантажилася сама, сайт повертає 502 — відповідь зазвичай уже записана, треба лише знати, як її запитати.

П'ять команд, яких достатньо

journalctl -u nginx -n 50 --no-pager      # last 50 lines of one service
journalctl -u nginx -f                    # follow in real time
journalctl -p err -b                      # only errors since boot
journalctl --since "10 min ago"           # everything for the last ten minutes
journalctl -b -1 -e                       # previous boot log, end of file

Остання особливо цінна після раптового перезавантаження: -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            # several services at once
journalctl _PID=1432                      # by specific process
journalctl -k                             # only kernel messages
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 може відмовитися працювати, доки не звільнити місце. Цю ситуацію розібрано в статті Заповнено диск.