systemd-Journal mit journalctl abfragen: Unit, Boot, Priorität, Zeitraum und JSON-Ausgabe

Ziel

Genau die benötigten Logzeilen aus dem systemd-Journal abrufen – nach Unit, Boot, Priorität und Zeit – in einem Format, das ein Skript auswerten kann, und prüfen, dass das Journal persistent und mit begrenzter Grösse gespeichert wird.

Voraussetzungen

Eine systemd-basierte Distribution, auf der systemd-journald läuft (systemctl status systemd-journald). Zum Lesen der meisten Logs sind root-Rechte oder die Mitgliedschaft in der Gruppe systemd-journal nötig; manche Distributionen schränken den Zugriff weiter ein.

Schritte

1. Über alle Boots hinweg nach Unit filtern: journalctl -u nginx.service --no-pager. --no-pager verhindert, dass journalctl less aufruft und eine nicht interaktive Sitzung blockiert.
2. Auf den aktuellen oder einen früheren Boot beschränken: journalctl -u nginx.service -b (aktueller Boot) oder -b -1 (vorheriger Boot).
3. Nach Priorität filtern: journalctl -p err zeigt die Priorität err und höhere (dringlichere); journalctl -p warning..err wählt einen Bereich aus.
4. Nach absoluter oder relativer Zeit filtern: journalctl --since "2026-09-20 00:00:00" --until "2026-09-21 00:00:00" oder journalctl --since -2h für die letzten zwei Stunden.
5. Filter lassen sich beliebig kombinieren: journalctl -u nginx.service -b -p err --since -1d --no-pager.
6. Maschinenlesbare Ausgabe für ein Skript erzeugen: journalctl -u nginx.service -o json --no-pager (ein JSON-Objekt pro Zeile) oder -o json-pretty zur manuellen Durchsicht; -o cat gibt nur den Meldungstext aus.
7. Prüfen, ob das Journal Neustarts überdauert: Storage= in /etc/systemd/journald.conf (und /etc/systemd/journald.conf.d/*.conf) lesen. persistent schreibt nach /var/log/journal/ (und legt das Verzeichnis bei Bedarf an); auto schreibt nur dorthin, wenn das Verzeichnis /var/log/journal/ bereits existiert, und verhält sich sonst wie volatile, das das Journal in /run/log/journal/ hält und es beim Neustart verliert. Zeigt journalctl --list-boots nur einen Boot an, ist das ein schnell erkennbares Anzeichen für ein nicht persistentes Journal.
8. Den Platzbedarf auf der Platte begrenzen: SystemMaxUse=, RuntimeMaxUse= und SystemKeepFree= in einer Drop-in-Datei unter /etc/systemd/journald.conf.d/ setzen und anschliessend systemctl restart systemd-journald ausführen.

Erwartetes Ergebnis

Die gefilterte Ausgabe beschränkt sich auf die angeforderte Unit, den Boot, die Priorität und das Zeitfenster; journalctl --disk-usage zeigt die aktuelle Journalgrösse an, die unter dem konfigurierten SystemMaxUse= bleiben sollte.

Grenzen und Prüfbasis

Basiert auf journalctl(1) und journald.conf(5). Ein Neustart von systemd-journald unterbricht das Logging kurz, verwirft aber das Journal auf der Platte nicht; um eine Änderung in journald.conf.d rückgängig zu machen, die Drop-in-Datei löschen und den Dienst nochmals neu starten. Läuft auf einer Distribution zusätzlich rsyslog parallel, zeigt journalctl nur, was journald erfasst hat.