journalctl: analiza logów systemd i trwałe przechowywanie journala

Serwer, z którym coś jest nie tak, zwykle dawno już zapisał, co się stało. Problemem nie jest brak informacji, tylko ilość, w jakiej ona występuje. Kto uruchamia journalctl bez argumentów, ląduje na początku journala i przewija komunikaty sprzed wielu tygodni. Ten poradnik pokazuje, jak w trzech albo czterech poleceniach wyciąć dokładnie ten fragment, który należy do awarii.

Artykuł Tworzenie własnej usługi systemd wymienia podstawowe formy -u, -b i -f. Tutaj chodzi o wszystko, co przychodzi potem: okna czasowe, filtry, priorytety, formaty wyjścia, trwałe zachowywanie journala, limity rozmiaru, komunikaty jądra i gotowe wzorce wyszukiwania.

Wszystkie informacje odnoszą się do Debiana 13 (trixie), Debiana 12 (bookworm), Ubuntu 24.04 LTS oraz Ubuntu 22.04 LTS. Polecenia napisano z myślą o pracy jako root. Jeśli pracujesz na zwykłym koncie użytkownika, poprzedź każde polecenie słowem sudo.

Zanim cokolwiek zmienisz: droga powrotna

Czytanie journala jest bezpieczne, żadne polecenie wyszukiwania z tego artykułu niczego w systemie nie zmienia. Ryzykowne są dokładnie trzy rzeczy i wszystkie pojawiają się dopiero dalej.

Pełny system plików. Bez własnego limitu journal zajmuje do dziesięciu procent systemu plików, z pułapem czterech gigabajtów. Na małym nośniku pełny /var to krótka droga do serwera, który nie przyjmuje już żadnego logowania.

Literówka w konfiguracji. systemd ignoruje nieznane klucze, zamiast zatrzymać usługę. Twój limit stoi wtedy w pliku, ale nie działa, i nikt ci tego sam z siebie nie powie.

Pochopne sprzątanie. journalctl --vacuum-time=1d kasuje nieodwracalnie, także te dowody, których właśnie szukasz.

Droga ratunku na najgorszy przypadek: serwery root KVM i serwery dedykowane w KernelHoście nie mają IPMI ani iDRAC. Dostęp, który działa również bez sieci, to konsola VNC w panelu klienta. Wisi ona na warstwie wirtualizacji względnie na samym przyłączu, a nie na stosie sieciowym systemu gościa. Zaloguj się tam raz zawczasu i upewnij się, że znasz hasło konta root.

Inwentaryzacja w pięciu poleceniach

systemctl --version | head -n 1

systemctl is-active systemd-journald

journalctl --disk-usage

ls -d /var/log/journal /run/log/journal

df -h /var

Czwarte polecenie jest najważniejsze: odpowiada na pytanie, czy twój journal przetrwa restart, a dla nieistniejącego katalogu zgłasza No such file or directory. Wszystkie zmiany z tego artykułu trafią później do osobnego pliku w /etc/systemd/journald.conf.d/. Dostarczony przez dystrybucję /etc/systemd/journald.conf pozostaje nietknięty, a wycofanie zmian to dwa polecenia: skasuj plik, zrestartuj usługę.

Zawężaj okno czasowe, zamiast przewijać

Prawie każda awaria ma znacznik czasu. Od niego zaczyna się analiza, a nie od nazwy usługi.

journalctl --since "-30min"

journalctl --since "2026-09-02 03:10" --until "2026-09-02 03:20"

journalctl --since yesterday --until today

--since i --until mają skrócone formy -S i -U. Jako czas journalctl rozumie wartości bezwzględne w postaci 2026-09-02 03:10:00, same daty bez godziny (obowiązuje wtedy północ), słowa kluczowe yesterday, today, tomorrow i now, a także zapisy względne w rodzaju -1h, -30min czy 2 days ago.

Tkwi tu pułapka, która kosztuje sporo czasu: journalctl pracuje w czasie lokalnym serwera, aplikacje natomiast często logują w UTC. Kto bez sprawdzenia wstawi do --since znacznik czasu z logu aplikacji, latem szuka dwie godziny obok zdarzenia. Sprawdź strefę albo od razu każ wyświetlić wszystko w UTC:

timedatectl

journalctl --since "2026-09-02 01:10" --until "2026-09-02 01:20" --utc --no-pager

Kontrola skuteczności: jeśli wraca -- No entries --, okno jest albo za wąskie, albo strefa się nie zgadza. Rozciągnij okno próbnie do godziny, zanim zaczniesz wątpić w filtry.

Rozruchy jako okno czasowe

Często właściwym fragmentem nie jest zakres godzin, tylko jeden start systemu. -b bez wartości oznacza bieżący, -b -1 ten poprzedni.

journalctl --list-boots --no-pager

journalctl -b -1 -p err --no-pager

Lista pokazuje po jednym wierszu na każdy rozruch, wraz z indeksem, a bieżący nosi 0. Jeśli pojawia się tylko ten jeden wiersz, journal prawdopodobnie w ogóle nie jest zapisywany trwale. Wtedy -b -1 odpowiada na Debianie 13 komunikatem No journal boot entry found for the specified boot (-1), a na Ubuntu 24.04 komunikatem No journal boot entry found from the specified boot offset (-1). To nie usterka, tylko informacja, że nie ma tam czego szukać.

Filtrowanie według usługi, procesu i priorytetu

Jednostka i dlaczego jej nazwa musi się zgadzać co do znaku

journalctl -u nginx.service --since "-2h" --no-pager

-u porównuje na równość, a nie na podobieństwo. Powstaje z tego wyjątkowo nieprzyjemny błąd, bo nie generuje żadnego komunikatu: journalctl -u mysql zwraca na systemie Debian z MariaDB -- No entries --, choć journal jest pełen komunikatów bazy danych. mysql.service jest tam tylko aliasem na mariadb.service. systemctl takie aliasy rozwiązuje, journal zapisuje pod prawdziwą nazwą. Dostajesz więc błędną odpowiedź, która na żaden błąd nie wygląda.

Prawdziwą nazwę weź z samego journala. -F wypisuje wszystkie wartości, jakie dane pole kiedykolwiek tam przyjęło:

journalctl -F _SYSTEMD_UNIT | sort | grep -i sql

-u przyjmuje poza tym wzorce, co całą sprawę rozbraja:

journalctl -u "mysql*" -u "mariadb*" -n 60 --no-pager

To samo sprawdzenie warto zrobić na Ubuntu 24.04 dla SSH, bo usługa startuje tam przez aktywację socketem, a logowania niekoniecznie stoją pod spodziewaną nazwą:

journalctl -F _SYSTEMD_UNIT | grep -i ssh

Identyfikator zamiast jednostki

Obok jednostki istnieje identyfikator nadawcy, czyli to, co klasyczny syslog prowadzi jako nazwę programu. Filtrem do tego jest -t:

journalctl -t sshd -t sshd-session -n 50 --no-pager

Dlaczego dwa? OpenSSH od wersji 9.8 wydziela sesje do osobnego procesu sshd-session. Na Debianie 13 (OpenSSH 10.0) pod -t sshd stoi więc już tylko to, że usługa nasłuchuje, podczas gdy każde logowanie leży pod -t sshd-session. Debian 12 (9.2), Ubuntu 24.04 (9.6) i Ubuntu 22.04 (8.9) tego podziału nie znają. Kto na Debianie 13 filtruje wyłącznie po -t sshd, uzna za spokojny serwer, na którym właśnie protokołowana jest każda próba. Solidniejsza jest droga przez jednostkę, bo procesy potomne należą do tej samej:

journalctl -u ssh --since "-24h" --no-pager

Dowolne pola i sposób ich łączenia

Każdy wpis niesie pola, które możesz zapisać wprost jako filtr, na przykład _COMM (nazwa programu), _PID, _UID, _SYSTEMD_UNIT albo _TRANSPORT. Reguły ich łączenia bywają błędnie rozumiane:

• Dwa filtry na różne pola łączą się przez I.
• Dwa filtry na to samo pole łączą się przez LUB.
• Pojedynczy znak plusa między dwiema grupami łączy te grupy przez LUB.

journalctl _SYSTEMD_UNIT=ssh.service _UID=0 --since "-1h" --no-pager

journalctl _SYSTEMD_UNIT=ssh.service + _SYSTEMD_UNIT=nginx.service --since "-1h" --no-pager

Nazwy pól zapisuje się wielkimi literami, a porównanie obejmuje pełną wartość. journalctl unit=nginx nie jest więc filtrem na fragment tekstu, tylko błędem składni, który journalctl kwituje komunikatem Failed to add match.

Priorytety

Każdy wpis niesie stopień pilności od 0 do 7. -p filtruje po nim, zawsze łącznie ze wszystkimi stopniami pilniejszymi: -p err pokazuje także crit, alert i emerg.

journalctl -b -p err --no-pager

journalctl -u nginx.service -p 2..4 --since "-24h" --no-pager

A teraz pułapka, na której filtrowanie po priorytecie regularnie się wykłada: to, co usługa pisze na standardowe wyjście, ląduje domyślnie w journalu jako info, nawet jeśli stało na standardowym wyjściu błędów. Program, który wypisuje wyjątek razem ze śladem stosu, pojawia się przez to jako nieszkodliwy komunikat z pracy systemu, a -p err go ukrywa. Właściwy stopień dostają tylko programy, które piszą wprost do interfejsu journala albo poprzedzają swoje wiersze prefiksem syslog w rodzaju <3>. Przy własnych usługach filtruj więc po jednostce i po tekście, przy usługach systemowych i przy jądrze -p jest jak najbardziej przydatne.

Wyszukiwanie w tekście

journalctl -u nginx.service --since "-24h" --grep "upstream timed out" --no-pager

--grep (w skrócie -g) przeszukuje wyłącznie tekst komunikatu, a nie pozostałe pola. Wielkość liter jest automatycznie pomijana tak długo, jak wzorzec zapisany jest w całości małymi literami; gdy tylko pojawi się wielka litera, porównanie staje się dokładne. Jedno i drugie wymusisz przez --case-sensitive=yes albo --case-sensitive=no. Wyrażenia regularne są dozwolone, pionowa kreska działa więc jako LUB.

Śledzenie logu na żywo

-f podczepia się na końcu journala i pokazuje nowe wiersze, gdy tylko nadchodzą. Sens ma to niemal wyłącznie z filtrem, inaczej przelatuje przez ekran pół systemu. -n określa, ile wcześniejszych wierszy pojawi się na początku; bez podanej wartości jest ich dziesięć. Kończysz kombinacją Ctrl+C.

journalctl -u nginx.service -f -n 100

journalctl -f -u nginx.service -u php8.2-fpm.service

journalctl -f -p warning

Typowy przebieg przy odtwarzalnym błędzie: w pierwszej sesji czytasz na bieżąco, w drugiej wywołujesz błąd. Przy bardzo szerokich wierszach pomaga -o cat, bo pojawia się wtedy sam tekst komunikatu, bez znacznika czasu i bez nadawcy.

Kontrola skuteczności: jeśli przy wywołaniu nie przychodzi zupełnie nic, usługa nie loguje do journala, tylko do własnego pliku. Przy serwerach WWW i bazach danych to sytuacja normalna. Droga prowadzi wtedy przez konfigurację aplikacji, a nie przez kolejne opcje journalctl.

Formaty wyjścia

Format domyślny jest pomyślany dla człowieka przy terminalu. Do zestawiania z innymi logami, do potoków i do analiz są lepsze. Przełączasz je przez -o:

journalctl -u ssh.service -n 1 -o verbose --no-pager

To jedno polecenie jest warte więcej niż każda lista pól w poradniku: widzisz, jakie pola faktycznie niosą twoje wpisy, i każdego z nich możesz potem użyć jako filtra. Uzupełniają to cztery opcje:

• --no-pager wyłącza pager. W skryptach i przed każdym potokiem jest obowiązkowa, inaczej wywołanie czeka na klawisz, którego nikt nie naciśnie.
• -r odwraca kolejność, najnowsze wiersze stoją na górze.
• -e skacze w pagerze od razu na koniec.
• -x dopisuje przy własnych komunikatach systemd wyjaśniający tekst z katalogu.

Przez --output-fields= da się zredukować wyjście do interesujących pól. Działa to tylko przy verbose, json i formatach pokrewnych:

journalctl -u ssh.service --since "-1h" -o json --output-fields=MESSAGE,_PID --no-pager

Zachowywanie journala mimo restartów

O tym, czy journal przetrwa restart, decyduje ustawienie domyślne Storage=auto według prostej reguły: jeśli /var/log/journal istnieje, zapis idzie tam i wszystko zostaje zachowane. Jeśli nie istnieje, wszystko ląduje w pamięci RAM pod /run/log/journal i po najbliższym restarcie znika. Nie zdawaj się na dystrybucję, między wariantami instalacji a obrazami chmurowymi występują oba stany. Journal w pamięci RAM to najczęstsze wyjaśnienie tego, że po awarii nikt już nie potrafi powiedzieć, co było wcześniej.

Gdy przestawiasz to ustawienie, ustaw limit w tym samym kroku. Z doświadczenia wiadomo, że później już się tego nie robi:

mkdir -p /etc/systemd/journald.conf.d

cat > /etc/systemd/journald.conf.d/10-kh-journal.conf <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=500M
SystemKeepFree=1G
MaxRetentionSec=1month
EOF

systemctl restart systemd-journald

journalctl --flush

Storage=persistent zakłada katalog samodzielnie, mkdir nie jest do tego potrzebne. journalctl --flush przenosi to, co leży jeszcze w /run, do /var/log/journal.

Kontrola skuteczności, w tej kolejności:

systemd-analyze cat-config systemd/journald.conf | grep -v '^#'

ls -d /var/log/journal

journalctl -u systemd-journald -b -n 20 --no-pager

Pierwsze polecenie pokazuje obowiązującą konfigurację z pliku głównego i ze wszystkich plików uzupełniających, czyli to, co usługa naprawdę wczytała. Trzecie to test na literówki: jeśli stoi tam wiersz z Unknown key, twoje ustawienie nie działa. Zależnie od wersji systemd brzmi on Unknown key name 'SystemMaxUsage' in section 'Journal', ignoring albo Unknown key 'SystemMaxUsage' in section [Journal], ignoring.

Ostatecznym dowodem jest prawdziwy restart. Po nim journalctl --list-boots musi pokazać co najmniej dwa wiersze, a journalctl -b -1 -n 20 musi zwrócić wpisy. Kto woli założyć katalog ręcznie, idzie następującą drogą. Wywołanie systemd-tmpfiles ustawia przy tym właściciela, uprawnienia oraz listy dostępu, które pozwalają czytać właściwym grupom:

mkdir -p /var/log/journal

systemd-tmpfiles --create --prefix /var/log/journal

systemctl restart systemd-journald

Czytanie bez konta root

Zwykły użytkownik widzi wyłącznie własne komunikaty i dostaje do tego wskazówkę Hint: You are currently not seeing messages from other users and the system. wraz z odesłaniem do grup, które mogą czytać wszystko. Na Debianie i Ubuntu jest to zwykle adm:

usermod -aG adm nazwauzytkownika

Kontrola skuteczności: przynależność do grupy obowiązuje dopiero w nowej sesji logowania. Wyloguj się więc, zaloguj ponownie, a potem id -nG i journalctl -n 5. Jeśli wskazówka zniknie i pojawią się komunikaty systemowe, udało się.

Ogranicz rozmiar, zanim zrobi to nośnik

Dostarczony przez dystrybucję /etc/systemd/journald.conf wymienia wszystkie klucze jako zakomentowane wiersze wraz z ich wartościami domyślnymi i jest przez to najpewniejszym źródłem wiedzy o tym, co w twoim systemie właśnie obowiązuje. Po każdej zmianie potrzebne jest systemctl restart systemd-journald, a potem wynik pokazuje journalctl --disk-usage.

Przy działaniu doraźnym na pełnym nośniku obowiązuje kolejność, o którą wielu się potyka: opcje sprzątania ruszają wyłącznie zamknięte pliki journala, nigdy tego aktualnie aktywnego. Bez wcześniejszej rotacji pozornie nic się nie dzieje, a wyjście brzmi mniej więcej Vacuuming done, freed 0B of archived journals.

journalctl --rotate

journalctl --vacuum-time=7d

Więcej na ten temat, razem z pozostałymi pożeraczami miejsca, znajdziesz w artykule Pełny dysk w Linuksie.

Drugim powodem brakujących wierszy jest wbudowane ograniczanie tempa przez RateLimitIntervalSec i RateLimitBurst: jeśli usługa pisze w krótkim czasie bardzo wiele komunikatów, journald odrzuca nadmiar i odnotowuje to wierszem zawierającym słowo Suppressed. Gdy log ma luki, choć usługa dowodnie działała, szukaj najpierw właśnie tego:

journalctl -b --grep "Suppressed" --no-pager

Komunikaty jądra: journalctl -k i dmesg

-k pokazuje wyłącznie komunikaty jądra i zawiera przy tym w sobie -b, ogranicza więc wyjście automatycznie do bieżącego rozruchu. Kto po restarcie szuka przyczyny, musi zażądać poprzedniego wprost:

journalctl -k -p err --no-pager

journalctl -k -b -1 --no-pager

Różnica wobec dmesg polega na miejscu przechowywania. dmesg czyta bufor pierścieniowy jądra: ograniczony, przepełnia się, po restarcie pusty. Journal zachowuje te same komunikaty, o ile jest trwały. Dla wczorajszego incydentu journalctl -k jest więc jedynym wiarygodnym źródłem. Do tego dwie uwagi z praktyki: dmesg -T przelicza sekundy od startu na godziny i po długim czasie pracy lekko się myli, journal prowadzi zawsze prawdziwą godzinę. A kernel.dmesg_restrict we wszystkich czterech dystrybucjach ma wartość 1, więc wywołanie bez konta root kończy się komunikatem Operation not permitted.

Dlaczego wiele serwerów nie ma już /var/log/syslog

Journal nie jest dodatkiem do klasycznych plików tekstowych, tylko ich zamiennikiem. /var/log/syslog i /var/log/auth.log nie powstają za sprawą systemd, tylko za sprawą dodatkowej usługi syslog, zwykle rsysloga. To osobny pakiet i w instalacjach minimalnych Debiana 12 oraz Debiana 13 nie jest już domyślnie instalowany. W obrazach serwerowych Ubuntu 22.04 i 24.04 jest obecny.

ls -l /var/log/syslog /var/log/auth.log

systemctl status rsyslog --no-pager

Jeśli nie zainstalowano żadnej usługi syslog, drugie polecenie odpowiada Unit rsyslog.service could not be found. To wyjaśnia trzy obserwacje za jednym zamachem: poradniki z tail -f /var/log/syslog kończą się błędem tail: cannot open '/var/log/syslog' for reading: No such file or directory, szukanie prób logowania w /var/log/auth.log trafia w próżnię, a fail2ban musi pobierać swoje zdarzenia z journala. Jak się to ustawia, opisuje artykuł Konfiguracja fail2ban.

Doinstalowywanie rsysloga tylko dlatego, że jest się przyzwyczajonym do tych plików, rzadko się opłaca: zapisujesz wtedy wszystko podwójnie i potrzebujesz dodatkowo działającej reguły logrotate. Sens ma to wtedy, gdy logi mają iść do systemu centralnego.

Gotowe wzorce wyszukiwania na sytuację awaryjną

Usługa padła albo ciągle się restartuje

systemctl list-units --type=service --state=failed --no-pager

journalctl -b -p err --no-pager

journalctl -b --grep "Main process exited|Failed with result|Start request repeated" --no-pager

Trzeci wiersz znajduje komunikaty, którymi systemd kwituje awarie i swój wbudowany hamulec startowy. Gdy zrzut pamięci po awarii staje się interesujący, najpierw ten plik wyjaśnia, kto za niego odpowiada:

cat /proc/sys/kernel/core_pattern

Jeśli stoi tam wywołanie systemd-coredump, istniejące zrzuty wymienia coredumpctl list. Jeśli stoi coś innego albo samo core, odpowiada za to inna obsługa, a coredumpctl pozostaje pusty.

Brak pamięci

journalctl -k -b --grep "Out of memory|oom-kill" --no-pager

journalctl --since "-7d" --grep "Out of memory|oom-kill" --no-pager

journalctl -u systemd-oomd --since "-7d" --no-pager

Drugie polecenie świadomie rezygnuje z -k i szuka dzięki temu ponad granicami rozruchów. Trzecie dotyczy Ubuntu 22.04 i 24.04, gdzie systemd-oomd działa fabrycznie i kończy całe control groups, zanim jądro zdąży zareagować; na Debianie ta usługa nie należy do wyposażenia standardowego. Jak odróżnić te komunikaty od siebie, opisuje artykuł Konfiguracja swapa i zapobieganie awariom z braku pamięci.

Nieudane logowania

journalctl -u ssh --since "-24h" --grep "Failed password|Invalid user" --no-pager

Ciekawszy niż pojedyncze wiersze jest rozkład. Poniższy wiersz zlicza adresy źródłowe i sortuje je malejąco:

journalctl -u ssh --since "-24h" -g "Failed password" -o cat --no-pager | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

Sztuczka polega na liczeniu od końca: komunikat kończy się zawsze na from ADRES port NUMER ssh2, czwarte pole od końca to więc adres, niezależnie od tego, czy przed nim stała prawdziwa, czy zmyślona nazwa użytkownika, i niezależnie od tego, czy chodzi o IPv4, czy IPv6. -o cat jest przy tym obowiązkowe, bo inaczej znacznik czasu i nadawca przesuwają numerację pól. Kontrpróba dla udanych logowań:

journalctl -u ssh --since "-7d" -g "Accepted (publickey|password)" -o cat --no-pager

Co było o 03:14 i co działo się wcześniej?

journalctl --since "2026-09-02 03:10" --until "2026-09-02 03:20" -o short-iso --no-pager

journalctl -b -1 -n 100 --no-pager

journalctl _PID=1234 --since "-1h" --no-pager

Drugie polecenie pokazuje ostatnie sto wierszy przed poprzednim końcem. Uporządkowane wyłączanie poznasz po tym, że systemd kończy tam usługi jedna po drugiej. Jeśli wyjście urywa się w środku normalnej pracy, była to awaria, twardy reset albo zanik zasilania. Przy trzecim poleceniu obowiązuje zasada: numery procesów są używane ponownie, bez okna czasowego możesz zmieszać w jednym wyjściu dwa różne programy.

Typowe błędy i ich rozwiązania

No journal files were found.: nie ma żadnych czytelnych plików journala. Albo systemd-journald nie działa, albo jako zwykły użytkownik nie masz dostępu. Najpierw sprawdź systemctl is-active systemd-journald, potem powtórz jako root.

-- No entries --: filtr niczego nie znalazł. To nie komunikat błędu, tylko poprawna odpowiedź na być może błędne pytanie. Trzy najczęstsze przyczyny: nazwa jednostki, która jest tylko aliasem, zbyt wąskie okno czasowe oraz -k, choć szukany komunikat wcale nie pochodził od jądra.

Hint: You are currently not seeing messages from other users and the system.: czytasz jako zwykły użytkownik. Dopisz konto do grupy adm i zaloguj się ponownie albo od razu pracuj przez sudo.

No journal boot entry found for the specified boot (-1) względnie No journal boot entry found from the specified boot offset (-1): w journalu nie ma zapisanego żadnego wcześniejszego rozruchu. Sytuacja normalna, dopóki journal leży wyłącznie w pamięci RAM.

Failed to add match: wyrażenie nie jest poprawnym filtrem pola. Nazwy pól zapisuje się wielkimi literami, a porównanie obejmuje pełną wartość. Za trafienia częściowe w tekście komunikatu odpowiada --grep.

Unknown key name 'SystemMaxUsage' in section 'Journal', ignoring: literówka w pliku uzupełniającym. systemd przeocza ten wiersz i pracuje dalej z wartością domyślną. Znajdziesz to przez journalctl -u systemd-journald -b.

Vacuuming done, freed 0B of archived journals: nie było czego kasować w archiwum, bo miejsce zajmuje plik aktywny. Najpierw journalctl --rotate, potem sprzątaj ponownie.

Operation not permitted przy dmesg: kernel.dmesg_restrict ma wartość 1. Powtórz jako root albo przejdź na journalctl -k.

File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing.: serwer padł twardo, gdy plik journala był otwarty. journald dokleja do starej nazwy tyldę i zaczyna nowy plik. Stan wszystkich plików sprawdza journalctl --verify, które wypisuje na każdy plik jeden wiersz z PASS; zastrzeżenia dotyczą z reguły dokładnie tych starych plików z tyldą.

Różnice między Debianem 13, Debianem 12, Ubuntu 24.04 i 22.04

• Debian 13 (trixie): systemd 257. OpenSSH 10.0, logowania stoją pod identyfikatorem sshd-session. rsyslog w instalacjach minimalnych nieobecny, brakuje wtedy /var/log/syslog. systemd-oomd poza wyposażeniem standardowym.
• Debian 12 (bookworm): systemd 252. OpenSSH 9.2, wszystko pod sshd. rsyslog obecny zależnie od wariantu instalacji, /var/log/syslog nie jest więc gwarantowany. systemd-oomd poza wyposażeniem standardowym.
• Ubuntu 24.04 LTS: systemd 255. OpenSSH 9.6, wszystko pod sshd. rsyslog obecny. systemd-oomd aktywny fabrycznie. SSH działa przez aktywację socketem, sprawdź więc w journalu faktyczną nazwę jednostki.
• Ubuntu 22.04 LTS: systemd 249. OpenSSH 8.9, wszystko pod sshd. rsyslog obecny. systemd-oomd aktywny fabrycznie. Najstarsza z czterech wersji systemd, brakuje tam pojedynczych nowszych formatów wyjścia.

We wszystkich czterech systemach to, co istotne, jest takie samo: te same filtry, te same priorytety, ten sam plik konfiguracyjny i ta sama reguła, że o trwałości decyduje /var/log/journal.

Kolejność, która sprawdza się na co dzień: najpierw okno czasowe, potem jednostka, potem priorytet, a na końcu wzorzec wyszukiwania. Kto tak postępuje, przy większości awarii nie potrzebuje nawet trzech poleceń. A kto raz zadba o to, żeby journal przetrwał restarty i mimo to miał górny limit, odpowie na pytanie o przyczynę także wtedy, gdy serwer dawno znów działa.