Logi systemd: journalctl prostym językiem

Prawie wszystko, co dzieje się w systemie, trafia do dziennika systemd. Usługa nie chce się uruchomić, maszyna sama się zrestartowała, strona zwraca 502 — odpowiedź zwykle jest już zapisana, trzeba tylko wiedzieć, jak o nią zapytać.

Pięć poleceń, które wystarczą

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

To ostatnie jest szczególnie cenne po nagłym restarcie: -b -1 otwiera poprzednią sesję, a na końcu zobaczysz, czy był to kernel panic, działanie OOM killera, czy czyste wyłączenie.

Poziomy w -p: emerg, alert, crit, err, warning, notice, info, debug. Podany poziom obejmuje wszystkie ważniejsze.

Diagnozowanie usługi, która nie wystartowała

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

systemctl status podaje kod wyjścia i ostatnie linie, journalctl daje pełny obraz. Zwróć uwagę na:

• Main process exited, code=exited, status=1 — aplikacja sama zakończyła się błędem, przyczyna jest w linii powyżej;
• Failed to start ... Permission denied — uprawnienia do pliku, katalogu lub portu poniżej 1024;
• Killed process ... (java) total-vm... od jądra — zadziałał OOM killer, przeczytaj Brak pamięci;
• Start request repeated too quickly — usługa wpada w pętlę restartów, systemd przestał ją uruchamiać; napraw przyczynę i wykonaj systemctl reset-failed myapp.

Lista wszystkiego, co zepsute w systemie, to systemctl --failed.

Filtry, które oszczędzają czas

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

Łącz z grep, ale pamiętaj: journalctl bez --no-pager otwiera pager, wyjdziesz z niego klawiszem q.

Jak nie pozwolić dziennikowi zjeść dysku

Domyślnie dziennik rośnie do 10% partycji. Na VDS-1 z dyskiem 40 GB to cztery gigabajty — odczuwalne.

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

Stały limit ustawisz w /etc/systemd/journald.conf:

[Journal]
SystemMaxUse=300M
MaxRetentionSec=1month

Potem systemctl restart systemd-journald.

Częste błędy

• Czytanie dziennika bez -u. Ogólny strumień jest zapchany wpisami z usług i potrzebna linia gdzieś ginie. Zawsze zawężaj do usługi lub poziomu.
• Utrata historii po restarcie. Jeśli katalog /var/log/journal nie istnieje, dziennik żyje tylko w pamięci. Utwórz go: mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal.
• Szukanie tam błędów aplikacji. Nginx, PostgreSQL i podobne piszą też do własnych plików w /var/log. Jeśli dziennik jest pusty, zajrzyj tam.

Gdy dysk jest pełny, journalctl może odmówić pracy, dopóki nie zwolnisz miejsca. Tę sytuację opisuje artykuł Brak miejsca na dysku.