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, finden Sie 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 Ihnen diese Anleitung. Sie lernen zuerst den Unterschied zwischen dem systemd-Journal und klassischen Textlogs in /var/log. Danach arbeiten Sie sich 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; besondere Hardware ist nicht nötig, jeder Server, jede VM und jeder Raspberry Pi mit systemd genügt
Zugriff auf eine Shell, lokal oder per SSH
sudo-Rechte oder die Mitgliedschaft in der Gruppe adm bzw. systemd-journal, damit Sie auch System-Logs sehen
Optional ein laufender Dienst wie ssh, sshd oder nginx, damit Sie die Filter direkt testen können

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

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

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

Das systemd-Journal: Darauf greifen Sie mit journalctl zu. Hier landen Dienst-, Kernel- und Systemmeldungen zentral an einer Stelle, in einem binären Format.
Klassische Textlogs in /var/log: Zum Beispiel /var/log/syslog, /var/log/auth.log oder /var/log/messages. Diese schreibt meist rsyslog, und Sie lesen sie mit Werkzeugen wie less, tail oder grep. Einige Programme (etwa Webserver oder Paketverwaltung) schreiben zusätzlich eigene Dateien dorthin.

Die wichtigste Regel: Beginnen Sie bei aktuellen Problemen zuerst mit journalctl. Wenn Sie dort nicht weiterkommen oder eine bestimmte Datei suchen, gehen Sie danach in /var/log.

Verifizieren: ls /var/log zeigt die klassischen Logdateien Ihres Systems, und systemctl is-active rsyslog verrät, ob überhaupt ein Syslog-Dienst die Textlogs schreibt. Meldet er inactive oder ist nicht vorhanden (etwa auf neueren Debian-Installationen), finden Sie die allgemeinen Meldungen nur im Journal.

Schritt 2: Sich mit journalctl zuerst grob orientieren

Bevor Sie filtern, sehen Sie sich einmal an, wie das Journal grundsätzlich aussieht. So erkennen Sie 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 seitenweise an (Beenden mit q)
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. Sie bekommen schnell ein Gefühl dafür, was zuletzt passiert ist, ohne in tausenden Zeilen unterzugehen.

Verifizieren: journalctl -n 50 zeigt die letzten Einträge mit Zeitstempel, Hostname und Dienstnamen. Sehen Sie nur Meldungen Ihres eigenen Benutzers oder den Hinweis, dass Sie keine System-Logs sehen dürfen, wiederholen Sie den Befehl mit sudo.

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 filtern Sie 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 Distribution und Dienst ab. Für SSH heißt der Dienst unter Debian und Ubuntu ssh, unter RHEL-artigen Systemen sshd. Wenn Sie unsicher sind, hilft:

systemctl list-units --type=service

Hier verknüpft sich dieser Artikel mit der Anleitung systemd-Service erstellen und verwalten: Der Unit-Name aus systemctl ist derselbe Name, den Sie in journalctl -u verwenden.

Verifizieren: Für einen echten Dienst auf Ihrem System liefert journalctl -u DIENST -n 20 gezielte Logzeilen, und jede Zeile trägt den Namen dieses Dienstes. Meldet der Befehl -- No entries --, prüfen Sie zuerst den Dienstnamen 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änken Sie 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: Sie sehen damit nicht nur exakt die Stufe err, sondern err und alles Kritischere (crit, alert, emerg). Für die Praxis ist das meistens richtig, weil Sie ernstere Meldungen nicht versehentlich ausblenden.

Wenn Sie gezielt nach Login-Problemen suchen, lohnt sich auch der Blick in /var/log/auth.log oder /var/log/secure. Tauchen dort auffällige Login-Fehler auf, ist die Anleitung SSH-Key-Authentifizierung einrichten der passende nächste Schritt.

Verifizieren: journalctl -p err -b | wc -l ergibt deutlich weniger Zeilen als journalctl -b | wc -l. Liefert der Filter gar nichts, kann das auch bedeuten, dass es im gewählten Zeitraum oder für diesen Dienst 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 kombinieren Sie 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

Liefert -b -1 nichts Brauchbares, ist das oft kein Fehler Ihrerseits, sondern ein Hinweis darauf, dass das Journal nicht persistent gespeichert wird. Das richten Sie in Schritt 7 ein.

Verifizieren: journalctl --list-boots listet mindestens den aktuellen Boot mit Index 0, und journalctl --since '2 hours ago' -n 5 zeigt nur Einträge, deren Zeitstempel in den letzten zwei Stunden liegen.

Schritt 6: Laufende Logs live verfolgen

Wenn Sie gerade aktiv testen, zum Beispiel einen Dienst neu starten oder einen Login-Versuch machen, wollen Sie 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-Gegenstück zu tail -f bei Textdateien. Besonders nützlich ist es, wenn Sie in einem zweiten Terminal eine Aktion auslösen und im ersten Terminal die passenden Meldungen beobachten. Beenden Sie den Live-Modus mit Strg+C.

Verifizieren: Starten Sie während sudo journalctl -f in einem zweiten Terminal einen echten Vorgang, etwa logger "Testmeldung" oder einen Dienst-Neustart. Die neue Meldung erscheint sofort in der Live-Ausgabe.

Schritt 7: Persistentes Journal aktivieren

Viele Nutzer wundern sich, warum frühere Boots fehlen. Der Grund: Mit der Standardeinstellung Storage=auto speichert journald nur dann dauerhaft, wenn das Verzeichnis /var/log/journal existiert. Fehlt es, landet das Journal nur in /run/log/journal und geht beim Neustart verloren. Auf vielen aktuellen Distributionen ist das Verzeichnis bereits vorhanden; prüfen Sie es zuerst mit ls -ld /var/log/journal. Fehlt es, legen Sie es an:

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

Dann prüfen oder ergänzen Sie die Konfiguration:

sudo nano /etc/systemd/journald.conf

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

Danach starten Sie journald neu:

sudo systemctl restart systemd-journald

Wichtig: Frühere Boots, die nie persistent gespeichert wurden, lassen sich damit nicht rückwirkend herstellen. Die Änderung wirkt ab jetzt für kommende Neustarts.

Verifizieren: ls -ld /var/log/journal zeigt das Verzeichnis mit der Gruppe systemd-journal, und journalctl --disk-usage nennt Dateien unter /var/log/journal. Nach dem nächsten Neustart zeigt journalctl --list-boots mehr als einen Boot.

Schritt 8: Speicherbedarf des Journals prüfen und bereinigen

Logs sind nützlich, dürfen aber nicht unkontrolliert wachsen. Prüfen Sie deshalb den Speicherbedarf gelegentlich und begrenzen Sie ihn bei Bedarf.

journalctl --disk-usage

sudo journalctl --rotate

sudo journalctl --vacuum-size=500M

sudo journalctl --vacuum-time=30d

Die Reihenfolge ist wichtig:

--disk-usage zeigt, wie viel Platz das Journal gerade belegt
--rotate archiviert die aktive Journal-Datei, damit auch sie bereinigt werden kann
--vacuum-size oder --vacuum-time löschen alte archivierte Dateien, bis Größe oder Alter unter dem Grenzwert liegen

Die gelöschten Einträge sind danach endgültig weg. Wer Logs aus rechtlichen oder betrieblichen Gründen aufbewahren muss, sichert sie vorher. Wenn Sie später in Storage- oder Platzthemen tiefer einsteigen, passt die Grundlagenanleitung Festplatten unter Linux einbinden: Partitionen, LVM und fstab.

Verifizieren: journalctl --disk-usage gibt einen konkreten Wert aus, der nach --vacuum-size=500M höchstens bei etwa 500 MB liegt.

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

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

/var/log/syslog auf Ubuntu und auf Debian mit installiertem rsyslog 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 (viele Dateien sind nur mit sudo oder als Mitglied der Gruppe adm lesbar):

less /var/log/syslog

tail -f /var/log/syslog

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

dmesg -T

Für rotierte und komprimierte Logs nutzen Sie die z-Werkzeuge:

zless /var/log/syslog.2.gz

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

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

Der Vorteil: Sie müssen die Dateien nicht erst entpacken. Die Rotation selbst übernimmt meist logrotate, das zeitgesteuert per systemd-Timer oder Cron läuft; zu Cron passt die Anleitung Cron und crontab richtig nutzen: die Grundlagen.

Verifizieren: sudo tail -n 5 /var/log/auth.log (bzw. /var/log/secure) zeigt die letzten Anmeldevorgänge, und sudo zgrep -c . /var/log/syslog.2.gz gibt eine Zeilenzahl aus, sofern rotierte Dateien vorhanden sind.

Troubleshooting

journalctl -u DIENST zeigt nichts: Prüfen Sie 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: Das Journal wird sehr wahrscheinlich nicht persistent gespeichert. Schritt 7 ist in diesem Fall der richtige Fix.
/var/log/syslog existiert nicht: Auf RHEL-artigen Distributionen heißt die Datei /var/log/messages. Auf neueren Debian-Installationen ist rsyslog nicht vorinstalliert; nutzen Sie dort journalctl oder installieren Sie rsyslog nach.
zless oder zgrep fehlen: Dann fehlt meist nur das Paket gzip.
Sie dürfen Logdateien nicht lesen: Dann fehlen passende Rechte oder sudo. Mehr dazu erklärt die 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 Sie dort schnell nach Dienst, Zeit und Priorität filtern können. Den Blick in /var/log ergänzen Sie, wenn Sie distributionsspezifische Dateien oder Anwendungslogs brauchen.

Warum sehe ich nach einem Neustart keine älteren Logs?

Weil das Journal auf Ihrem System nur flüchtig gespeichert wird, meist weil /var/log/journal fehlt. 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 liest nur den Kernel-Ringpuffer des aktuellen Boots. Kernel-Meldungen im Journal zeigt journalctl -k, auch für frühere Boots.

Kann ich mehrere Filter gleichzeitig kombinieren?

Ja, 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 auth.log relevant, auf RHEL-artigen Systemen secure.

Fazit

Wenn Sie Logs unter Linux sicher lesen können, wird Fehlersuche deutlich ruhiger und zielgerichteter. Der wichtigste Lernschritt ist nicht das Auswendiglernen einzelner Befehle, sondern die Reihenfolge: erst verstehen, welche Logquelle Sie brauchen, dann mit journalctl eingrenzen, danach bei Bedarf in klassische Dateien unter /var/log wechseln.

Als nächste sinnvolle Ergänzungen passen 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.