Logs lesen mit journalctl und /var/log gehört zu den wichtigsten Linux-Grundlagen überhaupt. Wenn ein Dienst nicht startet, ein Login fehlschlägt, ein Cronjob nicht läuft oder ein Server nach einem Neustart anders reagiert als erwartet, findest du die entscheidenden Hinweise fast immer in den Logs. Das Problem für Einsteiger ist selten der einzelne Befehl, sondern die Frage: Wo schaue ich zuerst nach?

Genau dabei hilft dir diese Anleitung. Du lernst zuerst den Unterschied zwischen dem systemd-Journal und klassischen Textlogs in /var/log. Danach arbeiten wir uns in einer sinnvollen Reihenfolge vor: erst grob orientieren, dann auf einen Dienst eingrenzen, dann Fehler, Zeiten und Boots filtern und erst danach an Themen wie persistentes Journal oder Journal-Bereinigung gehen.

Voraussetzungen

Ein Linux-System mit systemd, zum Beispiel Debian, Ubuntu, Rocky Linux, AlmaLinux, RHEL oder Fedora
Zugriff auf eine Shell, lokal oder per SSH
Für einige Schritte sudo-Rechte
Optional ein laufender Dienst wie ssh, sshd oder nginx, damit du die Filter direkt testen kannst

Wichtig für das Verständnis: Nicht jedes Linux-System nutzt dieselben Logdateien unter /var/log. Der Journal-Teil mit journalctl ist oft einheitlicher als die Dateinamen der klassischen Textlogs.

Schritt 1: Verstehen, welche Log-Welten es unter Linux gibt

Unter modernen Linux-Systemen begegnen dir meist zwei Log-Welten:

Das systemd-Journal: Darauf greifst du mit journalctl zu. Hier landen viele Dienst- und Systemmeldungen zentral an einer Stelle.
Klassische Textlogs in /var/log: Zum Beispiel /var/log/syslog, /var/log/auth.log oder /var/log/messages. Diese liest du mit Werkzeugen wie less, tail oder grep.

Für Einsteiger ist die wichtigste Regel: Beginne bei aktuellen Problemen zuerst mit journalctl. Wenn du dort nicht weit genug kommst oder einen ganz bestimmten Dateityp suchst, gehst du danach in /var/log.

Verifizieren: Du hast diesen Schritt verstanden, wenn du den Unterschied sauber erklären kannst: journalctl liest nicht einfach eine einzelne Textdatei, sondern das systemd-Journal. /var/log ist dagegen ein Verzeichnis mit klassischen Logdateien.

Schritt 2: Sich mit journalctl zuerst grob orientieren

Bevor du irgendetwas filterst, solltest du einmal sehen, wie das Journal grundsätzlich aussieht. So erkennst du Zeitstempel, Hostnamen, Dienstnamen und die typische Ausgabeform.

journalctl

journalctl -n 50

journalctl -r

journalctl --no-pager

Was diese Befehle tun:

journalctl zeigt das gesamte Journal paginiert an
journalctl -n 50 zeigt nur die letzten 50 Einträge
journalctl -r dreht die Reihenfolge um, damit die neuesten Einträge oben stehen
journalctl --no-pager unterdrückt die Ansicht über less, was für Skripte oder kurze Tests praktisch ist

Für den Alltag ist journalctl -n 50 oft der beste Startpunkt. Du bekommst schnell ein Gefühl dafür, was zuletzt passiert ist, ohne sofort in tausenden Zeilen unterzugehen.

Verifizieren: Der Schritt ist erfolgreich, wenn du die letzten Einträge deines Systems sehen kannst und dabei erkennst, dass die Ausgabe Zeitstempel und Dienste enthält. Wenn du nur einen leeren Bildschirm oder eine Fehlermeldung siehst, prüfe, ob du auf dem richtigen System arbeitest oder ob sudo nötig ist.

Schritt 3: Einen einzelnen Dienst gezielt prüfen

Der häufigste Praxisfall lautet nicht „Zeig mir alles“, sondern „Warum läuft genau dieser Dienst nicht richtig?“. Dafür filterst du mit -u nach einer systemd-Unit.

journalctl -u ssh

journalctl -u sshd

journalctl -u nginx

journalctl -u nginx -n 100

Welcher Dienstname richtig ist, hängt von deiner Distribution und vom Dienst ab. Für SSH heißt der Dienst oft ssh oder sshd. Wenn du unsicher bist, hilft dir:

systemctl list-units --type=service

Genau hier verknüpft sich dieser Artikel mit unserer Anleitung systemd-Service erstellen und verwalten: Der Unit-Name aus systemctl ist derselbe Name, den du in journalctl -u verwendest.

Verifizieren: Der Schritt ist erfolgreich, wenn du für einen echten Dienst auf deinem System gezielte Logzeilen bekommst. Wenn journalctl -u DIENST gar nichts zeigt, prüfe zuerst, ob der Dienstname stimmt und ob der Dienst überhaupt schon gelaufen ist.

Schritt 4: Nur Fehler und Warnungen herausfiltern

Wenn ein Dienst viele normale Meldungen schreibt, helfen Prioritätsfilter. Mit -p schränkst du die Ausgabe auf Fehlerstufen ein.

journalctl -p err

journalctl -p warning

journalctl -u nginx -p err

journalctl -u ssh -p warning

Wichtig ist das Verständnis hinter -p err: Du siehst damit nicht nur exakt Stufe err, sondern err und alles Kritischere. Für die Praxis ist das meistens genau richtig, weil du ernstere Meldungen nicht versehentlich ausblendest.

Wenn du gezielt nach Login-Problemen schaust, lohnt sich auch der Blick in /var/log/auth.log oder /var/log/secure. Die Verbindung zur SSH-Grundlage liegt auf der Hand: Wenn dort auffällige Login-Fehler auftauchen, ist unsere Anleitung SSH-Key-Authentifizierung einrichten der passende nächste Schritt.

Verifizieren: Du bist hier richtig unterwegs, wenn die gefilterte Ausgabe deutlich kürzer ist als vorher und vor allem Warnungen oder Fehler zeigt. Wenn plötzlich gar nichts mehr erscheint, kann das auch einfach bedeuten, dass es in diesem Zeitraum oder für diesen Dienst aktuell keine Fehler gibt.

Schritt 5: Nach Zeitfenster und Boot eingrenzen

Viele Probleme sind an einen Zeitpunkt gebunden: „Seit heute Morgen“, „nach dem letzten Neustart“ oder „kurz vor 14 Uhr“. Dafür kombinierst du Zeitfilter und Boot-Filter.

journalctl --since 'today'

journalctl --since '2 hours ago'

journalctl --since '2026-06-12 08:00:00' --until '2026-06-12 09:00:00'

journalctl -b

journalctl -b -1

journalctl --list-boots

Die Bedeutung dahinter:

--since und --until grenzen einen Zeitraum ein
-b zeigt nur Meldungen des aktuellen Boots
-b -1 zeigt den vorherigen Boot
--list-boots zeigt, welche Boots überhaupt verfügbar sind

Wenn -b -1 nichts Brauchbares liefert, ist das oft kein Fehler von dir, sondern ein Hinweis darauf, dass das Journal noch nicht persistent gespeichert wird. Genau das richten wir in Schritt 7 sauber ein.

Verifizieren: Du hast diesen Schritt verstanden, wenn du entweder nur den aktuellen Boot oder einen klar abgegrenzten Zeitraum anzeigen kannst. Der Unterschied zur ungefilterten Gesamtausgabe sollte sofort sichtbar sein.

Schritt 6: Laufende Logs live verfolgen

Wenn du gerade aktiv testest, zum Beispiel einen Dienst neu startest oder einen Login-Versuch machst, willst du die Logs nicht immer wieder neu abfragen. Dafür gibt es den Live-Modus mit -f.

journalctl -f

journalctl -f -u ssh

journalctl -f -u nginx

journalctl -f -u ssh -p err

Das ist das Journal-Pendant zu tail -f bei Textdateien. Besonders nützlich wird es, wenn du in einem zweiten Terminal eine Aktion auslöst und im ersten Terminal direkt die passenden Meldungen beobachtest.

Verifizieren: Starte einen echten Vorgang, zum Beispiel einen SSH-Login oder einen Dienst-Neustart, während journalctl -f läuft. Der Test ist erfolgreich, wenn neue Einträge live nachlaufen, sobald auf dem System etwas passiert.

Schritt 7: Persistentes Journal aktivieren

Viele Nutzer wundern sich, warum frühere Boots fehlen. Der Grund ist oft simpel: Das Journal wird nur flüchtig gespeichert und beim Neustart verworfen. Für produktive Systeme solltest du das Journal persistent speichern.

Zuerst legst du das Verzeichnis an:

sudo mkdir -p /var/log/journal
sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal

Dann prüfst oder ergänzt du die Konfiguration:

sudo nano /etc/systemd/journald.conf

[Journal]
Storage=persistent
SystemMaxUse=500M
SystemMaxFileSize=50M

Danach lädst du journald neu:

sudo systemctl restart systemd-journald

Wichtig: Frühere Boots, die vorher nie persistent gespeichert wurden, kannst du damit nicht rückwirkend herbeizaubern. Die Änderung hilft dir ab jetzt für kommende Neustarts.

Verifizieren: Prüfe zuerst, ob /var/log/journal existiert. Nach dem nächsten Neustart sollte außerdem journalctl --list-boots mehr als nur den aktuellen Boot zeigen. Spätestens dann weißt du, dass die Persistenz sauber greift.

Schritt 8: Speicherbedarf des Journals prüfen und bereinigen

Logs sind nützlich, aber sie dürfen nicht unkontrolliert wachsen. Deshalb solltest du den Speicherbedarf gelegentlich prüfen und bei Bedarf begrenzen.

journalctl --disk-usage

sudo journalctl --rotate

sudo journalctl --vacuum-size=500M

sudo journalctl --vacuum-time=30d

Die Reihenfolge ist wichtig:

--disk-usage zeigt dir, wie viel Platz das Journal gerade belegt
--rotate sorgt dafür, dass die aktive Journal-Datei archiviert wird
--vacuum-size oder --vacuum-time räumen alte archivierte Dateien auf

Wenn du später in Storage- oder Platzthemen tiefer einsteigst, passt dazu auch unsere Grundlagenanleitung Festplatten unter Linux einbinden – Partitionen, LVM und fstab.

Verifizieren: Der Schritt ist erfolgreich, wenn journalctl --disk-usage dir einen konkreten Wert ausgibt und sich dieser nach einer Bereinigung nachvollziehbar verändert oder zumindest bestätigt, dass gerade kein großer Altbestand vorhanden ist.

Schritt 9: Klassische Logs in /var/log lesen und rotierte .gz-Dateien öffnen

Nicht alles läuft über das Journal. Deshalb musst du die wichtigsten Dateien unter /var/log ebenfalls kennen. Typische Kandidaten sind:

/var/log/syslog auf Debian und Ubuntu für allgemeine Systemmeldungen
/var/log/messages auf RHEL, Rocky oder AlmaLinux für allgemeine Systemmeldungen
/var/log/auth.log oder /var/log/secure für Logins, sudo und Authentifizierung
/var/log/dpkg.log oder /var/log/apt/history.log für Paketvorgänge auf Debian und Ubuntu

Zum Lesen reichen oft schon diese Befehle:

less /var/log/syslog

tail -f /var/log/syslog

grep 'Failed password' /var/log/auth.log

dmesg -T

Für rotierte und komprimierte Logs brauchst du die z-Tools:

zless /var/log/syslog.2.gz

zcat /var/log/auth.log.1.gz

zgrep -i 'error' /var/log/syslog*.gz

Der Vorteil: Du musst die Dateien nicht erst manuell entpacken. Wenn du dich später mit automatischer Rotation beschäftigst, ist die passende Ergänzung unsere Anleitung Cron und crontab richtig nutzen – die Grundlagen.

Verifizieren: Der Schritt ist erfolgreich, wenn du auf deinem System mindestens eine klassische Logdatei sicher öffnen kannst und außerdem verstehst, dass .gz-Dateien mit zless, zcat oder zgrep gelesen werden, nicht mit normalen Editor-Befehlen.

Troubleshooting

journalctl -u DIENST zeigt nichts: Prüfe den exakten Unit-Namen mit systemctl list-units --type=service. Möglicherweise heißt der Dienst anders oder lief noch nie.
journalctl -b -1 findet keinen vorherigen Boot: Dann ist das Journal sehr wahrscheinlich nicht persistent gespeichert. Schritt 7 ist in diesem Fall der richtige Fix.
/var/log/syslog existiert nicht: Auf manchen Distributionen heißt die allgemeine Logdatei stattdessen /var/log/messages.
zless oder zgrep fehlen: Dann fehlt meist nur das Paket gzip oder die z-Tool-Sammlung deiner Distribution.
Du darfst Logdateien nicht lesen: Dann fehlen dir passende Rechte oder sudo. Mehr dazu erklärt unsere Anleitung Linux-Benutzer, Gruppen und Rechte verstehen.

Häufige Fragen

Womit soll ich bei einem frischen Fehler anfangen: journalctl oder /var/log?

In den meisten Fällen mit journalctl, weil du dort schnell nach Dienst, Zeit und Priorität filtern kannst. Danach ergänzt du den Blick in /var/log, wenn du sehr distributionsspezifische oder klassische Dateien brauchst.

Warum sehe ich nach einem Neustart keine älteren Logs?

Weil das Journal oft zunächst nur flüchtig gespeichert wird. Ohne persistentes Journal bleiben nur die Logs des aktuellen Boots erhalten.

Was ist der Unterschied zwischen journalctl und dmesg?

journalctl zeigt das systemd-Journal und damit viel mehr als nur Kernel-Meldungen. dmesg konzentriert sich auf den Kernel-Ringpuffer und ist deshalb nur ein Teil des Gesamtbildes.

Kann ich mehrere Filter gleichzeitig kombinieren?

Ja. Genau das ist im Alltag sogar normal. Ein typisches Beispiel ist journalctl -u nginx -p err --since 'today'.

Warum sind rotierte Logs oft komprimiert?

Weil alte Logdateien Speicher sparen sollen. Durch die Komprimierung bleiben sie erhalten, ohne unnötig viel Platz zu verbrauchen.

Wann schaue ich eher in auth.log oder secure?

Immer dann, wenn es um Login-Versuche, SSH, sudo oder andere Authentifizierungsfragen geht. Auf Debian und Ubuntu ist oft auth.log relevant, auf RHEL-artigen Systemen eher secure.

Fazit

Wenn du Logs unter Linux sauber lesen kannst, wird Troubleshooting deutlich ruhiger und zielgerichteter. Der wichtigste Lernschritt ist nicht das Auswendiglernen einzelner Befehle, sondern die Reihenfolge: erst verstehen, welche Logquelle du brauchst, dann mit journalctl eingrenzen, danach bei Bedarf in klassische Dateien unter /var/log wechseln. Genau dieses Muster spart Zeit und verhindert blinde Suche.

Als nächste sinnvolle Ergänzungen passen dazu besonders systemd-Service erstellen und verwalten, Cron und crontab richtig nutzen – die Grundlagen und Linux-Benutzer, Gruppen und Rechte verstehen.

Weiterführende Anleitungen und Quellen

Quellen: journalctl(1) man page, journald.conf(5) Debian Manpage, journald.conf(5) Ubuntu Manpage.