systemd-Logs: journalctl in einfacher Sprache

Fast alles, was auf dem System passiert, landet im systemd-Journal. Ein Dienst startet nicht, die Maschine hat von selbst neu gestartet, die Website liefert einen 502 — die Antwort ist meist schon aufgezeichnet, Sie müssen nur wissen, wie Sie danach fragen.

Fünf Befehle, die ausreichen

journalctl -u nginx -n 50 --no-pager      # last 50 lines of one service
journalctl -u nginx -f                    # follow in real time
journalctl -p err -b                      # only errors since boot
journalctl --since "10 min ago"           # everything for the last ten minutes
journalctl -b -1 -e                       # previous boot log, end of file

Der letzte ist besonders wertvoll nach einem plötzlichen Neustart: -b -1 öffnet die vorherige Sitzung, und am Ende sehen Sie, ob es eine Kernel-Panic war, der OOM-Killer zugeschlagen hat oder ein sauberes Herunterfahren vorlag.

Die Stufen in -p: emerg, alert, crit, err, warning, notice, info, debug. Die angegebene Stufe schließt alle wichtigeren ein.

Diagnose eines fehlgeschlagenen Dienstes

systemctl status myapp
journalctl -u myapp --since today -p warning

systemctl status liefert den Exit-Code und die letzten Zeilen, journalctl liefert das vollständige Bild. Achten Sie auf:

• Main process exited, code=exited, status=1 — die Anwendung hat sich mit einem Fehler selbst beendet, die Ursache steht in der Zeile darüber;
• Failed to start ... Permission denied — Berechtigungen auf eine Datei, ein Verzeichnis oder einen Port unter 1024;
• Killed process ... (java) total-vm... vom Kernel — der OOM-Killer hat zugeschlagen, lesen Sie Out of memory;
• Start request repeated too quickly — der Dienst hängt in einer Crash-Schleife, systemd hat den Start eingestellt; beheben Sie die Ursache und führen Sie systemctl reset-failed myapp aus.

Eine Liste aller defekten Dienste auf dem System erhalten Sie mit systemctl --failed.

Filter, die Zeit sparen

journalctl --since "2026-08-22 03:00" --until "2026-08-22 04:00"
journalctl -u nginx -u php-fpm            # several services at once
journalctl _PID=1432                      # by specific process
journalctl -k                             # only kernel messages
journalctl -u sshd | grep "Failed password" | tail -20

Kombinieren Sie mit grep, aber denken Sie daran: journalctl ohne --no-pager öffnet einen Pager, den Sie mit q verlassen.

Damit das Journal nicht die Festplatte auffrisst

Standardmäßig wächst das Journal auf 10 % der Partition. Auf VDS-1 mit einer 40-GB-Festplatte sind das vier Gigabyte — spürbar.

journalctl --disk-usage
journalctl --vacuum-size=200M
journalctl --vacuum-time=14d

Das dauerhafte Limit steht in /etc/systemd/journald.conf:

[Journal]
SystemMaxUse=300M
MaxRetentionSec=1month

Danach systemctl restart systemd-journald.

Häufige Fehler

• Das Journal ohne -u lesen. Der allgemeine Strom ist mit Dienst-Einträgen verstopft, und die benötigte Zeile geht unter. Grenzen Sie immer auf einen Dienst oder eine Stufe ein.
• Verlauf nach einem Neustart verlieren. Wenn das Verzeichnis /var/log/journal nicht existiert, liegt das Journal nur im Speicher. Erstellen Sie es: mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal.
• Dort nach Anwendungsfehlern suchen. Nginx, PostgreSQL und ähnliche schreiben auch in ihre eigenen Dateien in /var/log. Ist das Journal leer, prüfen Sie dort.

Wenn die Festplatte voll ist, kann journalctl die Arbeit verweigern, bis Speicherplatz freigegeben ist. Diese Situation wird im Artikel Out of disk space behandelt.