journalctl: ściągawka na codzienną pracę z logami Linuksa

journalctl w jednym wierszu: journalctl -u <service> -f śledzi log usługi na żywo, journalctl -u <service> -n 100 pokazuje ostatnie 100 linii, a journalctl --since "1 hour ago" pokazuje wszystko z ostatnich chwil. To pokrywa 90% momentów typu „czemu ta usługa nie odpowiada”. Reszta ściągawki to wzorce do wklejenia, które oszczędzą ci ponownej lektury man page o 2 w nocy — filtrowanie po jednostce, czasie, priorytecie i starcie, plus komendy porządkowe, które nie pozwolą journalowi zjeść ci dysku. Każda komenda poniżej działa bez zmian na każdej dystrybucji ze systemd (Ubuntu, Debian, Fedora, Arch).

Czym jest journalctl i czemu nie czytać po prostu /var/log/syslog?

Logowanie po staremu zapisywało zwykłe pliki tekstowe pod /var/log — syslog, auth.log, messages. systemd zamienił to na journal: binarny, indeksowany log zarządzany przez systemd-journald. Zwykły grep nie da rady go przeczytać; journalctl to jedyne drzwi wejściowe, a w zamian dostajesz filtrowanie po usłudze, czasie, starcie i ważności bez akrobacji na regexach.

Model mentalny jest prosty: journal przechowuje wszystko, a journalctl to narzędzie do odpytywania. Usługa nie potrzebuje własnego pliku logu — wszystko, co pisze na stdout/stderr, działając pod systemd, ląduje w journalu automatycznie. Dlatego journalctl -u nginx działa nawet wtedy, gdy nie masz pojęcia, gdzie nginx skonfigurował swój error log.

Jedno zastrzeżenie: przy niektórych minimalnych instalacjach journal jest ulotny (trzymany w /run, czyszczony przy reboocie), bo /var/log/journal nie istnieje. Naprawiasz to raz:

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

Jak zobaczyć ostatnie 100 linii logu?

-n ogranicza wyjście do N najnowszych linii (domyślnie 10):

journalctl -n 100                      # ostatnie 100 linii wszystkiego
journalctl -u nginx -n 100             # ostatnie 100 linii jednej jednostki
journalctl -n 100 --no-pager           # wypisz i wyjdź — idealne do pipe'a

--no-pager znaczy więcej, niż wygląda: bez niego journalctl odpala less i twój skrypt, pipe albo one-liner przez ssh wisi, czekając na klawisz. Każda komenda, której wyjście leci dalej w pipe, powinna go mieć.

Jak śledzić logi na żywo, jak tail -f?

Flaga -f to journalowy tail -f — strumieniuje nowe wpisy na bieżąco:

journalctl -f                    # wszystko, na żywo
journalctl -u sshd -f            # sam demon SSH, na żywo
journalctl -u ollama -f -n 50    # na żywo, ale zacznij od ostatnich 50 linii

To komenda do odpalenia w drugim terminalu, gdy w pierwszym restartujesz usługę: systemctl restart nginx w jednym panelu, journalctl -u nginx -f w drugim, a przyczyna crashu zwykle sama się zgłasza w ciągu kilku sekund. Dokładnie tę pętlę odpalam na swoim homelabie, za każdym razem, gdy kontener albo usługa zaczyna płatać figle.

Jak pokazać logi konkretnej usługi?

-u filtruje po jednostce systemd:

journalctl -u nginx                    # jedna jednostka, cała historia
journalctl -u nginx -u redis           # kilka jednostek naraz
journalctl _SYSTEMD_UNIT=nginx.service # wariant z dokładnym dopasowaniem

Jednostki potrafią wypuszczać jednostki pomocnicze, które zachowują ciekawe wyjście — padająca aplikacja webowa czasem loguje prawdziwy błąd pod inną jednostką. Jeśli -u <service> nie zwraca nic, a usługa ewidentnie działa, najpierw znajdź prawdziwą nazwę jednostki:

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

Ten sam wzorzec -u działa dla timerów (systemctl list-timers pokaże nazwy) i usług użytkownika — do wszystkiego, co działa pod systemd --user, dodaj --user:

journalctl --user -u pipewire -n 50

Jak filtrować logi po czasie?

--since i --until przyjmują znaczniki czasu, ale też pobłażliwe sformułowania względne:

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

Połącz okno czasowe z jednostką i masz triage incydentu w jednym wierszu: „co logowało API między 9:00 a momentem, w którym padło?” Na pojedynczej maszynie to szybsze niż każdy agregator logów.

Jak pokazać tylko błędy (albo ostrzeżenia)?

-p filtruje po priorytecie, używając nazw ważności ze sysloga:

journalctl -p err -b              # tylko błędy, od tego startu
journalctl -p warning..alert -u nginx   # zakres ważności

Priorytety malejąco: emerg, alert, crit, err, warning, notice, info, debug. Gdy maszyna „zachowuje się dziwnie”, journalctl -p err -b --since today to najszybszy test poczytalności — odpowiada na pytanie „czy cokolwiek realnie pada?” bez szumu rutynowych linii info.

Jak zobaczyć logi z poprzedniego startu?

Usługi, które sypią się przy starcie, produkują linie logu przed twoim obecnym bootem, a journalctl domyślnie pokazuje tylko bieżący. -b wybiera starty:

journalctl -b                 # tylko bieżący start
journalctl -b -1              # poprzedni start
journalctl -b -1 -u sshd      # czemu SSH padło ostatnim razem
journalctl --list-boots       # indeks zapisanych startów

To najprzydatniejsza pojedyncza flaga w scenariuszu „popsuło się, zrobiłem reboot i teraz nie widzę błędu” — błąd dalej tam jest, jeden start wstecz.

Ściągawka: flagi warte zapamiętania

Cel	Komenda
Śledzenie jednej usługi na żywo	journalctl -u <svc> -f
Ostatnie 100 linii	journalctl -n 100
Od godziny wstecz	journalctl --since "1 hour ago"
Błędy w tym starcie	journalctl -p err -b
Poprzedni start	journalctl -b -1
Zajętość dysku przez journal	journalctl --disk-usage
Wyjście czytelne dla maszyn	journalctl -o json-pretty
Tylko komunikaty jądra	journalctl -k

Jak powstrzymać journal od zapełniania dysku?

Sprawdź, ile kosztuje, potem ustal limit:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # zostaw najnowsze 500 MB
sudo journalctl --vacuum-time=30d      # zostaw najnowsze 30 dni

Żeby limit był stały, ustaw SystemMaxUse=500M w sekcji [Journal] w /etc/systemd/journald.conf, potem sudo systemctl restart systemd-journald. Przy limicie rozmiaru i filtrze po starcie journal znów jest narzędziem, a nie powolnym wyciekiem dysku.

journalctl vs dmesg vs /var/log — gdzie zajrzeć najpierw?

• journalctl — zachowanie aplikacji i usług. Wszystko, czym zarządza systemd, jest tutaj: zaindeksowane i filtrowalne. Domyślny pierwszy przystanek.
• journalctl -k / dmesg — jądro i sprzęt: zabójstwa OOM, resety USB, błędy dysku. Jeśli proces umarł bez wyjaśnienia, poszukaj tu OOM killera, zanim obwinisz aplikację.
• /var/log/<app>/ — tylko dla aplikacji, które prowadzą własne logi plikowe (access logi nginx, PostgreSQL). I nawet wtedy błędy startowe zwykle lądują w journalu.

Ten sam workflow rozciąga się na lokalne usługi AI — gdy jednostka ollama serve staje w miejscu, journalctl -u ollama -n 100 od razu pokaże nieudane ładowanie modelu, jak opisano w porównaniu Ollama vs LM Studio.

To cała ściągawka: -u dla jednostki, -f do śledzenia, -n dla linii, --since dla czasu, -p dla ważności, -b dla startów. Sześć flag pokrywa niemal każde pytanie o logi, jakie postawi ci maszyna z Linuksem.