Logs lesen mit journalctl

Modul 6: Dienste und Logs · Lesezeit: 11 Minuten

Lernziel: Nach dieser Lektion können Sie mit journalctl gezielt in den Protokollen Ihres Servers suchen (nach Dienst, Priorität und Zeit), wissen Sie, wo andere Logdateien liegen, und verhindern Sie, dass Logs Ihre Festplatte füllen.

Kernbegriffe: journald, Journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, Priorität (err, warning, info), persistente Speicherung, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

Das Protokoll als erster Zeuge

Wenn auf Ihrem Server etwas nicht funktioniert, steht der Grund fast immer in einem Protokoll. Eine Website, die eine Fehlerseite anzeigt, ein Dienst, der nicht startet, ein Backup, das heute Nacht nicht gelaufen ist: Der Server hat es aufgeschrieben. Ein guter Administrator schaut zuerst ins Protokoll und ändert erst danach etwas.

Auf modernen Linux-Servern sammelt journald (Teil von systemd) die Meldungen des Kernels, von systemd selbst und von allen Diensten in einem Protokoll: dem Journal. Sie lesen es mit journalctl.

Um alles lesen zu können, müssen Sie Mitglied der Gruppe adm oder systemd-journal sein oder sudo verwenden. Ohne diese Rechte sehen Sie nur Ihre eigenen Meldungen.

Wo liegt es? Persistent oder flüchtig

journald speichert das Journal an einem von zwei Orten:

• in /var/log/journal/: persistent, die Logs bleiben nach einem Neustart erhalten;
• in /run/log/journal/: flüchtig, im Arbeitsspeicher, nach einem Neustart weg.

Die Standardeinstellung (Storage=auto in /etc/systemd/journald.conf) wählt persistent, wenn das Verzeichnis /var/log/journal/ existiert. Unter Debian legt das systemd-Paket dieses Verzeichnis bereits seit Debian 11 an, und unter Ubuntu existiert es ebenfalls. Prüfen Sie es:

anna@web1:~$ ls -d /var/log/journal
/var/log/journal
anna@web1:~$ journalctl --list-boots | tail -n 3
 -2 3c1f... Sun 2026-11-01 04:30:12 CET Sun 2026-11-08 04:30:01 CET
 -1 9ab7... Sun 2026-11-08 04:30:40 CET Mon 2026-11-09 08:12:05 CET
  0 e41d... Mon 2026-11-09 08:12:30 CET Mon 2026-11-09 11:40:17 CET

Sehen Sie nur einen einzigen Startzeitpunkt, obwohl der Server schon einmal neu gestartet wurde, dann sind Ihre Logs flüchtig. Legen Sie das Verzeichnis an (sudo mkdir -p /var/log/journal und sudo systemd-tmpfiles --create --prefix /var/log/journal) und starten Sie journald neu. Das ist wichtig: Nach einem Absturz möchten Sie gerade wissen, was vor dem Neustart passiert ist.

Seit Debian 12 installiert Debian rsyslog nicht mehr standardmäßig. Dieses Programm schrieb früher Textdateien wie /var/log/syslog und /var/log/auth.log. Auf einem neuen Debian-Server existieren diese also nicht; alles steht im Journal. Ubuntu hat rsyslog noch. Anleitungen, die sagen "schauen Sie in /var/log/auth.log", können Sie unter Debian in journalctl -u ssh übersetzen.

Suchen: die Filter, die Sie wirklich verwenden

Ohne Filter zeigt journalctl alles, beginnend mit dem Ältesten. Das ist selten, was Sie wollen. Die wichtigsten Filter, die Sie kombinieren können:

Die Prioritäten reichen von 0 (emerg) bis 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. Mit -p err erhalten Sie err und alles, was schwerwiegender ist. -p warning zeigt auch Warnungen.

Ein typischer Suchweg. Ihre Website liefert seit heute Morgen einen Fehler 502:

anna@web1:~$ systemctl status php8.4-fpm
× php8.4-fpm.service - The PHP 8.4 FastCGI Process Manager
     Active: failed (Result: exit-code) since Mon 2026-11-09 07:02:11 CET; 4h ago
...
anna@web1:~$ sudo journalctl -u php8.4-fpm --since today -p warning --no-pager
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: [/etc/php/8.4/fpm/pool.d/www.conf:42] unknown entry 'pm.max_children '
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: FPM initialization failed
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Main process exited, code=exited, status=78/CONFIG
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Failed with result 'exit-code'.

Die Ursache steht wörtlich da: ein Tippfehler in Zeile 42 einer Konfigurationsdatei. Der Status 78 (CONFIG) bestätigt, dass es sich um einen Konfigurationsfehler handelt. Sie müssen nichts raten.

Zwei Tipps zum Lesen:

• Lesen Sie von oben nach unten und suchen Sie den ersten Fehler. Ein Fehler verursacht oft eine ganze Reihe von Folgemeldungen. Der erste ist meistens die Ursache.
• Achten Sie auf die Uhrzeit. Was hat sich um diesen Zeitpunkt geändert? Ein automatisches Update (Lektion 4.2: /var/log/unattended-upgrades/), eine Änderung von Ihnen, ein Neustart?

Andere Logdateien

Nicht alles steht im Journal. Viele Programme schreiben auch (oder nur) eigene Dateien in /var/log/:

Große Textdateien lesen Sie mit less (suchen mit /), das Ende mit tail -n 50, live mit tail -f und filtern mit grep:

anna@web1:~$ sudo grep " 502 " /var/log/nginx/access.log | tail -n 5

Die Logs von Docker-Containern liegen nicht in /var/log, sondern bei Docker selbst: docker compose logs (Lektion 9.3).

Logs dürfen Ihre Festplatte nicht füllen

Eine volle Festplatte ist eine der häufigsten Ursachen dafür, dass ein Server "plötzlich" nicht mehr funktioniert: Datenbanken stoppen, Updates schlagen fehl, manchmal können Sie sich nicht einmal mehr anmelden. Logs sind oft die Schuldigen.

Das Journal begrenzt sich selbst. Standardmäßig belegt es höchstens 10 % des Dateisystems, maximal 4 GB (SystemMaxUse=). Wie viel es aktuell belegt und wie Sie aufräumen:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # älter als 30 Tage entfernen
anna@web1:~$ sudo journalctl --vacuum-size=500M    # bis 500 MB

Möchten Sie eine feste Grenze, tragen Sie in einer Drop-in-Datei /etc/systemd/journald.conf.d/grootte.conf Folgendes ein:

[Journal]
SystemMaxUse=1G

und starten Sie journald mit sudo systemctl restart systemd-journald neu.

Textdateien in /var/log werden von logrotate verwaltet: Jeden Tag oder jede Woche wird eine Datei umbenannt (error.log.1), ältere Versionen werden komprimiert (.gz) und die ältesten gelöscht. Die Regeln pro Programm stehen in /etc/logrotate.d/. Pakete aus der Distribution bringen ihre eigene Regel mit. Schreibt ein eigenes Programm oder Skript in eine eigene Logdatei, legen Sie selbst eine Regel an, sonst wächst die Datei endlos.

Herausfinden, was Platz belegt:

anna@web1:~$ df -h /
anna@web1:~$ sudo du -xh /var/log | sort -h | tail -n 5

Logs und Datenschutz

Protokolle enthalten IP-Adressen, Benutzernamen und manchmal E-Mail-Adressen: Das sind personenbezogene Daten. Bewahren Sie sie nicht länger als nötig auf (einige Wochen bis einige Monate sind für einen kleinen Server üblich), machen Sie sie nicht öffentlich zugänglich (ein Verzeichnis /logs in Ihrem Webroot ist ein bekannter Fehler) und kopieren Sie sie nicht einfach zu Diensten Dritter.

Unter AlmaLinux und Rocky Linux

journalctl funktioniert genauso. Dort ist rsyslog noch standardmäßig aktiv, mit Dateien wie /var/log/messages und /var/log/secure (das Gegenstück zu auth.log). Meldungen von SELinux stehen in /var/log/audit/audit.log; ausearch -m avc -ts recent zeigt aktuelle Verweigerungen.

Zusammenfassung

• journald sammelt alle Meldungen im Journal; lesen Sie es mit journalctl, gefiltert nach Dienst (-u), Priorität (-p), Zeit (--since) und Systemstart (-b).
• Prüfen Sie, ob das Journal persistent ist (/var/log/journal existiert), sonst sind Ihre Logs nach einem Neustart verloren.
• Debian 12 und neuer haben standardmäßig kein rsyslog und damit kein /var/log/auth.log und /var/log/syslog; alles steht im Journal.
• Suchen Sie den ersten Fehler und schauen Sie, was sich um diesen Zeitpunkt geändert hat.
• Behalten Sie die Größe im Blick: Das Journal begrenzt sich selbst (--disk-usage, --vacuum-*), Textdateien regelt logrotate.

Quiz

Aufgabe

Aufgabe Z6.2: Einen abstürzenden Dienst analysieren. In der Beispieldatei journal-crash-1.txt steht die Ausgabe von systemctl status und journalctl eines Dienstes, der immer wieder neu startet und dann aufgibt. Beantworten Sie: Wie heißt der Dienst, wie oft hat systemd versucht, ihn zu starten, mit welchem Exit-Code wurde er beendet, was ist laut der ersten Fehlermeldung die Ursache, und um wie viel Uhr hat systemd aufgegeben? Das Programm vergleicht mit dem festen Lösungsschlüssel. Prüfen Sie anschließend auf Ihrem eigenen Server, ob journalctl -p err -b Fehler anzeigt und ob Ihr Journal persistent ist.

Weiterführende Informationen

• Handbuch journalctl(1): https://manpages.debian.org/trixie/systemd/journalctl.1.en.html
• Handbuch journald.conf(5) (Storage=, SystemMaxUse=): https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html
• Debian 12, Release Notes 5.1.7 (rsyslog nicht mehr standardmäßig): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html