Polecenie journalctl: użycie, logi według usług i porządkowanie rozmiaru dziennika

Polecenie journalctl to narzędzie do wybierania i czytania logów, które usługi i jądro zostawiają w dzienniku systemd. W Linuksie z systemd te logi zbiera w dzienniku systemd-journald. Po przeczytaniu logów według usługi, czasu i priorytetu na serwerze AlmaLinux 9 i na serwerze Debian 12 okazało się, że zwykłe konto widzi tylko własne logi, a serwer trzymający dziennik w pamięci nie pozwala wybrać poprzedniego uruchomienia.

Poniższe wyniki pochodzą z obu serwerów. Nazwy hostów, konta, identyfikatory uruchomienia, numery procesów na serwerze AlmaLinux i wydanie pakietu systemd zamieniono na przykładowe wartości, a oba serwery wypisywały czas w UTC.

1️⃣ Jak używać polecenia journalctl i czytać najnowsze logi

Uruchomione bez opcji journalctl otwiera dziennik w less od najstarszego wiersza, więc aby zobaczyć najnowsze logi, ustaw liczbę wierszy przez -n. Jeśli pominiesz liczbę po -n, pojawi się 10 wierszy.

journalctl -n 3

Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Deactivated successfully.
Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Consumed 3.934s CPU time.
Oct 28 07:14:07 server1 sudo[851987]: pam_unix(sudo:session): session closed for user user

Każdy wiersz składa się z czasu, nazwy hosta, programu, który zapisał log, wraz z numerem procesu oraz komunikatu. Opcja -r odwraca kolejność, tak że najnowszy wiersz trafia na górę. W logu crond na serwerze AlmaLinux na górze był wiersz CMDEND zapisany jako ostatni.

journalctl -r -u crond -n 3

Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-f nie kończy działania po ostatnim wierszu, tylko dalej wypisuje nowo przychodzące wiersze. Na serwerze Debian 12 z -q i -t myapp na ekranie został ostatni wiersz loggera, a loggerem zapisano jeszcze dwa wiersze. Oba wiersze pojawiły się zaraz pod nim.

journalctl -q -f -n 1 -t myapp

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test
Oct 28 07:14:35 server2 myapp[347881]: follow line 1
Oct 28 07:14:36 server2 myapp[347877]: follow line 2

-f nie zatrzymuje się, dopóki nie naciśniesz Ctrl+C, więc używaj go do śledzenia logu podczas restartu usługi.

W less wiersze szersze niż ekran są ucinane z prawej strony, a ucięty fragment zobaczysz strzałkami. Wyjście przekazane do potoku lub pliku nie przechodzi przez less. Aby wypisać je od razu w terminalu bez less, dodaj --no-pager.

2️⃣ Logi journalctl według usług

Najnowsze wiersze mieszają logi wielu usług, więc aby zobaczyć log jednej usługi, podaj nazwę jednostki przez -u. Końcówkę .service w nazwie jednostki można pominąć.

journalctl -u crond -n 4

Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

Jeśli wpiszesz -u dwa razy, logi obu usług pojawią się przemieszane w kolejności czasu. Po wybraniu razem crond i nginx od 08:00 do 08:15 18 października na serwerze AlmaLinux po czterech wierszach crond o 08:01 przyszły dwa wiersze nginx reload o 08:12.

journalctl -u nginx -u crond --since '2026-10-18 08:00' --until '2026-10-18 08:15'

Oct 18 08:01:01 server1 CROND[381522]: (root) CMD (run-parts /etc/cron.hourly)
Oct 18 08:01:01 server1 run-parts[381528]: (/etc/cron.hourly) starting 0anacron
Oct 18 08:01:01 server1 run-parts[381534]: (/etc/cron.hourly) finished 0anacron
Oct 18 08:01:01 server1 CROND[381518]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 18 08:12:30 server1 systemd[1]: Reloading nginx - high performance web server...
Oct 18 08:12:30 server1 systemd[1]: Reloaded nginx - high performance web server.

systemctl status pokazuje pod stanem usługi tylko ostatnie 10 wierszy logu, więc starsze logi sprawdzaj przez journalctl -u. Zaraz po wykonaniu systemctl restart dla usługi uruchom journalctl -u, aby sprawdzić log startu.

Logi zapisane loggerem przez skrypty lub zadania crona znajdziesz po etykiecie (identyfikatorze), a nie po jednostce. Po -t wpisz tę samą nazwę, która była podana w -t loggera.

logger -t myapp 'journalctl test message'

Na serwerze Debian 12 logger nic nie wypisał na ekranie, a zapisane wiersze znaleziono przez -t myapp.

journalctl -q -t myapp

Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

-g zostawia tylko wiersze, których komunikat zawiera określony tekst. Jeśli wpiszesz szukany tekst całkiem małymi literami, wielkość liter nie ma znaczenia.

journalctl -u crond -g anacron -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron

-n liczy wiersze, zanim -g je przefiltruje, dlatego z dwóch ostatnich wierszy crond został tylko ten z anacron.

3️⃣ Logi według zakresu czasu i uruchomienia

--since i --until wyznaczają początek i koniec wypisywanego zakresu czasu. Jeśli między datą a godziną jest spacja, ujmij wartość w pojedyncze cudzysłowy.

Na serwerze AlmaLinux ostatnie 2 godziny zaczynały się od wierszy crond zapisanych o 06:01; poniżej są cztery pierwsze z nich.

journalctl -u crond --since '-2h' | head -4

Oct 28 06:01:01 server1 CROND[802930]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 06:01:01 server1 run-parts[802936]: (/etc/cron.hourly) starting 0anacron
Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-b zostawia tylko logi od bieżącego uruchomienia. Gdy szukasz przyczyny restartu serwera, najpierw sprawdź na liście uruchomień, czy zostały logi z poprzedniego uruchomienia.

journalctl -b -u crond -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

--list-boots wypisuje dla każdego uruchomienia zachowanego w dzienniku numer, identyfikator uruchomienia i czas pierwszego i ostatniego wiersza.

journalctl --list-boots

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
  0 4f1c2a9be0d34c7a8e6b5d20c1f3a7e9 Sat 2026-10-17 08:29:26 UTC Wed 2026-10-28 07:16:10 UTC

Serwer AlmaLinux nie trzyma dziennika na dysku, więc miał tylko jeden zapis uruchomienia. Dlatego -b -1 dla poprzedniego uruchomienia zostawiło tylko komunikat i się zakończyło.

journalctl -b -1

Specifying boot ID or boot offset has no effect, no persistent journal was found.

Logi z poprzedniego uruchomienia można czytać przez -b -1 tylko na serwerach, które zapisują dziennik na dysku (/var/log/journal).

4️⃣ Logi błędów i logi jądra w journalctl

-p wybiera wiersze według priorytetu logu. Gdy podasz jeden poziom, pojawi się ten poziom i wszystkie ważniejsze, a poziom można zapisać nazwą albo liczbą.

Po zapisaniu loggerem jednego wiersza na poziomie err i wybraniu przez -p err wiersz notice z tą samą etykietą (journalctl test message) odpadł i został tylko wiersz err.

logger -t myapp -p user.err 'journalctl error test'; journalctl -q -t myapp -p err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

Połączenie dwóch poziomów dwiema kropkami wypisuje tylko ten zakres. Przy warning..err zostają tylko poziomy ostrzeżenia i błędu.

journalctl -q -t myapp -p warning..err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

-k zostawia tylko komunikaty jądra i wypisuje tylko wiersze od bieżącego uruchomienia.

journalctl -k -n 3

Oct 26 10:14:25 server1 systemd-rc-local-generator[96245]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 10:47:57 server1 systemd-rc-local-generator[512078]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 11:01:10 server1 systemd-rc-local-generator[520023]: /etc/rc.d/rc.local is not marked executable, skipping.

Trzy ostatnie wiersze -k na serwerze AlmaLinux były wszystkie wierszami systemd-rc-local-generator. To komunikaty zapisane do bufora logów jądra, więc są przechowywane z _TRANSPORT równym kernel i pojawiają się także przy -k.

5️⃣ Formaty wyjścia journalctl

-o zmienia format każdego wiersza. Domyślne short jest prawie takie samo jak plik syslog, a short-iso zamienia czas na format ISO 8601 razem ze strefą czasową. Po przełączeniu na short-iso na serwerze AlmaLinux na końcu czasu pojawiło się +0000.

journalctl -u crond -n 2 -o short-iso

2026-10-28T07:01:01+0000 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
2026-10-28T07:01:01+0000 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

cat usuwa czas i nazwę hosta i wypisuje tylko komunikat, więc używaj go, gdy przekazujesz komunikaty do grep lub innego programu.

journalctl -u crond -n 2 -o cat

(/etc/cron.hourly) starting 0anacron
(root) CMDEND (run-parts /etc/cron.hourly)

json i json-pretty wypisują pola zapisane w dzienniku jako nazwy i wartości. Gdy wybierasz pola przez --output-fields, pola kursora, czasu i identyfikatora uruchomienia zawsze idą razem. Nawet gdy na serwerze Debian 12 wybrano tylko cztery pola, pojawiły się też __CURSOR, _BOOT_ID i dwa pola czasu.

journalctl -q -t myapp -n 1 -o json-pretty --output-fields=MESSAGE,PRIORITY,SYSLOG_IDENTIFIER,_PID

{
	"__REALTIME_TIMESTAMP" : "1793171676664200",
	"_PID" : "347877",
	"SYSLOG_IDENTIFIER" : "myapp",
	"MESSAGE" : "follow line 2",
	"__CURSOR" : "s=2a6f0c1d9e8b47a3b5c4d3e2f1a0b9c8;i=1a2b3;b=b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47;m=17cf8fe36f5;t=65ee150cf1188;x=1f2e3d4c5b6a7980",
	"_BOOT_ID" : "b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47",
	"PRIORITY" : "5",
	"__MONOTONIC_TIMESTAMP" : "1636264982261"
}

6️⃣ Miejsce zapisu dziennika i porządkowanie jego rozmiaru

O tym, czy dziennik jest w pamięci, czy na dysku, decyduje wartość Storage= w journald.conf. Domyślne auto zapisuje na dysku, jeśli istnieje folder /var/log/journal, a w przeciwnym razie w pamięci (/run/log/journal).

Serwer AlmaLinux nie miał folderu /var/log/journal, więc dziennik był tylko w /run/log/journal.

ls -ld /var/log/journal /run/log/journal

ls: cannot access '/var/log/journal': No such file or directory
drwxr-sr-x+ 4 root systemd-journal 80 Oct 17 08:30 /run/log/journal

Serwer Debian 12 miał oba foldery, a dziennik gromadził się na dysku.

ls -ld /var/log/journal /run/log/journal

drwxr-sr-x+ 2 root systemd-journal   40 Oct  9 08:43 /run/log/journal
drwxr-sr-x+ 4 root systemd-journal 4096 Sep 24 12:52 /var/log/journal

Aby zachować logi po restarcie, zmień Storage= w journald.conf na persistent i uruchom ponownie systemd-journald. Według oficjalnego podręcznika folder /var/log/journal tworzy się w razie potrzeby automatycznie. Na potrzeby tego artykułu ustawień nie zmieniano.

Dziennik na dysku jest jak czarna skrzynka samolotu, którą wyjmuje się i odczytuje po zdarzeniu.

--disk-usage wypisuje łączny rozmiar zarchiwizowanych plików dziennika i plików używanych w tej chwili. Na zwykłym koncie serwera Debian 12, z komunikatem [Hint] na górze ukrytym przez -q, wynik był jednym wierszem: 6.6M.

journalctl -q --disk-usage

Archived and active journals take up 6.6M in the file system.

Maksymalny rozmiar dziennika zapisywanego na dysku ustawia się przez SystemMaxUse=. Bez wartości limit wynosi 10% rozmiaru systemu plików (najwyżej 4G), a w journald.conf serwera Debian 12 było wpisane 50M.

grep -v '^#' /etc/systemd/journald.conf | grep -v '^$'

[Journal]
SystemMaxUse=50M

Aby od razu zmniejszyć stare dzienniki, ustaw rozmiar do zachowania przez --vacuum-size albo okres do zachowania przez --vacuum-time. Oba polecenia usuwają pliki dziennika, więc w tym artykule ich nie uruchamiano.

journalctl --vacuum-size=200M

--vacuum-size=200M usuwa zarchiwizowane pliki dziennika, zaczynając od najstarszych, aż łączny rozmiar spadnie poniżej 200M.

journalctl --vacuum-time=2weeks

--vacuum-time=2weeks usuwa pliki archiwum zawierające tylko wiersze starsze niż 2 tygodnie.

vacuum usuwa tylko zarchiwizowane pliki i zostawia pliki w użyciu, więc nawet po jego wykonaniu liczba z --disk-usage może nie spaść do podanego rozmiaru.

Logi tekstowe w /var/log zapisuje rsyslog, który działa niezależnie od journald. Dlatego oba logi czyta się i zarządza nimi inaczej.

7️⃣ Uprawnienia do odczytu i opcje polecenia journalctl

🔲 Uprawnienia do odczytu

Po uruchomieniu journalctl z konta innego niż root na górze pojawia się tekst [Hint] i widać tylko logi zapisane przez to konto. Przy szukaniu logów nginx ze zwykłego konta na serwerze Debian 12 po komunikacie pojawiło się tylko [-- No entries --].

journalctl -u nginx -n 5

Hint: You are currently not seeing messages from other users and the system.
      Users in groups 'adm', 'systemd-journal' can see all messages.
      Pass -q to turn off this notice.
-- No entries --

Według id -nG to konto należało tylko do jednej grupy i nie było w grupach adm ani systemd-journal, o których mówi komunikat.

id -nG

user

Oficjalny podręcznik wyjaśnia, że konta z grup systemd-journal, adm i wheel mogą czytać cały dziennik. adm i wheel niosą też inne uprawnienia ustalone przez dystrybucję, a wheel często pozwala także na zadania administracyjne, więc dla konta, które tylko czyta logi, właściwa jest grupa systemd-journal.

usermod -aG systemd-journal user

Polecenia usermod dodającego grupę w tym artykule nie uruchamiano. Po dodaniu grupy zaloguj się ponownie i sprawdź grupy przez id -nG. Konto z uprawnieniami administratora również widzi wszystkie logi, gdy uruchomi sudo journalctl.

Tekst [Hint] ukrywa się przez -q. Nawet z -q widoczne logi to jednak tylko wiersze zapisane przez to konto. --user czyta dziennik użytkownika tego konta i działa tylko na serwerach zapisujących dziennik na dysku. Na serwerze Debian 12, który trzyma dziennik na dysku, pojawiły się wiersze systemd i loggera tego konta.

journalctl --user -n 3

Oct 28 07:12:35 server2 systemd[347665]: Reached target default.target - Main User Target.
Oct 28 07:12:35 server2 systemd[347665]: Startup finished in 181ms.
Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

🔲 Opcje polecenia journalctl

📌 Główne opcje: wyniki z tego artykułu

📎 Pozostałe opcje: według oficjalnego podręcznika

🔲 Symulator polecenia journalctl

W symulatorze poniżej możesz sam wpisywać polecenia, aby sprawdzić najnowsze logi, logi według usług, zakresy czasu, priorytety i formaty wyjścia.

🔢 FAQ & polecane treści

🧭 Polecenia informacji · ustawień systemu: polecane treści 8 artykułów · 2 źródła

🗂️ Polecenia informacji · ustawień systemu

▸📂 Informacje o systemie4

📄 Informacje o CPU · RAM · dysku · systemie 📄 uname · wersja jądra 📄 Polecenie free 📄 Polecenie uptime

▸📂 Ustawienia2

📄 Polecenie timedatectl 📄 Polecenie localectl

▸📂 Logi2

📄 logrotate 📄 Polecenie journalctl

▸🪐 Źródła2

📡 journalctl(1) — systemd 252 📡 journald.conf(5) — systemd 252

Linux · Informacje o systemie

Sprawdzanie CPU w Linuksie: polecenia do RAM, dysku i informacji o systemie

W Linuksie liczbę rdzeni CPU dostajesz od razu jednym wierszem: [nproc].

Czytaj wpis →Bieżąca treść

Linux · Informacje o systemie

Polecenia do sprawdzania wersji jądra Linux i jak sprawdzić wersję dystrybucji

Przy administrowaniu Linuksem czasem trzeba sprawdzić wersję jądra Linuksa i wersję dystrybucji.

Czytaj wpis →Bieżąca treść

Linux · Informacje o systemie

Polecenie free w Linuksie: sprawdzanie stanu pamięci

Polecenie free w Linuksie pokazuje użycie pamięci i wolną pamięć serwera, odczytując informacje o pamięci z /proc/meminfo.

Czytaj wpis →Bieżąca treść

Linux · Informacje o systemie

Polecenie uptime w Linuksie (czas pracy serwera & średnie obciążenie z 1, 5 i 15 minut)

Polecenie uptime w Linuksie pokazuje średnie obciążenie systemu i czas pracy serwera.

Czytaj wpis →Bieżąca treść

Linux · Ustawienia

Synchronizacja czasu serwera Linux: timedatectl (CentOS 7 i nowsze)

Ustawienie daty i godziny w Linuksie jest potrzebne, bo gdy czas jest błędny podczas pracy serwera, czasy danych w bazie, logów i wejść na serwer WWW mogą się nie zgadzać.

Czytaj wpis →Bieżąca treść

Linux · Ustawienia

[Linux] Polecenie localectl

Od CentOS 7 wiele poleceń jest dostępnych w zintegrowanej formie.

Czytaj wpis →Bieżąca treść

Linux · Logi

Logrotate w Linuksie: koncepcja i ustawienia

Logrotate w Linuksie, jak sugeruje wyrażenie „obracanie logów”, to połączenie słów log i rotate.

Czytaj wpis →Bieżąca treść

Linux · Logi

Polecenie journalctl: użycie, logi według usług i porządkowanie rozmiaru dziennika

Polecenie journalctl to narzędzie do wybierania i czytania logów, które usługi i jądro zostawiają w dzienniku systemd, a w Linuksie z systemd te logi zbiera w dzienniku systemd-journald.

Czytaj wpis →Bieżąca treść

📡journalctl(1) — systemd 252 📡journald.conf(5) — systemd 252

ℹ️ Informacja o linkach partnerskich
Treści tej witryny zawierają linki partnerskie. Jeśli odwiedzający kupi produkt lub usługę przez taki link, witryna otrzymuje od sprzedawcy prowizję. Kwota płacona przy tym przez kupującego ^{(podczas promocji spada↓)} nie wzrasta. Podane ceny, rabaty i dostępność odnoszą się do chwili pisania i mogą różnić się od stanu faktycznego, dlatego przed zakupem sprawdź je u sprzedawcy. Produkty wybieramy i oceniamy według własnych kryteriów, a prowizja nie wpływa ani na kolejność prezentacji, ani na treść ocen.