journalctl: die Befehle, mit denen du Fehler wirklich findest

Auf einem aktuellen Debian oder Ubuntu landet fast alles, was Dienste ausgeben, im systemd-Journal. Wer darin nur mit journalctl | less blättert, sucht die Nadel im Heuhaufen. Mit einer Handvoll Filter wird daraus eine gezielte Abfrage: Welcher Dienst, seit wann, wie schlimm, in welchem Bootvorgang.

Die fünf Filter, die du täglich brauchst#

journalctl -u nginx                 # nur ein Dienst
journalctl -u nginx -u php8.4-fpm   # mehrere Dienste, zeitlich gemischt
journalctl --since "1 hour ago"     # Zeitraum
journalctl -p err                   # nur Fehler und Schlimmeres
journalctl -b                       # nur seit dem letzten Start

Die Filter lassen sich kombinieren. Die Frage „Was hat nginx seit heute früh an Fehlern gemeldet?“ lautet:

journalctl -u nginx --since today -p warning

Prioritäten von schlimm nach harmlos: emerg, alert, crit, err, warning, notice, info, debug. -p err zeigt err und alles darüber.

Live mitlesen#

journalctl -u meinbot -f

-f folgt dem Protokoll wie tail -f. Besonders nützlich in einem zweiten Terminal, während du im ersten einen Dienst neu startest: Du siehst sofort, woran er scheitert.

Der letzte Absturz: vorheriger Bootvorgang#

Ist der Server neu gestartet und du willst wissen, was davor passiert ist:

journalctl --list-boots          # alle gespeicherten Bootvorgänge
journalctl -b -1 -n 100          # die letzten 100 Zeilen vor dem letzten Neustart
journalctl -b -1 -p err          # nur die Fehler davor

Zeigt --list-boots nur einen Eintrag?

Dann ist dein Journal flüchtig: Es liegt im Arbeitsspeicher und ist nach jedem Neustart weg. Genau die Protokolle, die einen Absturz erklären würden, fehlen dann. Dauerhaft wird es, sobald das Verzeichnis existiert:

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald

Wie groß es werden darf, steht in Platte voll.

Kernel-Meldungen#

journalctl -k -b          # wie dmesg, aber mit echten Zeitstempeln
journalctl -k | grep -i -E "oom|killed process"

Hier stehen Hardwarefehler, Dateisystemprobleme und der OOM-Killer. Wenn ein Dienst ohne Fehlermeldung verschwunden ist, lohnt der Blick fast immer hierhin. Mehr dazu in Speicher knapp.

Die erste Stelle finden, nicht die letzte#

Ein Dienst, der in einer Schleife neu startet, schreibt hunderte Male dieselbe Meldung. Die interessante Zeile ist die erste, nicht die letzte:

journalctl -u meinbot -b --no-pager | grep -i -m 5 -E "error|fail|exception"

-m 5 bricht nach fünf Treffern ab, und weil das Journal chronologisch ausgegeben wird, sind das die ersten. Umgekehrt zeigt -r die neuesten Einträge zuerst, wenn du am Ende anfangen willst.

Ausgabe für Skripte und Suche#

journalctl -u nginx -o cat           # nur die Nachricht, ohne Zeitstempel und Rechnername
journalctl -u nginx -o short-iso     # ISO-Zeitstempel, gut zum Vergleichen
journalctl -u nginx -o json-pretty -n 1   # alle Felder eines Eintrags

Die JSON-Ansicht zeigt, welche Felder es gibt. Danach lässt sich direkt filtern, zum Beispiel nach Prozess-ID oder Programmname:

journalctl _PID=1234
journalctl _COMM=sshd --since today
journalctl _SYSTEMD_UNIT=ssh.service | grep "Accepted"

Typische Fragen an das Journal#

Frage	Abfrage
Wer hat sich heute per SSH angemeldet?	`journalctl -u ssh --since today \| grep Accepted`
Warum startet der Dienst nicht?	`systemctl status dienst` und `journalctl -u dienst -b -n 50`
Was lief schief beim letzten Timer-Lauf?	`journalctl -u sicherung.service -n 30`
Gab es heute Nacht Fehler?	`journalctl --since "yesterday 22:00" --until "today 06:00" -p err`
Welche Dienste melden am meisten?	`journalctl --since today -o json \| jq -r ._SYSTEMD_UNIT \| sort \| uniq -c \| sort -n \| tail`

Die letzte Zeile braucht jq (apt install jq) und findet den Dienst, der das Protokoll zumüllt.

Eigene Skripte ins Journal schreiben#

Läuft ein Skript als systemd-Dienst oder -Timer, landet seine Ausgabe automatisch im Journal. Außerhalb davon schreibst du mit systemd-cat hinein:

echo "Sicherung fertig" | systemd-cat -t sicherung -p info
journalctl -t sicherung

Das -t setzt einen Namen, nach dem du später filtern kannst.

Häufige Fragen#

Brauche ich rsyslog noch?#

Für die meisten Server nicht. Auf aktuellen Debian-Installationen ist rsyslog nicht mehr vorinstalliert, das Journal reicht. rsyslog lohnt sich, wenn Protokolle an einen zentralen Server gehen sollen und dort ein System erwartet, das Syslog spricht.

Warum sehe ich als normaler Benutzer nichts?#

Das Systemjournal lesen nur root und Mitglieder der Gruppe systemd-journal bzw. adm. usermod -aG systemd-journal deinname und neu anmelden.

Wie exportiere ich einen Ausschnitt für ein Ticket?#

journalctl -u dienst --since "10:00" --until "10:30" --no-pager > ausschnitt.txt. Vorher auf Zugangsdaten und Kundendaten durchsehen, bevor die Datei den Server verlässt.

Das Journal ist beschädigt. Was nun?#

journalctl --verify zeigt defekte Dateien. Sie entstehen nach harten Abstürzen. journald legt dann eine neue Datei an; die beschädigte kannst du nach dem Auswerten löschen.

Kurz gesagt#

-u für den Dienst, --since für die Zeit, -p err für die Schwere, -b für den Bootvorgang.
-b -1 zeigt, was vor dem letzten Neustart passiert ist, aber nur mit dauerhaftem Journal.
/var/log/journal anlegen, sonst ist nach jedem Neustart alles weg.
Bei Neustartschleifen zählt die erste Fehlermeldung, nicht die letzte.
-k zeigt Kernel-Meldungen mit Zeitstempel, dort steht der OOM-Killer.