journalctl: Logs unter systemd auswerten und dauerhaft aufheben

Ein Server, bei dem etwas nicht stimmt, hat meist längst aufgeschrieben, was passiert ist. Das Problem ist nicht die fehlende Information, sondern die Menge, in der sie steht. Wer journalctl ohne Argumente aufruft, landet am Anfang des Journals und blättert durch Wochen alter Meldungen. Diese Anleitung zeigt, wie Sie in drei oder vier Befehlen genau den Ausschnitt herausschneiden, der zur Störung gehört.

Der Beitrag systemd-Service erstellen nennt die Grundformen -u, -b und -f. Hier geht es um alles, was danach kommt: Zeitfenster, Filter, Prioritäten, Ausgabeformate, das dauerhafte Aufheben des Journals, Größengrenzen, Kernelmeldungen und fertige Suchmuster.

Alle Angaben beziehen sich auf Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS und Ubuntu 22.04 LTS. Die Befehle sind für den Betrieb als root geschrieben. Wenn Sie als normaler Benutzer arbeiten, stellen Sie jedem Befehl sudo voran.

Bevor Sie etwas ändern: der Rückweg

Das Lesen des Journals ist ungefährlich, kein Suchbefehl in diesem Artikel verändert etwas am System. Riskant sind genau drei Dinge, und die kommen alle erst später.

Ein volles Dateisystem. Ohne eigene Obergrenze belegt das Journal bis zu zehn Prozent des Dateisystems, gedeckelt bei vier Gigabyte. Auf einem kleinen Datenträger ist ein volles /var der kurze Weg zu einem Server, der keine Anmeldung mehr annimmt.

Ein Tippfehler in der Konfiguration. systemd ignoriert unbekannte Schlüssel, statt den Dienst anzuhalten. Ihre Grenze steht dann in der Datei, wirkt aber nicht, und niemand sagt es Ihnen ungefragt.

Ein voreiliges Aufräumen. journalctl --vacuum-time=1d löscht unwiderruflich, auch die Belege, die Sie gerade suchen.

Der Rettungsweg für den schlimmsten Fall: Bei KVM-Rootservern und Dedicated Servern von KernelHost gibt es kein IPMI und kein iDRAC. Der Zugang, der auch ohne Netzwerk funktioniert, ist die VNC-Konsole im Kundenbereich. Sie hängt an der Virtualisierungsschicht beziehungsweise am Anschluss selbst, nicht am Netzwerkstack des Gastsystems. Melden Sie sich dort einmal vorher an, und vergewissern Sie sich, dass Sie das root-Passwort kennen.

Bestandsaufnahme in fünf Befehlen

systemctl --version | head -n 1

systemctl is-active systemd-journald

journalctl --disk-usage

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

df -h /var

Der vierte Befehl ist der wichtigste: Er beantwortet, ob Ihr Journal einen Neustart überlebt, und meldet für das jeweils nicht vorhandene Verzeichnis No such file or directory. Alle Änderungen in diesem Artikel landen später in einer eigenen Datei unter /etc/systemd/journald.conf.d/. Die ausgelieferte /etc/systemd/journald.conf bleibt unangetastet, und der Rückbau besteht aus zwei Befehlen: Datei löschen, Dienst neu starten.

Zeitfenster eingrenzen statt scrollen

Fast jede Störung hat einen Zeitstempel. Damit fängt die Auswertung an, nicht mit dem Dienstnamen.

journalctl --since "-30min"

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

journalctl --since yesterday --until today

--since und --until haben die Kurzformen -S und -U. Als Zeitangabe versteht journalctl absolute Werte in der Form 2026-09-02 03:10:00, Datumsangaben ohne Uhrzeit (dann gilt Mitternacht), die Schlüsselwörter yesterday, today, tomorrow und now sowie relative Angaben wie -1h, -30min oder 2 days ago.

Hier steckt eine Falle, die viel Zeit kostet: journalctl arbeitet in der Ortszeit des Servers, Anwendungen protokollieren dagegen oft in UTC. Wer einen Zeitstempel aus einem Anwendungslog unbesehen in --since einsetzt, sucht im Sommer zwei Stunden neben dem Ereignis. Prüfen Sie die Zone, oder lassen Sie sich gleich alles in UTC anzeigen:

timedatectl

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

Prüfschritt: Kommt -- No entries -- zurück, ist entweder das Fenster zu eng oder die Zone falsch. Ziehen Sie das Fenster testweise auf eine Stunde auf, bevor Sie an den Filtern zweifeln.

Bootvorgänge als Zeitfenster

Oft ist der passende Ausschnitt kein Uhrzeitbereich, sondern ein Systemstart. -b ohne Wert meint den laufenden, -b -1 den davor.

journalctl --list-boots --no-pager

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

Die Liste zeigt je Bootvorgang eine Zeile mit einem Index, der laufende trägt die 0. Erscheint nur diese eine Zeile, wird das Journal vermutlich gar nicht dauerhaft gespeichert. Dann antwortet -b -1 auf Debian 13 mit No journal boot entry found for the specified boot (-1) und auf Ubuntu 24.04 mit No journal boot entry found from the specified boot offset (-1). Kein Defekt, sondern die Ansage, dass dort nichts zu holen ist.

Nach Dienst, Prozess und Priorität filtern

Die Unit, und warum der Name genau stimmen muss

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

-u vergleicht auf Gleichheit, nicht auf Ähnlichkeit. Daraus entsteht ein besonders unangenehmer Fehler, weil er keine Fehlermeldung erzeugt: journalctl -u mysql liefert auf einem Debian-System mit MariaDB -- No entries --, obwohl das Journal voller Datenbankmeldungen ist. mysql.service ist dort nur ein Zweitname für mariadb.service. systemctl löst solche Zweitnamen auf, das Journal speichert unter dem echten Namen. Sie bekommen also eine falsche Antwort, die nach keinem Fehler aussieht.

Den echten Namen holen Sie sich aus dem Journal selbst. -F listet alle Werte auf, die ein Feld dort jemals angenommen hat:

journalctl -F _SYSTEMD_UNIT | sort | grep -i sql

-u akzeptiert außerdem Muster, was die Frage entschärft:

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

Dieselbe Prüfung lohnt auf Ubuntu 24.04 für SSH, weil der Dienst dort über eine Socket-Aktivierung startet und die Anmeldungen nicht zwingend unter dem erwarteten Namen stehen:

journalctl -F _SYSTEMD_UNIT | grep -i ssh

Bezeichner statt Unit

Neben der Unit gibt es den Absenderbezeichner, also das, was klassisches Syslog als Programmnamen führt. Der Filter dafür ist -t:

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

Warum zwei? OpenSSH lagert seit Version 9.8 die Sitzungen in einen eigenen Prozess sshd-session aus. Auf Debian 13 (OpenSSH 10.0) steht unter -t sshd deshalb nur noch, dass der Dienst lauscht, während jeder Anmeldevorgang unter -t sshd-session liegt. Debian 12 (9.2), Ubuntu 24.04 (9.6) und Ubuntu 22.04 (8.9) kennen diese Aufteilung nicht. Wer auf Debian 13 nur -t sshd filtert, hält einen Server für ruhig, auf dem gerade jeder Versuch protokolliert wird. Robuster ist der Weg über die Unit, denn die Kindprozesse gehören zur selben:

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

Beliebige Felder, und wie sie verknüpft werden

Jeder Eintrag trägt Felder, die Sie direkt als Filter schreiben können, etwa _COMM (Programmname), _PID, _UID, _SYSTEMD_UNIT oder _TRANSPORT. Die Verknüpfungsregeln werden oft falsch angenommen:

• Zwei Filter auf verschiedene Felder werden mit UND verknüpft.
• Zwei Filter auf dasselbe Feld werden mit ODER verknüpft.
• Ein einzelnes Pluszeichen zwischen zwei Gruppen verknüpft die Gruppen mit ODER.

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

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

Feldnamen stehen in Großbuchstaben, verglichen wird auf den vollständigen Wert. Ein journalctl unit=nginx ist deshalb kein Filter auf einen Teilstring, sondern ein Syntaxfehler, den journalctl mit Failed to add match quittiert.

Prioritäten

Jeder Eintrag trägt eine Dringlichkeitsstufe von 0 bis 7. -p filtert darauf, immer einschließlich aller dringenderen Stufen: -p err zeigt auch crit, alert und emerg.

journalctl -b -p err --no-pager

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

Und jetzt der Fallstrick, an dem die Prioritätsfilterung regelmäßig scheitert: Was ein Dienst auf die Standardausgabe schreibt, landet in der Voreinstellung als info im Journal, auch wenn es auf der Standardfehlerausgabe stand. Ein Programm, das eine Ausnahme samt Stacktrace ausgibt, erscheint damit als harmlose Betriebsmeldung, und -p err versteckt sie. Eine passende Stufe bekommen nur Programme, die direkt gegen die Journal-Schnittstelle schreiben oder ihren Zeilen ein Syslog-Präfix wie <3> voranstellen. Bei eigenen Diensten filtern Sie deshalb nach Unit und Text, bei Systemdiensten und beim Kernel ist -p sehr wohl brauchbar.

Textsuche

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

--grep (Kurzform -g) durchsucht ausschließlich den Meldungstext, nicht die übrigen Felder. Die Schreibweise wird automatisch ignoriert, solange das Muster durchgehend klein geschrieben ist; sobald ein Großbuchstabe vorkommt, wird exakt verglichen. Erzwingen lässt sich beides mit --case-sensitive=yes oder --case-sensitive=no. Reguläre Ausdrücke sind erlaubt, der senkrechte Strich wirkt also als ODER.

Dem Log live folgen

-f hängt sich an das Ende des Journals und zeigt neue Zeilen, sobald sie ankommen. Sinnvoll ist das fast nur mit Filter, sonst rauscht das halbe System durch. -n bestimmt, wie viele zurückliegende Zeilen zuerst erscheinen; ohne Angabe sind es zehn. Beendet wird mit Strg+C.

journalctl -u nginx.service -f -n 100

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

journalctl -f -p warning

Der übliche Ablauf für einen reproduzierbaren Fehler: in der ersten Sitzung mitlesen, in einer zweiten den Fehler auslösen. Bei sehr breiten Zeilen hilft -o cat, weil dann nur der Meldungstext ohne Zeitstempel und Absender erscheint.

Prüfschritt: Kommt beim Auslösen gar nichts an, protokolliert der Dienst nicht ins Journal, sondern in eine eigene Datei. Bei Webservern und Datenbanken ist das der Normalfall. Dann führt der Weg über die Konfiguration der Anwendung, nicht über weitere journalctl-Optionen.

Ausgabeformate

Das Standardformat ist auf Menschen am Terminal ausgelegt. Für den Abgleich mit anderen Logs, für Pipes und für Auswertungen gibt es passendere. Umgeschaltet wird mit -o:

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

Dieser eine Befehl ist mehr wert als jede Feldliste in einer Anleitung: Sie sehen, welche Felder Ihre Einträge tatsächlich tragen, und können jedes davon anschließend als Filter verwenden. Vier Optionen ergänzen das:

• --no-pager schaltet den Pager ab. In Skripten und vor jeder Pipe gehört sie dazu, sonst wartet der Aufruf auf eine Taste, die niemand drückt.
• -r dreht die Reihenfolge um, die neuesten Zeilen stehen oben.
• -e springt im Pager sofort ans Ende.
• -x ergänzt bei systemd-eigenen Meldungen einen erklärenden Katalogtext.

Mit --output-fields= lässt sich die Ausgabe auf die interessanten Felder eindampfen. Das wirkt nur bei verbose, json und verwandten Formaten:

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

Das Journal über Neustarts hinweg aufheben

Ob das Journal einen Neustart überlebt, entscheidet die Voreinstellung Storage=auto nach einer einfachen Regel: Existiert /var/log/journal, wird dorthin geschrieben und alles bleibt erhalten. Existiert es nicht, landet alles im Arbeitsspeicher unter /run/log/journal und ist nach dem nächsten Neustart weg. Verlassen Sie sich nicht auf die Distribution, zwischen Installationsvarianten und Cloud-Abbildern kommen beide Zustände vor. Ein Journal im Arbeitsspeicher ist die häufigste Erklärung dafür, dass nach einem Absturz niemand mehr sagen kann, was davor war.

Wenn Sie umstellen, setzen Sie die Grenze im selben Arbeitsschritt. Nachträglich passiert das erfahrungsgemäß nicht mehr:

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 legt das Verzeichnis selbst an, ein mkdir ist dafür nicht nötig. journalctl --flush übernimmt das, was noch in /run liegt, nach /var/log/journal.

Prüfschritte, in dieser Reihenfolge:

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

ls -d /var/log/journal

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

Der erste Befehl zeigt die wirksame Konfiguration aus Hauptdatei und allen Ergänzungsdateien, also das, was der Dienst wirklich gelesen hat. Der dritte ist der Tippfehler-Test: Steht dort eine Zeile mit Unknown key, wirkt Ihre Einstellung nicht. Je nach systemd-Version lautet sie Unknown key name 'SystemMaxUsage' in section 'Journal', ignoring oder Unknown key 'SystemMaxUsage' in section [Journal], ignoring.

Der abschließende Beweis ist ein echter Neustart. Danach muss journalctl --list-boots mindestens zwei Zeilen zeigen und journalctl -b -1 -n 20 Einträge liefern. Wer das Verzeichnis lieber von Hand anlegt, nimmt den folgenden Weg. Der Aufruf von systemd-tmpfiles setzt dabei Eigentümer, Rechte und die Zugriffslisten, die den passenden Gruppen das Mitlesen erlauben:

mkdir -p /var/log/journal

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

systemctl restart systemd-journald

Lesen ohne root

Ein normaler Benutzer sieht nur seine eigenen Meldungen und bekommt dazu den Hinweis Hint: You are currently not seeing messages from other users and the system. samt Verweis auf die Gruppen, die alles lesen dürfen. Auf Debian und Ubuntu ist das üblicherweise adm:

usermod -aG adm benutzername

Prüfschritt: Die Gruppenzugehörigkeit gilt erst in einer neuen Anmeldung. Also abmelden, neu anmelden, dann id -nG und journalctl -n 5. Bleibt der Hinweis aus und erscheinen Systemmeldungen, hat es geklappt.

Größe begrenzen, bevor es der Datenträger tut

Die ausgelieferte /etc/systemd/journald.conf führt alle Schlüssel als auskommentierte Zeilen mit ihren Voreinstellungen auf und ist damit die zuverlässigste Quelle dafür, was auf Ihrem System gerade gilt. Nach jeder Änderung ist systemctl restart systemd-journald nötig, danach zeigt journalctl --disk-usage das Ergebnis.

Für die Sofortmaßnahme auf einem vollen Datenträger gilt eine Reihenfolge, über die viele stolpern: Die Aufräumoptionen fassen ausschließlich abgeschlossene Journaldateien an, niemals die gerade aktive. Ohne vorheriges Rotieren passiert scheinbar nichts, und die Ausgabe lautet sinngemäß Vacuuming done, freed 0B of archived journals.

journalctl --rotate

journalctl --vacuum-time=7d

Mehr dazu, samt der übrigen Speicherfresser, steht im Beitrag Festplatte voll unter Linux.

Ein zweiter Grund für fehlende Zeilen ist die eingebaute Ratenbegrenzung über RateLimitIntervalSec und RateLimitBurst: Schreibt ein Dienst in kurzer Zeit sehr viele Meldungen, verwirft journald den Überschuss und vermerkt das mit einer Zeile, die das Wort Suppressed enthält. Wenn ein Protokoll Lücken hat, obwohl der Dienst nachweislich lief, suchen Sie zuerst danach:

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

Kernelmeldungen: journalctl -k und dmesg

-k zeigt ausschließlich Kernelmeldungen und schließt dabei -b mit ein, beschränkt die Ausgabe also automatisch auf den laufenden Bootvorgang. Wer nach einem Neustart nach der Ursache sucht, muss den vorigen ausdrücklich anfordern:

journalctl -k -p err --no-pager

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

Der Unterschied zu dmesg ist der Speicherort. dmesg liest den Ringpuffer des Kernels: begrenzt, läuft über, nach einem Neustart leer. Das Journal hebt dieselben Meldungen auf, sofern es persistent ist. Für einen Vorfall von gestern ist journalctl -k also die einzige verlässliche Quelle. Dazu zwei Praxishinweise: dmesg -T rechnet die Sekunden seit dem Start in Uhrzeiten um und liegt nach langen Laufzeiten leicht daneben, das Journal führt immer die echte Uhrzeit. Und kernel.dmesg_restrict steht auf allen vier Distributionen auf 1, ein Aufruf ohne root scheitert deshalb mit Operation not permitted.

Warum viele Server kein /var/log/syslog mehr haben

Das Journal ist kein Zusatz zu den klassischen Textdateien, sondern deren Ersatz. /var/log/syslog und /var/log/auth.log entstehen nicht durch systemd, sondern durch einen zusätzlichen Syslog-Dienst, üblicherweise rsyslog. Der ist ein eigenes Paket und gehört in minimalen Installationen von Debian 12 und Debian 13 nicht mehr zum Lieferumfang. Auf den Server-Abbildern von Ubuntu 22.04 und 24.04 ist er vorhanden.

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

systemctl status rsyslog --no-pager

Ist kein Syslog-Dienst installiert, antwortet der zweite Befehl mit Unit rsyslog.service could not be found. Das erklärt drei Beobachtungen auf einen Schlag: Anleitungen mit tail -f /var/log/syslog scheitern mit tail: cannot open '/var/log/syslog' for reading: No such file or directory, die Suche nach Anmeldeversuchen in /var/log/auth.log geht ins Leere, und fail2ban muss seine Ereignisse aus dem Journal beziehen. Wie das eingestellt wird, steht im Beitrag fail2ban einrichten.

rsyslog nachzuinstallieren, nur weil man die Dateien gewohnt ist, lohnt selten: Sie speichern dann alles doppelt und brauchen zusätzlich eine funktionierende logrotate-Regel. Sinnvoll ist es, wenn Logs an ein zentrales System gehen sollen.

Fertige Suchmuster für den Ernstfall

Ein Dienst ist gestorben oder startet dauernd neu

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

Die dritte Zeile findet die Meldungen, mit denen systemd Abstürze und seine eingebaute Startbremse quittiert. Wird ein Absturzabbild interessant, klärt zuerst diese Datei, wer dafür zuständig ist:

cat /proc/sys/kernel/core_pattern

Steht dort ein Aufruf von systemd-coredump, listet coredumpctl list die vorhandenen Abbilder. Steht etwas anderes oder nur core, ist ein anderer Handler zuständig und coredumpctl bleibt leer.

Speichermangel

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

Der zweite Befehl verzichtet bewusst auf -k und sucht dadurch über Bootvorgänge hinweg. Der dritte gilt für Ubuntu 22.04 und 24.04, wo systemd-oomd ab Werk mitläuft und ganze Control-Groups beendet, bevor der Kernel eingreift; auf Debian gehört dieser Dienst nicht zur Standardausstattung. Wie man die Meldungen auseinanderhält, steht im Beitrag Swap einrichten und Out-of-Memory vermeiden.

Gescheiterte Anmeldungen

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

Interessanter als die Einzelzeilen ist die Verteilung. Die folgende Zeile zählt die Quelladressen und sortiert sie absteigend:

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

Der Trick ist die Zählung von hinten: Die Meldung endet immer auf from ADRESSE port NUMMER ssh2, das viertletzte Feld ist also die Adresse, unabhängig davon, ob ein gültiger oder ein erfundener Benutzername davorstand und ob es IPv4 oder IPv6 ist. -o cat ist dabei Pflicht, weil sonst Zeitstempel und Absender die Feldzählung verschieben. Die Gegenprobe für erfolgreiche Anmeldungen:

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

Was war um 03:14, und was kam davor?

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

Der zweite Befehl zeigt die letzten hundert Zeilen vor dem vorherigen Ende. Ein geordnetes Herunterfahren erkennen Sie daran, dass systemd dort reihenweise Dienste beendet. Bricht die Ausgabe mitten im normalen Betrieb ab, war es ein Absturz, ein harter Reset oder ein Stromverlust. Beim dritten Befehl gilt: Prozessnummern werden wiederverwendet, ohne Zeitfenster mischen Sie womöglich zwei verschiedene Programme in einer Ausgabe.

Häufige Fehler und Lösungen

No journal files were found.: Es gibt keine lesbaren Journaldateien. Entweder läuft systemd-journald nicht, oder Sie haben als normaler Benutzer keinen Zugriff. Erst systemctl is-active systemd-journald prüfen, dann als root wiederholen.

-- No entries --: Der Filter hat nichts gefunden. Das ist keine Fehlermeldung, sondern eine korrekte Antwort auf eine womöglich falsche Frage. Die drei häufigsten Ursachen: ein Unit-Name, der nur ein Zweitname ist, ein zu enges Zeitfenster, und ein -k, obwohl die gesuchte Meldung gar nicht vom Kernel kam.

Hint: You are currently not seeing messages from other users and the system.: Sie lesen als normaler Benutzer. Aufnahme in die Gruppe adm und neu anmelden, oder gleich mit sudo arbeiten.

No journal boot entry found for the specified boot (-1) beziehungsweise No journal boot entry found from the specified boot offset (-1): Im Journal steht kein früherer Bootvorgang. Normalfall, solange das Journal nur im Arbeitsspeicher liegt.

Failed to add match: Der Ausdruck ist kein gültiger Feldfilter. Feldnamen stehen in Großbuchstaben, verglichen wird auf den vollständigen Wert. Für Teiltreffer im Meldungstext ist --grep zuständig.

Unknown key name 'SystemMaxUsage' in section 'Journal', ignoring: Ein Tippfehler in der Ergänzungsdatei. systemd überliest die Zeile und arbeitet mit der Voreinstellung weiter. Zu finden über journalctl -u systemd-journald -b.

Vacuuming done, freed 0B of archived journals: Es gab nichts Archiviertes zu löschen, weil die aktive Datei den Platz belegt. Erst journalctl --rotate, dann erneut aufräumen.

Operation not permitted bei dmesg: kernel.dmesg_restrict steht auf 1. Als root wiederholen oder auf journalctl -k ausweichen.

File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing.: Der Server ist hart ausgegangen, während eine Journaldatei offen war. journald hängt an den alten Namen eine Tilde an und beginnt eine neue Datei. Den Zustand aller Dateien prüft journalctl --verify, das je Datei eine Zeile mit PASS ausgibt; Beanstandungen betreffen in aller Regel genau die alten Dateien mit der Tilde.

Unterschiede zwischen Debian 13, Debian 12, Ubuntu 24.04 und 22.04

• Debian 13 (trixie): systemd 257. OpenSSH 10.0, Anmeldevorgänge stehen unter dem Bezeichner sshd-session. rsyslog in minimalen Installationen nicht vorhanden, /var/log/syslog fehlt dann. systemd-oomd nicht in der Standardausstattung.
• Debian 12 (bookworm): systemd 252. OpenSSH 9.2, alles unter sshd. rsyslog je nach Installationsvariante vorhanden, /var/log/syslog also nicht garantiert. systemd-oomd nicht in der Standardausstattung.
• Ubuntu 24.04 LTS: systemd 255. OpenSSH 9.6, alles unter sshd. rsyslog vorhanden. systemd-oomd ab Werk aktiv. SSH läuft über eine Socket-Aktivierung, deshalb den tatsächlichen Unit-Namen im Journal nachsehen.
• Ubuntu 22.04 LTS: systemd 249. OpenSSH 8.9, alles unter sshd. rsyslog vorhanden. systemd-oomd ab Werk aktiv. Älteste der vier systemd-Versionen, einzelne neuere Ausgabeformate fehlen dort.

Gleich ist auf allen vier Systemen das Wesentliche: dieselben Filter, dieselben Prioritäten, dieselbe Konfigurationsdatei und dieselbe Regel, dass /var/log/journal über die Haltbarkeit entscheidet.

Die Reihenfolge, die sich im Alltag bewährt: erst das Zeitfenster, dann die Unit, dann die Priorität, und zum Schluss ein Suchmuster. Wer so vorgeht, braucht für die meisten Störungen keine drei Befehle. Und wer einmal dafür sorgt, dass das Journal Neustarts übersteht und trotzdem eine Obergrenze hat, kann die Frage nach dem Warum auch dann noch beantworten, wenn der Server längst wieder läuft.