Logs lesen mit journalctl und /var/log

Logs lesen mit journalctl und /var/log ist die Grundlage jeder Linux-Diagnose. Wenn ein Dienst ausfällt, ein Cronjob nicht läuft oder das System sich seltsam verhält, führt der erste Weg immer in die Logs. Auf modernen systemd-basierten Systemen (Debian, Ubuntu, RHEL, CentOS, Rocky Linux) ist journalctl das zentrale Werkzeug. Daneben existieren die klassischen Textlogs unter /var/log, die weiterhin relevant sind – besonders für ältere Dienste oder Distributionen ohne vollständiges systemd-Journal. Diese Anleitung zeigt, wie du beide Welten effizient nutzt, das Journal persistent speicherst und auch rotierte, komprimierte Logs auswertest.

Kurzfassung: Für Service-Logs: journalctl -u DIENST.service. Nur Fehler: journalctl -p err. Live folgen: journalctl -f -u DIENST.service. Persistentes Journal aktivieren: Storage=persistent in /etc/systemd/journald.conf setzen und /var/log/journal anlegen. Klassische Logs in /var/log/syslog, auth.log, kern.log direkt lesen; rotierte .gz-Dateien mit zcat, zless, zgrep.

Voraussetzungen

1. Linux-System mit systemd (Debian, Ubuntu, RHEL, Rocky Linux, Fedora oder vergleichbar)
2. Shell-Zugang (lokal oder per SSH); für manche Befehle sudo-Rechte erforderlich
3. Grundkenntnisse in der Kommandozeile (Navigation, Pipes)
4. Optional: ein laufender Dienst wie nginx oder sshd, um die Filter-Befehle auszuprobieren

Schritt 1: journalctl – erste Orientierung

journalctl liest das binäre systemd-Journal und gibt Logeinträge formatiert aus. Ohne Optionen zeigt es alle gespeicherten Einträge vom ältesten bis zum neuesten – auf aktiven Servern schnell tausende Zeilen. Deshalb ist gezieltes Filtern wichtig.

Die wichtigsten Grundbefehle im Überblick:

# Alle Logs anzeigen (paginiert, neueste zuletzt)
journalctl

# Letzte 50 Einträge anzeigen (Standard: 10)
journalctl -n 50

# Neueste Einträge zuerst (reverse)
journalctl -r

# Ausgabe nicht paginieren (direkt in Terminal)
journalctl --no-pager

# Ausgabe im JSON-Format (für Weiterverarbeitung)
journalctl -o json

Hinweis: Standardmäßig zeigt journalctl nur 10 Zeilen, wenn mit -n kombiniert. Ohne -n wird die gesamte Journal-Ausgabe paginiert. Für Scripts empfiehlt sich --no-pager, damit keine interaktive Paginierung gestartet wird.

Schritt 2: Nach Service filtern mit -u

Der nützlichste Filter im Alltag: Logs eines einzelnen Dienstes gezielt abrufen. Mit -u (Unit) gibst du den systemd-Service-Namen an. Das entspricht dem Einheitennamen aus systemctl status.

# Alle Logs für nginx anzeigen
journalctl -u nginx.service

# Kurzform ohne .service-Suffix funktioniert auch
journalctl -u nginx

# Logs für sshd (SSH-Daemon)
journalctl -u sshd

# Letzten 100 Einträge für einen Service
journalctl -u nginx -n 100

# Mehrere Services gleichzeitig filtern
journalctl -u nginx -u php-fpm

Den exakten Dienstnamen findest du mit systemctl list-units --type=service. Mehr zur Verwaltung von Diensten erklärt die Anleitung systemd-Service erstellen und verwalten.

Schritt 3: Nach Priorität filtern mit -p

Logs werden nach Syslog-Prioritäten eingestuft. Mit -p filterst du auf eine bestimmte Schwere – und alle kritischeren Stufen werden automatisch mitangezeigt.

WertNameBedeutung

0

emerg

System nicht mehr nutzbar

1

alert

Sofortiger Handlungsbedarf

2

crit

Kritischer Fehler

3

err

Fehler

4

warning

Warnung

5

notice

Normales, aber bedeutsames Ereignis

6

info

Informationsmeldung

7

debug

Debug-Informationen

# Nur Fehler (err) und kritischer (crit, alert, emerg)
journalctl -p err

# Warnungen und schlimmer
journalctl -p warning

# Nur Warnungen UND Fehler (kommagetrennt)
journalctl -p warning..err

# Fehler für einen bestimmten Dienst
journalctl -u nginx -p err

Wichtig: -p err zeigt Einträge mit Priorität 0 bis 3 – also alles gleich oder kritischer als „err“. Es werden nicht ausschließlich Einträge der Stufe 3 angezeigt.

Schritt 4: Zeitraum filtern mit --since und --until

Zeitbasiertes Filtern ist unverzichtbar, wenn du einen Vorfall zu einem bestimmten Zeitpunkt analysierst. --since und --until akzeptieren absolute und relative Zeitangaben.

# Logs eines bestimmten Zeitraums
journalctl --since '2026-06-01 08:00:00' --until '2026-06-01 17:00:00'

# Relative Zeitangaben
journalctl --since '2 hours ago'
journalctl --since 'today'
journalctl --since 'yesterday'

# Kombiniert: Service + Zeitraum + Priorität
journalctl -u nginx --since '2026-06-01 00:00:00' -p err

Das Datumsformat ist flexibel: YYYY-MM-DD HH:MM:SS, YYYY-MM-DD, oder Schlüsselwörter wie today, yesterday, 1 hour ago, 5 minutes ago.

Schritt 5: Boot-Logs filtern mit -b und live folgen mit -f

Mit -b filterst du auf einen bestimmten Systemstart. Das ist nützlich, wenn du weißt, dass ein Problem bei einem bestimmten Boot aufgetreten ist. Mit -f folgst du dem Journal live – ähnlich wie tail -f für Textlogs.

# Logs des aktuellen Boots
journalctl -b

# Logs des vorherigen Boots
journalctl -b -1

# Noch frühere Boots (zweivor letzter)
journalctl -b -2

# Alle verfügbaren Boots auflisten
journalctl --list-boots

# Live folgen (alle Logs)
journalctl -f

# Live folgen für einen Service
journalctl -f -u nginx.service

# Kombination: aktueller Boot, nur Fehler, mit Erklärungen, live
journalctl -b -x -f -p err

Die Option -x reichert Logeinträge mit Erklärungen aus dem systemd-Nachrichtenkatalog an. Das ist besonders hilfreich, wenn du einen unbekannten Fehlercode siehst und schnell den Kontext verstehen möchtest.

Hinweis: Vorherige Boots (-b -1 usw.) sind nur verfügbar, wenn das Journal persistent gespeichert wird – dazu in Schritt 6 mehr.

Schritt 6: Persistentes Journal einrichten

Standardmäßig speichert systemd-journald die Logs in /run/log/journal. Dieses Verzeichnis liegt im RAM und wird bei jedem Neustart geleert. Für produktive Systeme solltest du persistente Speicherung aktivieren, damit Logs über Reboots erhalten bleiben.

# Verzeichnis für persistentes Journal anlegen
sudo mkdir -p /var/log/journal
sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal

Anschließend die journald-Konfiguration anpassen:

sudo nano /etc/systemd/journald.conf

Relevante Parameter in /etc/systemd/journald.conf:

[Journal]
# Persistente Speicherung aktivieren
Storage=persistent

# Maximale Gesamtgröße des Journals (Standard: 10% des Dateisystems, max 4 GB)
SystemMaxUse=500M

# Maximale Größe einer einzelnen Journal-Datei (Standard: 1/8 von SystemMaxUse, max 128 MB)
SystemMaxFileSize=50M

# Logs älter als 30 Tage werden automatisch entfernt (optional)
MaxRetentionSec=30day

Änderungen aktivieren:

systemctl restart systemd-journald

Nach dem nächsten Neustart werden alle Logs in /var/log/journal geschrieben und bleiben erhalten. Du kannst jetzt mit journalctl -b -1 auf Logs aus früheren Boots zugreifen.

Schritt 7: Journal-Größe bereinigen mit --vacuum

Das Journal kann mit der Zeit viel Speicherplatz belegen. Mit --vacuum-size und --vacuum-time bereinigst du alte Einträge. Wichtig: Vacuum arbeitet nur auf archivierten Journal-Dateien. Die aktive Datei wird nicht angefasst – deshalb zuerst --rotate ausführen.

# Aktive Journal-Dateien zuerst archivieren
sudo journalctl --rotate

# Journal auf maximal 500 MB begrenzen
sudo journalctl --vacuum-size=500M

# Einträge älter als 30 Tage löschen
sudo journalctl --vacuum-time=30d

# Beides kombiniert
sudo journalctl --vacuum-size=500M --vacuum-time=30d

# Aktuellen Speicherbedarf des Journals prüfen
journalctl --disk-usage

Schritt 8: Klassische Textlogs in /var/log lesen

Auch auf modernen systemd-Systemen schreiben viele Dienste und der Kernel weiterhin direkte Textlogs nach /var/log. Diese sind mit einfachen Texttools lesbar.

DateiInhaltDistribution

/var/log/syslog

Allgemeine Systemlogs

Debian, Ubuntu

/var/log/messages

Allgemeine Systemlogs

RHEL, CentOS, Rocky

/var/log/auth.log

SSH-Logins, sudo, Authentifizierung

Debian, Ubuntu

/var/log/secure

SSH-Logins, sudo, Authentifizierung

RHEL, CentOS, Rocky

/var/log/kern.log

Kernel-Meldungen

Debian, Ubuntu

/var/log/dmesg

Kernel-Ring-Buffer (Boot)

Alle

/var/log/dpkg.log

Paketinstallationen

Debian, Ubuntu

/var/log/apt/history.log

apt-Verlauf

Debian, Ubuntu

# Syslog live verfolgen
tail -f /var/log/syslog

# Auth-Log auf fehlgeschlagene Logins prüfen
grep 'Failed password' /var/log/auth.log

# Kernel-Ring-Buffer anzeigen (aktueller Boot)
dmesg

# dmesg mit Zeitstempeln und menschenlesbarem Format
dmesg -T

# Kernel-Meldungen auf Fehler filtern
dmesg | grep -i error

# Kernel-Logs via journalctl (aus spezifischem Boot)
journalctl -b -k

Schritt 9: Rotierte Logs mit z-Tools lesen

logrotate komprimiert alte Logdateien mit gzip. Du erkennst sie an der Endung .gz (oder einer Zahl wie syslog.1, syslog.2.gz). Für komprimierte Logs gibt es spezialisierte z-Tools – du musst die Dateien nicht erst entpacken.

# Komprimiertes Log ausgeben (wie cat)
zcat /var/log/syslog.1.gz

# Komprimiertes Log paginiert lesen (wie less)
zless /var/log/auth.log.2.gz

# In komprimiertem Log suchen (wie grep)
zgrep 'ERROR' /var/log/syslog.1.gz

# Alle rotierten Syslog-Dateien nach 'error' durchsuchen
zgrep -i 'error' /var/log/syslog*.gz

# Nicht komprimierte rotierte Datei direkt lesen
less /var/log/syslog.1

logrotate wird in der Regel täglich per Cron ausgeführt und komprimiert Logs, die älter als einen Tag sind. Die Konfiguration liegt in /etc/logrotate.conf und /etc/logrotate.d/. Mehr zur Cron-Konfiguration erklärt die Anleitung Cron und Crontab – Grundlagen unter Linux.

Troubleshooting

1. Problem: journalctl -b -1 zeigt „No journal files were found“. Das Journal ist nicht persistent. Schritt 6 dieser Anleitung ausführen: /var/log/journal anlegen und Storage=persistent setzen.
2. Problem: journalctl --vacuum-size löscht wenig oder nichts. Vacuum arbeitet nur auf archivierten Dateien. Zuerst sudo journalctl --rotate ausführen, dann --vacuum-size.
3. Problem: Kein Zugriff auf /var/log/journal ohne sudo. Den eigenen Benutzer der Gruppe systemd-journal hinzufügen: sudo usermod -aG systemd-journal BENUTZERNAME. Danach neu einloggen.
4. Problem: journalctl -f zeigt zu viele Meldungen gleichzeitig. Mit -u DIENST auf einen Service eingrenzen oder mit -p err nur Fehler anzeigen.
5. Problem: /var/log/syslog existiert nicht. Auf RHEL/CentOS/Rocky heißt die Datei /var/log/messages. Alternativ: journalctl verwenden, das überall verfügbar ist.
6. Problem: zcat oder zless nicht gefunden. Paket gzip installieren: sudo apt install gzip (Debian/Ubuntu) oder sudo dnf install gzip (RHEL/Rocky).
7. Problem: Journal wächst trotz konfiguriertem SystemMaxUse. journald bereinigt automatisch nur beim Schreiben neuer Einträge. Manuell: sudo journalctl --rotate && sudo journalctl --vacuum-size=ZIEL.

Häufige Fragen

Wo werden Journal-Logs standardmäßig gespeichert?

Ohne besondere Konfiguration speichert systemd-journald die Logs flüchtig in /run/log/journal. Dieser Pfad liegt im RAM und wird beim Herunterfahren geleert. Für persistente Speicherung muss das Verzeichnis /var/log/journal existieren und Storage=persistent in /etc/systemd/journald.conf gesetzt sein.

Was bedeutet -p err genau – werden wirklich nur Fehler angezeigt?

Nein. -p err zeigt alle Einträge mit Priorität 3 (err) und kritischer – also auch crit (2), alert (1) und emerg (0). Es ist ein „kleiner oder gleich“-Filter. Wer ausschließlich Stufe 3 sehen möchte, kann mit dem Bereich -p err..err arbeiten, aber im Praxisalltag ist der offene Filter sinnvoller.

Wie unterscheiden sich journalctl -b und dmesg?

journalctl -b zeigt alle Journal-Logs des aktuellen Boots – also Meldungen aller Dienste und des Kernels. dmesg zeigt ausschließlich den Kernel-Ring-Buffer, der nur Kernel-Nachrichten enthält. Für Kernel-Meldungen aus dem Journal gibt es journalctl -b -k. dmesg -T ist praktisch, wenn du menschenlesbare Zeitstempel brauchst.

Kann ich mehrere Filter gleichzeitig kombinieren?

Ja, die meisten Filter lassen sich kombinieren. Beispiel: journalctl -u nginx -p err --since 'yesterday' zeigt alle nginx-Fehler seit gestern. Die Filter werden mit UND verknüpft. Nur bei -u mit mehreren Services gilt ODER-Verknüpfung.

Was tun, wenn /var/log/auth.log verdächtige Einträge zeigt?

Fehlgeschlagene SSH-Logins und Brute-Force-Versuche landen in /var/log/auth.log (Debian/Ubuntu) bzw. /var/log/secure (RHEL). Mit grep 'Failed password' /var/log/auth.log siehst du schnell, welche IPs betroffen sind. Als Gegenmaßnahme empfiehlt sich der Einsatz von SSH-Key-Authentifizierung statt Passwort – wie in der Anleitung SSH-Key-Authentifizierung einrichten beschrieben.

Wie lässt sich die Journal-Größe dauerhaft begrenzen?

In /etc/systemd/journald.conf die Parameter SystemMaxUse (Gesamtgröße), SystemMaxFileSize (Einzeldateigröße) und MaxRetentionSec (maximales Alter) setzen. journald erzwingt diese Grenzen automatisch beim Schreiben neuer Einträge. Für eine sofortige Bereinigung: sudo journalctl --rotate && sudo journalctl --vacuum-size=ZIEL.

Fazit

Die Kombination aus journalctl und den klassischen /var/log-Textlogs deckt den gesamten Diagnose-Alltag auf Linux-Systemen ab. Mit gezielten Filtern (-u, -p, --since, -b) findest du relevante Einträge schnell, ohne in langen Ausgaben zu suchen. Persistentes Journal (Storage=persistent) ist auf Produktivsystemen Pflicht – nur so stehen Logs nach einem Neustart zur Analyse bereit. Rotierte Logs sind kein Hindernis, solange du die z-Tools (zcat, zless, zgrep) kennst. Wer diese Grundlagen beherrscht, kann die meisten Dienst- und Systemprobleme eigenständig eingrenzen.

Weiterführende Anleitungen und Quellen

1. systemd-Service erstellen und verwalten – Dienste anlegen, aktivieren und mit journalctl überwachen
2. SSH-Key-Authentifizierung einrichten – Anmeldung absichern, nachdem auth.log Brute-Force-Versuche zeigt
3. Cron und Crontab – Grundlagen unter Linux – logrotate und automatisierte Log-Bereinigung per Cron
4. Linux-Benutzer, Gruppen und Rechte (chmod, chown, sudo) – Berechtigungen für /var/log/journal verstehen
5. Alle Linux-Anleitungen auf s-edv.com

Quellen: journalctl(1) Linux Man Pages (man7.org), journald.conf(5) Debian Manpages, Ubuntu Manpages (Jammy), The Ultimate Guide To Logging – loggly.com. Alle Befehle geprüft gegen die oben genannten Dokumentationsquellen.