Czytanie logów za pomocą journalctl

Moduł 6: Usługi i logi · Czas czytania: 11 min

Cel lekcji: Po tej lekcji będą Państwo potrafili za pomocą journalctl celowo przeszukiwać logi swojego serwera (według usługi, priorytetu i czasu), będą Państwo wiedzieć, gdzie znajdują się inne pliki logów, oraz zapobiegną Państwo zapełnieniu dysku przez logi.

Kluczowe pojęcia: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, priorytet (err, warning, info), trwałe przechowywanie, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

Log jako pierwszy świadek

Gdy coś na serwerze nie działa, przyczyna prawie zawsze jest zapisana w logu. Strona internetowa wyświetlająca stronę błędu, usługa, która się nie uruchamia, kopia zapasowa, która nie wykonała się tej nocy: serwer to zanotował. Dobry administrator najpierw zagląda do logu, a dopiero potem zaczyna coś zmieniać.

Na nowoczesnych serwerach z systemem Linux journald (część systemd) zbiera komunikaty jądra, samego systemd i wszystkich usług w jednym dzienniku: journal. Odczytują go Państwo za pomocą journalctl.

Aby móc odczytać wszystko, muszą Państwo należeć do grupy adm lub systemd-journal albo użyć sudo. Bez tych uprawnień widzą Państwo tylko własne komunikaty.

Gdzie to jest zapisane? Trwale lub ulotnie

journald przechowuje journal w jednym z dwóch miejsc:

• w /var/log/journal/: trwale, logi zostają zachowane po ponownym uruchomieniu;
• w /run/log/journal/: ulotnie, w pamięci, znikają po ponownym uruchomieniu.

Ustawienie domyślne (Storage=auto w /etc/systemd/journald.conf) wybiera przechowywanie trwałe, jeśli katalog /var/log/journal/ istnieje. W Debianie pakiet systemd tworzy ten katalog już od Debiana 11, w Ubuntu on również istnieje. Prosimy to sprawdzić:

anna@web1:~$ ls -d /var/log/journal
/var/log/journal
anna@web1:~$ journalctl --list-boots | tail -n 3
 -2 3c1f... Sun 2026-11-01 04:30:12 CET Sun 2026-11-08 04:30:01 CET
 -1 9ab7... Sun 2026-11-08 04:30:40 CET Mon 2026-11-09 08:12:05 CET
  0 e41d... Mon 2026-11-09 08:12:30 CET Mon 2026-11-09 11:40:17 CET

Jeśli widzą Państwo tylko jedno uruchomienie, choć serwer był już ponownie uruchamiany, Państwa logi są ulotne. Prosimy utworzyć katalog (sudo mkdir -p /var/log/journal i sudo systemd-tmpfiles --create --prefix /var/log/journal) i ponownie uruchomić journald. To ważne: po awarii chcą Państwo przecież wiedzieć, co działo się przed ponownym uruchomieniem.

Od Debiana 12 Debian nie instaluje już domyślnie rsyslog. Ten program zapisywał dawniej pliki tekstowe, takie jak /var/log/syslog i /var/log/auth.log. Na nowym serwerze z Debianem te pliki więc nie istnieją; wszystko znajduje się w journal. Ubuntu nadal ma rsyslog. Poradniki, które mówią „proszę zajrzeć do /var/log/auth.log”, mogą Państwo w Debianie przełożyć na journalctl -u ssh.

Wyszukiwanie: filtry, których naprawdę się używa

Bez filtra journalctl pokazuje wszystko, od najstarszego wpisu. Rzadko tego Państwo potrzebują. Najważniejsze filtry, które można łączyć:

Priorytety mają wartości od 0 (emerg) do 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. Za pomocą -p err otrzymują Państwo err i wszystko, co poważniejsze. -p warning pokazuje także ostrzeżenia.

Typowa ścieżka wyszukiwania. Państwa strona od rana zwraca błąd 502:

anna@web1:~$ systemctl status php8.4-fpm
× php8.4-fpm.service - The PHP 8.4 FastCGI Process Manager
     Active: failed (Result: exit-code) since Mon 2026-11-09 07:02:11 CET; 4h ago
...
anna@web1:~$ sudo journalctl -u php8.4-fpm --since today -p warning --no-pager
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: [/etc/php/8.4/fpm/pool.d/www.conf:42] unknown entry 'pm.max_children '
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: FPM initialization failed
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Main process exited, code=exited, status=78/CONFIG
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Failed with result 'exit-code'.

Przyczyna jest podana dosłownie: literówka w wierszu 42 pliku konfiguracyjnego. Status 78 (CONFIG) potwierdza, że chodzi o błąd konfiguracji. Nie trzeba niczego zgadywać.

Dwie wskazówki dotyczące czytania:

• Proszę czytać od góry do dołu i szukać pierwszego błędu. Jeden błąd często wywołuje całą serię kolejnych komunikatów. Pierwszy z nich jest zwykle przyczyną.
• Proszę zwrócić uwagę na czas. Co zmieniło się mniej więcej w tym momencie? Automatyczna aktualizacja (lekcja 4.2: /var/log/unattended-upgrades/), Państwa własna zmiana, ponowne uruchomienie?

Inne pliki logów

Nie wszystko trafia do journal. Wiele programów zapisuje także (lub wyłącznie) własne pliki w /var/log/:

Duże pliki tekstowe czytają Państwo za pomocą less (wyszukiwanie przez /), koniec pliku za pomocą tail -n 50, na żywo za pomocą tail -f, a filtrują za pomocą grep:

anna@web1:~$ sudo grep " 502 " /var/log/nginx/access.log | tail -n 5

Logi kontenerów Docker nie znajdują się w /var/log, lecz w samym Dockerze: docker compose logs (lekcja 9.3).

Logi nie mogą zapełnić dysku

Pełny dysk to jedna z najczęstszych przyczyn tego, że serwer „nagle” przestaje działać: bazy danych się zatrzymują, aktualizacje kończą się niepowodzeniem, czasem nie da się nawet zalogować. Winowajcą są często logi.

Journal sam się ogranicza. Domyślnie zajmuje najwyżej 10% systemu plików, maksymalnie 4 GB (SystemMaxUse=). Ile zajmuje obecnie i jak go wyczyścić:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # usuń starsze niż 30 dni
anna@web1:~$ sudo journalctl --vacuum-size=500M    # do 500 MB

Jeśli chcą Państwo ustalić stały limit, prosimy wpisać go w pliku drop-in /etc/systemd/journald.conf.d/grootte.conf:

[Journal]
SystemMaxUse=1G

i ponownie uruchomić journald za pomocą sudo systemctl restart systemd-journald.

Pliki tekstowe w /var/log obsługuje logrotate: codziennie lub co tydzień plik otrzymuje nową nazwę (error.log.1), starsze wersje są kompresowane (.gz), a najstarsze usuwane. Reguły dla poszczególnych programów znajdują się w /etc/logrotate.d/. Pakiety z dystrybucji dostarczają własne reguły. Jeśli własny program lub skrypt zapisuje do własnego pliku logu, prosimy samodzielnie utworzyć regułę, w przeciwnym razie plik będzie rósł bez końca.

Wyszukiwanie tego, co zajmuje miejsce:

anna@web1:~$ df -h /
anna@web1:~$ sudo du -xh /var/log | sort -h | tail -n 5

Logi a prywatność

Logi zawierają adresy IP, nazwy użytkowników, a czasem adresy e-mail: są to dane osobowe. Prosimy nie przechowywać ich dłużej, niż to konieczne (dla małego serwera typowe jest od kilku tygodni do kilku miesięcy), nie udostępniać ich publicznie (katalog /logs w katalogu głównym strony to znany błąd) i nie kopiować ich bez zastanowienia do usług innych firm.

W AlmaLinux i Rocky Linux

journalctl działa tak samo. Tam rsyslog jest nadal domyślnie włączony, z plikami takimi jak /var/log/messages i /var/log/secure (odpowiednik auth.log). Komunikaty SELinux znajdują się w /var/log/audit/audit.log; ausearch -m avc -ts recent pokazuje ostatnie odmowy.

Podsumowanie

• journald zbiera wszystkie komunikaty w journal; odczytują je Państwo za pomocą journalctl, filtrując według usługi (-u), priorytetu (-p), czasu (--since) i uruchomienia (-b).
• Prosimy sprawdzić, czy journal jest trwały (czy istnieje /var/log/journal), w przeciwnym razie po ponownym uruchomieniu stracą Państwo logi.
• Debian 12 i nowsze nie mają domyślnie rsyslog, a więc również plików /var/log/auth.log i /var/log/syslog; wszystko znajduje się w journal.
• Prosimy szukać pierwszego błędu i sprawdzać, co zmieniło się w tym czasie.
• Prosimy pilnować rozmiaru: journal ogranicza się sam (--disk-usage, --vacuum-*), pliki tekstowe obsługuje logrotate.

Quiz

Zadanie

Zadanie Z6.2: Analiza usługi, która ulega awarii. W przykładowym pliku journal-crash-1.txt znajdują się wyniki systemctl status i journalctl dla usługi, która wciąż uruchamia się ponownie, a w końcu się poddaje. Prosimy odpowiedzieć: jak nazywa się usługa, ile razy systemd próbował ją uruchomić, z jakim kodem wyjścia się zakończyła, jaka jest przyczyna według pierwszego komunikatu o błędzie i o której godzinie systemd zrezygnował? Program porównuje odpowiedzi ze stałym kluczem. Następnie prosimy sprawdzić na własnym serwerze, czy journalctl -p err -b pokazuje błędy i czy Państwa journal jest trwały.

Przeczytaj więcej

• Dokumentacja journalctl(1): https://manpages.debian.org/trixie/systemd/journalctl.1.en.html
• Dokumentacja journald.conf(5) (Storage=, SystemMaxUse=): https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html
• Debian 12, informacje o wydaniu 5.1.7 (rsyslog nie jest już domyślny): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html