journalctl w praktyce: znajdź właściwe logi i odczytaj kontekst

W dzienniku systemowym możesz znaleźć zarówno przyczynę awarii, jak i setki zwykłych komunikatów. Skuteczne użycie journalctl polega na wyborze właściwego uruchomienia, czasu i usługi. Sam czerwony wpis lub słowo „failed” nie wyjaśniają, co wymaga zmiany.

Przykłady dotyczą systemów korzystających z journala systemd. Nazwa nginx.service jest przykładem: zastąp ją istniejącą jednostką na swoim komputerze. Polecenia odczytu nie restartują usług i nie usuwają logów.

Najpierw określ moment i zakres problemu

Zapisz godzinę awarii, objaw oraz to, czy komputer został później uruchomiony ponownie. Jeśli szukasz przyczyny poprzedniego restartu, log bieżącego startu może już jej nie obejmować. Jeżeli problem dotyczy jednej aplikacji, nie zaczynaj od całej historii systemu.

Stan znanej usługi sprawdzisz przez:

systemctl status nginx.service --no-pager

Wynik pokazuje stan i fragment ostatnich komunikatów, a nie kompletną historię. Odczytaj także nazwę jednostki i jej źródło. Usługa systemowa oraz usługa sesji użytkownika mogą mieć podobne nazwy, lecz należeć do różnych zakresów zarządzania.

Wybierz uruchomienie i przedział czasu

journalctl --list-boots
journalctl -b --no-pager
journalctl -b -1 --no-pager

Pierwszy odczyt pokazuje zachowane uruchomienia, drugi bieżące, a trzeci poprzednie. Brak poprzedniego startu na liście może wynikać z przechowywania logu, a nie z braku zdarzeń podczas awarii.

Przy konkretnej godzinie ogranicz zakres. Datę w przykładzie zastąp datą zdarzenia:

journalctl --since "2026-10-04 18:20:00" --until "2026-10-04 18:30:00" --no-pager

Sprawdź czas i strefę systemu. Porównując zapis routera z logiem komputera, uwzględnij różnicę ustawień zegara. Zbyt wąskie okno może pominąć wcześniejszą przyczynę, dlatego obejmij nim również chwilę poprzedzającą objaw.

Usługa, jądro i priorytet

journalctl -b -u nginx.service --since "-15 min" --no-pager
journalctl -k -b --no-pager
journalctl -b -p warning --no-pager

Odczyty wybierają kolejno jednostkę z ostatnich minut, komunikaty jądra i poziom warning wraz z poważniejszymi. Filtry można łączyć. Przy usługach użytkownika dobierz zakres --user. Jeśli zwykłe konto nie widzi potrzebnych dzienników systemowych, użyj uprawnionego konta lub sudo; nie zmieniaj praw wszystkich plików logów.

Filtr priorytetu pomaga przy pierwszym przeglądzie, ale nie pokazuje całego kontekstu. Program mógł zapisać istotną informację jako zwykły komunikat. Po znalezieniu błędu przeczytaj również sąsiednie wpisy bez ograniczenia do warning.

Przykładowo seria „uruchamianie”, następnie komunikat parsera wskazujący plik i linię, a na końcu „usługa zakończyła się” prowadzi do sprawdzenia konfiguracji. Ostatnia wiadomość systemd opisuje skutek. Zmienianie zasad restartowania nie naprawi wcześniejszego błędu składni.

Oddziel częstotliwość od znaczenia komunikatu. Jedno ostrzeżenie przy starcie, po którym usługa działa poprawnie, może być mniej istotne niż zwykły wpis powtarzany przed każdym zerwaniem połączenia. Zapisz zależność między konkretnym zdarzeniem a obserwowanym objawem. Nie kasuj znalezionego pliku ani nie wyłączaj mechanizmu, którego nazwę zobaczyłeś w logu, dopóki nie rozumiesz treści komunikatu.

Dobrym wynikiem analizy jest zdanie: „po odczytaniu tego pliku program zgłasza błąd składni w tej linii i kończy start”. Ogólne stwierdzenie „journal ma błędy” nie wskazuje następnego kroku. Jeśli nie da się uzyskać tak konkretnego opisu, rozszerz kontekst albo sprawdź dziennik aplikacji.

Obserwacja na żywo i zapis wybranego fragmentu

journalctl -f -u nginx.service
journalctl -b -u nginx.service --since "-15 min" -o short-iso --no-pager > log-uslugi.txt

Śledzenie zakończysz przez Ctrl+C; zatrzymujesz obserwację, nie usługę. Drugie polecenie zapisuje wybrany zakres do pliku w bieżącym katalogu. Znak > zastąpi plik o tej nazwie, jeśli już istnieje, więc przed ponownym użyciem wybierz nazwę, której nie chcesz zachować.

Do zgłoszenia dołącz opis zdarzenia, wersję programu oraz zakres czasu. Sprawdź treść pliku przed udostępnieniem: aplikacja może zapisać token, nazwę użytkownika, adres lub fragment żądania. Usuń dane wrażliwe, pozostawiając kolejność komunikatów i właściwy błąd.

Dlaczego journal może być pusty lub niepełny?

W trybie nietrwałym dzienniki są przechowywane w /run/log/journal i mogą zniknąć po restarcie. Przechowywanie trwałe wiąże się z /var/log/journal oraz konfiguracją journald. Sprawdź politykę swojego systemu, zanim uznasz, że wcześniejsza awaria nie została odnotowana.

Ograniczenia rozmiaru i retencji mogą usunąć starszą historię. Ograniczanie liczby komunikatów może pomijać część wpisów przy bardzo intensywnym logowaniu. Zwiększenie retencji na przyszłość nie odtworzy informacji, których już nie ma.

Nie każdy program zapisuje wszystkie szczegóły do journala. Aplikacja może prowadzić własny plik, a kontener osobny mechanizm logowania. Jeśli widać wyłącznie start procesu i kod zakończenia, sprawdź dokumentację jego logów. Kolejne rozszerzanie filtra systemowego nie ujawni treści zapisanej gdzie indziej.

Nie czyść journala podczas zbierania materiału do diagnozy. Jeśli zajmuje dużo miejsca, najpierw zachowaj potrzebny zakres i sprawdź wykorzystanie dysku w Linuksie. Przy usłudze kończącej się błędem dalsze kroki opisuje poradnik diagnozowania nieudanego startu usługi.