journalctl Cheat Sheet: Linux-Logs tailen und filtern

journalctl in einer Zeile: journalctl -u <service> -f verfolgt den Log eines laufenden Dienstes, journalctl -u <service> -n 100 zeigt die letzten 100 Zeilen, und journalctl --since "1 hour ago" zeigt alles, was zuletzt passiert ist. Das deckt 90 % der Momente ab, in denen ein Dienst nicht mehr antwortet und niemand weiß warum. Der Rest dieses Cheat Sheets sind die Copy-paste-Muster, die dich davor bewahren, um 2 Uhr nachts die Man Page ein zweites Mal zu lesen — Filterung nach Unit, Zeit, Priorität und Boot, dazu die Aufräum-Befehle, die verhindern, dass das Journal deine Platte frisst. Jeder Befehl unten läuft unverändert auf jeder systemd-Distribution (Ubuntu, Debian, Fedora, Arch).

Was ist journalctl, und warum nicht einfach /var/log/syslog lesen?

Das klassische Linux-Logging schrieb Textdateien unter /var/log — syslog, auth.log, messages. systemd hat das durch das Journal ersetzt: ein binäres, indiziertes Log, verwaltet von systemd-journald. Ein schlichtes grep kann es nicht lesen; journalctl ist die einzige Tür hinein, und im Gegenzug filterst du nach Dienst, Zeit, Boot und Schweregrad, ohne Regex-Akrobatik.

Das mentale Modell ist simpel: Das Journal speichert alles, und journalctl ist das Abfragewerkzeug. Ein Dienst braucht keine eigene Log-Datei — alles, was er im Betrieb unter systemd auf stdout/stderr schreibt, landet automatisch im Journal. Deshalb funktioniert journalctl -u nginx, selbst wenn du keine Ahnung hast, wo nginx sein Error-Log konfiguriert.

Ein Haken: Bei manchen Minimal-Installationen ist das Journal volatil (liegt in /run, wird beim Reboot gelöscht), weil /var/log/journal nicht existiert. Das fixt man einmal:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

Wie sehe ich die letzten 100 Zeilen eines Logs?

-n begrenzt die Ausgabe auf die neuesten N Zeilen (Standard ist 10):

journalctl -n 100                      # die letzten 100 Zeilen von allem
journalctl -u nginx -n 100             # die letzten 100 Zeilen einer Unit
journalctl -n 100 --no-pager           # ausgeben und enden — ideal für Pipes

--no-pager ist wichtiger, als es aussieht: Ohne ihn öffnet journalctl less, und dein Skript, deine Pipe oder dein ssh-Einzeiler hängt und wartet auf einen Tastendruck. Jeder Befehl, dessen Ausgabe in eine Pipe weiterläuft, sollte ihn tragen.

Wie verfolge ich Logs live, wie mit tail -f?

Das Flag -f ist das tail -f von journalctl — es streamt neue Einträge, sobald sie ankommen:

journalctl -f                    # alles, live
journalctl -u sshd -f            # nur der SSH-Daemon, live
journalctl -u ollama -f -n 50    # live, aber mit den letzten 50 Zeilen starten

Das ist der Befehl für das zweite Terminal, während du im ersten einen Dienst neu startest: systemctl restart nginx in der einen Hälfte, journalctl -u nginx -f in der anderen, und die Absturzursache meldet sich meist binnen Sekunden von selbst. Genau diese Schleife fahre ich auf meinem Homelab jedes Mal, wenn ein Container oder Dienst zickt.

Wie zeige ich die Logs eines bestimmten Dienstes an?

-u filtert nach systemd-Unit:

journalctl -u nginx                    # eine Unit, der komplette Verlauf
journalctl -u nginx -u redis           # mehrere Units auf einmal
journalctl _SYSTEMD_UNIT=nginx.service # die Alternative mit exaktem Match

Units können Hilfs-Units erzeugen, und dort bleibt die interessante Ausgabe manchmal hängen — eine abstürzende Web-App loggt den echten Fehler nicht selten unter einer anderen Unit. Wenn -u <service> nichts liefert, der Dienst aber offensichtlich läuft, finde zuerst den echten Unit-Namen:

systemctl list-units --type=service | grep -i <guess>

Das gleiche -u-Muster funktioniert für Timer (systemctl list-timers zeigt die Namen) und User-Services — für alles, was unter systemd --user läuft, ergänze --user:

journalctl --user -u pipewire -n 50

Wie filtere ich Logs nach Zeit?

--since und --until nehmen Zeitstempel, akzeptieren aber auch großzügige relative Formulierungen:

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

Kombiniere ein Zeitfenster mit einer Unit, und du hast Incident-Triage in einer Zeile: „Was hat die API zwischen 09:00 und dem Moment geloggt, als sie umgefallen ist?” Auf einer einzelnen Maschine ist das schneller als jeder Log-Aggregator.

Wie zeige ich nur Fehler (oder Warnungen) an?

-p filtert nach Priorität, mit den Schweregrad-Namen von syslog:

journalctl -p err -b              # nur Fehler, seit diesem Boot
journalctl -p warning..alert -u nginx   # ein Bereich von Schweregraden

Die Prioritäten in absteigender Reihenfolge: emerg, alert, crit, err, warning, notice, info, debug. Wenn sich eine Maschine „komisch verhält”, ist journalctl -p err -b --since today der schnellste Realitätscheck — er beantwortet „schlägt überhaupt irgendwas fehl?”, ohne das Rauschen der Routine-Info-Zeilen.

Wie sehe ich die Logs des vorherigen Boots?

Dienste, die beim Start abstürzen, erzeugen Log-Zeilen vor deinem aktuellen Boot, und journalctl zeigt standardmäßig stillschweigend nur diesen an. -b wählt Boots aus:

journalctl -b                 # nur der aktuelle Boot
journalctl -b -1              # der vorherige Boot
journalctl -b -1 -u sshd      # warum SSH beim letzten Mal gestorben ist
journalctl --list-boots       # Index der gespeicherten Boots

Das ist das mit Abstand nützlichste Flag für den Fall „es ist kaputtgegangen, ich habe neu gestartet, und jetzt sehe ich den Fehler nicht mehr” — der Fehler ist noch da, einen Boot zurück.

Kurzreferenz: Die Flags, die man auswendig können sollte

Ziel	Befehl
Einem Dienst live folgen	journalctl -u <svc> -f
Die letzten 100 Zeilen	journalctl -n 100
Seit einer Stunde	journalctl --since "1 hour ago"
Fehler dieses Boots	journalctl -p err -b
Vorheriger Boot	journalctl -b -1
Plattenplatz des Journals	journalctl --disk-usage
Maschinenlesbare Ausgabe	journalctl -o json-pretty
Nur Kernel-Meldungen	journalctl -k

Wie verhindere ich, dass das Journal meine Platte füllt?

Erst prüfen, was es kostet, dann deckeln:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # die neuesten 500 MB behalten
sudo journalctl --vacuum-time=30d      # die neuesten 30 Tage behalten

Damit das Limit dauerhaft gilt, setze SystemMaxUse=500M in der Sektion [Journal] von /etc/systemd/journald.conf und danach sudo systemctl restart systemd-journald. Zwischen Größenlimit und Boot-Filter von oben bleibt das Journal ein Werkzeug statt eines langsamen Plattenlecks.

journalctl vs. dmesg vs. /var/log — wo schaue ich zuerst nach?

• journalctl — das Verhalten von Anwendungen und Diensten. Alles, was systemd verwaltet, ist hier, indiziert und filterbar. Die erste Anlaufstelle.
• journalctl -k / dmesg — Kernel und Hardware: OOM-Kills, USB-Resets, Festplattenfehler. Wenn ein Prozess mysteriös gestorben ist, such hier nach dem OOM-Killer, bevor du der App die Schuld gibst.
• /var/log/<app>/ — nur für Apps, die ihr eigenes Datei-Logging betreiben (nginx-Access-Logs, PostgreSQL). Selbst dann landen Startfehler meist trotzdem im Journal.

Der gleiche Workflow lässt sich auf lokale KI-Dienste ausweiten — wenn eine ollama serve-Unit hängen bleibt, zeigt journalctl -u ollama -n 100 sofort den Fehler beim Modell-Laden, wie im Ollama-vs-LM-Studio-Vergleich beschrieben.

Das war das ganze Cheat Sheet: -u für die Unit, -f zum Folgen, -n für Zeilen, --since für die Zeit, -p für den Schweregrad, -b für Boots. Sechs Flags beantworten fast jede Log-Frage, die ein Linux-Rechner dir stellt.