PRZYGOTOWANIE
Czego potrzebujesz
- Linux z systemd-journald
- Nazwa usługi lub przybliżony czas awarii
- Dostęp do potrzebnego dziennika; w razie ograniczonych uprawnień możliwość użycia sudo
KROK 01
Sprawdź bieżący rozruch
Zacznij od wpisów z bieżącego uruchomienia systemu. Opcja -b wybiera ten rozruch, -n 100 ogranicza wynik do ostatnich stu wpisów, a --no-pager wyłącza program przeglądający odpowiedź. Wynik pojawia się bezpośrednio w terminalu. To przegląd ostatnich zapisanych zdarzeń, a nie potwierdzenie, że każda działająca aplikacja wysyła nowe komunikaty.
Pamiętaj, że nie wszystkie aplikacje domyślnie logują do journald. Aplikacje korzystające z własnych plików logów (np. w /var/log/) mogą nie pojawiać się w dzienniku systemd. W takim przypadku journalctl nie będzie zawierał ich komunikatów, a ty musisz sprawdzić dedykowane pliki.
Jeśli dziennik jest pusty lub zawiera tylko starsze wpisy, sprawdź uprawnienia. W niektórych dystrybucjach zwykły użytkownik widzi tylko logi swoich procesów. Użyj sudo journalctl, aby odczytać pełny dziennik systemowy.
journalctl -b -n 100 --no-pagerWynik pokazuje ostatnie 100 wpisów z bieżącego rozruchu. Każdy wiersz zawiera datę i godzinę, nazwę hosta, proces i komunikat. Jeśli widzisz tylko kilka linii, system nie generuje dużo logów lub nie masz odpowiednich uprawnień.
KROK 02
Wybierz jedną usługę
Aby zawęzić dziennik do konkretnej usługi, użyj parametru -u z nazwą jednostki. W przykładzie używamy nginx.service – zastąp ją własną. Połączenie -u z -b i -n 100 daje skupiony podgląd na to, co dana usługa robiła podczas bieżącego rozruchu.
Jeśli dla danej jednostki nie ma żadnych wpisów, nie oznacza to automatycznie, że usługa jest zdrowa. Możliwe, że usługa nie loguje do journald, logi zostały już obrócone (usunięte), lub uprawnienia uniemożliwiają odczyt. Sprawdź też, czy jednostka w ogóle istnieje za pomocą systemctl status.
Nazwa jednostki musi być dokładna. Jeśli nie jesteś pewien pełnej nazwy, użyj autouzupełniania przez tabulację lub polecenie systemctl list-units --type=service, aby zobaczyć dostępne jednostki.
journalctl -u nginx.service -b -n 100 --no-pagerDziennik pokazuje tylko wpisy powiązane z nginx.service. Widzisz komunikaty startu, stopu, błędy i ostrzeżenia. Szukaj linii zawierających failed, error lub exit-code.
KROK 03
Zawęź przedział czasu
Często potrzebujesz sprawdzić logi z konkretnego momentu, a nie tylko ostatnie N wpisów. Parametry --since i --until przyjmują elastyczne formaty czasu. Możesz użyć wyrażeń względnych, takich jak 1 hour ago, yesterday, czy today, a także pełnych dat i godzin.
W przykładzie pierwsze polecenie pokazuje logi z ostatniej godziny dla nginx. Drugie pokazuje wpisy między konkretnymi datami. Pamiętaj, że journalctl wyświetla czas w strefie lokalnej systemu, a nie zawsze w UTC. Jeśli porównujesz logi z innymi źródłami, upewnij się, że strefy czasowe są zgodne.
Podaj datę i godzinę w czytelnym formacie RRRR-MM-DD GG:MM:SS. Jeśli parser nie rozpozna wartości, polecenie zgłosi błąd; nie zakładaj, że wykonało poprawne filtrowanie. Daty w przykładzie zastąp czasem swojej awarii. Bez zmiany daty możesz dostać pusty wynik, mimo że w dzienniku znajdują się inne zdarzenia.
journalctl -u nginx.service --since "1 hour ago" --no-pager
journalctl --since "2026-10-06 10:00:00" --until "2026-10-06 10:15:00" --no-pagerPierwsze polecenie wyświetla wpisy z ostatniej godziny. Drugie pokazuje logi z 15-minutowego okna między 10:00 a 10:15. W drugim przykładzie nie ma filtra jednostki, więc widać wszystkie logi systemowe z tego przedziału.
KROK 04
Odszukaj błędy oraz komunikaty jądra
Aby nie przeglądać wszystkich komunikatów, użyj filtra priorytetu -p err. Pokazuje on tylko komunikaty o poziomie err i wyższym (emerg, alert, crit, err). Poziomy 0-3 to błędy, 4-6 to ostrzeżenia i informacje. Jeśli interesują cię tylko krytyczne awarie, użyj -p crit.
Parametr -k ogranicza dziennik do komunikatów jądra (kernel). To przydatne przy diagnozowaniu problemów sprzętowych, sterowników lub modułów. Połącz -k z -b, aby zobaczyć tylko komunikaty jądra z bieżącego rozruchu.
Uwaga: filtry priorytetu i jednostki można łączyć, np. journalctl -u nginx.service -p err. Dzięki temu zobaczysz tylko błędy konkretnej usługi, co znacznie przyspiesza diagnostykę.
journalctl -b -p err --no-pager
journalctl -k -b -n 100 --no-pagerPierwsze polecenie wyświetla wszystkie błędy systemowe z bieżącego rozruchu – poziom err i wyższy. Drugie pokazuje ostatnie 100 komunikatów jądra. W obu przypadkach wynik jest znacznie krótszy niż pełny dziennik.
KROK 05
Obserwuj nowe zdarzenia i wcześniejsze uruchomienia
Parametr -f (follow) sprawia, że journalctl działa w trybie nasłuchiwania – wyświetla nowe wpisy na bieżąco, podobnie jak tail -f. To przydatne, gdy testujesz zmianę konfiguracji i chcesz na żywo widzieć, jakie komunikaty generuje usługa. Aby zakończyć podgląd, naciśnij Ctrl+C.
Polecenie --list-boots wyświetla listę poprzednich uruchomień systemu z identyfikatorem (offset) i datami. Dzięki temu możesz sprawdzić logi z poprzedniego uruchomienia systemu, używając journalctl -b -1 (ostatnie bootowanie), -b -2 (przedostatnie) itd.
Dostępność starszych logów zależy od konfiguracji journald. Jeśli system ma ograniczony rozmiar dziennika lub używa przechowywania ulotnego (volatile), starsze uruchomienia systemu mogą być niedostępne. W takim przypadku --list-boots pokaże tylko bieżący rozruch.
journalctl -u nginx.service -f
# Zakończ podgląd Ctrl+C, zanim wykonasz następne polecenie.
journalctl --list-boots
journalctl -b -1 -n 100 --no-pagerTryb -f wyświetla nowe wpisy w czasie rzeczywistym. --list-boots pokazuje tabelę z numerem boot ID, offsetem i datami. journalctl -b -1 wyświetla logi z poprzedniego uruchomienia, jeśli są dostępne.
KROK 06
Zachowaj potrzebne informacje
Gdy znajdziesz wpisy wskazujące na przyczynę problemu, zapisz je do pliku lub skopiuj. Możesz przekierować wynik journalctl do pliku: journalctl -u nginx.service -b > log_nginx.txt. To ułatwia późniejszą analizę lub wysłanie logów do kogoś, kto pomoże w diagnozie.
Przed udostępnieniem logów usuń lub zamaskuj dane wrażliwe: adresy IP z sieci wewnętrznych, nazwy użytkowników, hasła, tokeny API. Logi mogą zawierać argumenty wywołania programów, które nieświadomie ujawniają sekrety.
Podane polecenia służą odczytowi, ale journalctl ma także opcje zarządzania dziennikiem. Podczas ustalania przyczyny nie usuwaj starszych wpisów: mogą być jedynym śladem wcześniejszych awarii. Pomiar rozmiaru dziennika może przydać się przy problemach z miejscem, jednak nie zastępuje analizy komunikatów z odpowiedniego przedziału czasu.
Zapis logów do pliku pozwala na spokojną analizę i porównanie z innymi źródłami. Zawsze sprawdź, czy plik nie zawiera danych poufnych przed wysłaniem go osobom trzecim.
Pytania i odpowiedzi
Dlaczego journalctl nie pokazuje logów mojej aplikacji?
Aplikacja może nie logować do journald, tylko do własnych plików w /var/log. Sprawdź, czy proces korzysta z stdout/stderr i czy ma skonfigurowany standardowy logging. Możliwe też, że logi zostały już obrócone lub nie masz uprawnień do odczytu – spróbuj z sudo.
Jak sprawdzić logi z dokładnie określonego momentu awarii?
Użyj --since i --until z precyzyjną datą i godziną, np. journalctl -u usługa --since "2026-10-06 14:30:00" --until "2026-10-06 14:35:00". Jeśli znasz tylko przybliżony czas, użyj wyrażeń względnych, np. --since "10 minutes ago".
Dlaczego journalctl --list-boots pokazuje tylko jeden wpis?
Oznacza to, że starsze logi bootowań są niedostępne. Przyczyną może być ograniczony rozmiar dziennika (SystemMaxUse w journald.conf), przechowywanie ulotne (Storage=volatile) lub niedawna reinstalacja systemu. Sprawdź konfigurację journald w /etc/systemd/journald.conf.