Das Journal sammelt alle Meldungen von Systemd. Hier finden Sie ausführlichere Protokolle als bei SysVinit, die früher einsetzen und gezielte Suchen erlauben.

Systemd [1] spaltet die Linux-Welt in Befürworter und erklärte Feinde der mittlerweile in den meisten Distributionen verankerten Systemmanagementsoftware. Die hat nicht nur das überkommene Init-System SysVinit [2] ersetzt, sondern übernimmt an vielen Stellen zunehmend Aufgaben der Administration. Dazu zählt auch das Protokollieren der Ereignisse sowohl des Systems wie der Anwendungen.

Hierzu bringt Systemd das Journal mit, das bisherige Werkzeuge wie Rsyslog [3] ersetzt. Mussten Administratoren zum Lösen eines Problems früher oft mehrere Logs konsultieren und die Ergebnisse vergleichen, so vereint das Journal alle Daten in einer einzigen Instanz und erleichtert so das Auswerten.

Im Gegensatz zu Systemadministratoren bemerken Desktop-Anwender im besten Fall kaum etwas von Systemd. Eine Ausnahme stellt hier eben das Journal dar, denn jeder kommt vermutlich irgendwann in die Verlegenheit, Protokolldateien zu studieren. Um hier zu einem positiven Ergebnis zu kommen, helfen einige Tricks und Kniffe.

Besser strukturiert

Ein Daemon namens Journald sammelt die Meldungen des Kernels, von Initrd, den Diensten und allen anderen verfügbaren Quellen und fasst sie zusammen. So häuft er wesentlich mehr Daten an als die über Jahrzehnte genutzten Log-Dateien wie /var/log/messages oder /var/log/syslog. An vielen Stellen erhalten Sie außerdem Metadaten mitgeliefert, die die Ergebnisse der Suche im Journal unter Umständen wesentlich verfeinern.

Dadurch entsteht allerdings auch ein höheres Aufkommen an Daten, das sich mit den herkömmlichen Textdateien schwer handhaben lässt. Deshalb speichert der Journal-Daemon die Informationen in Binärdateien ab, aus denen Sie die Daten mit administrativen Rechten über den Befehl journalctl wieder auslesen. Bei Bedarf wandeln Sie die Binärdateien in andere Formate um, um sie weiterzuverarbeiten.

Wildwuchs begrenzen

Die Fülle an protokollierten Daten führt dazu, das sich schnell große Dateien ansammeln. Bislang bekamen Sie diesen Wildwuchs beispielsweise über das Tool Logrotate in den Griff, das die Protokolldateien rotiert und komprimiert. Beim Journal von Systemd setzen Sie konkrete Grenzwerte, bei deren Erreichen die Software die Files durchwechselt.

Werfen Sie einen Blick in die entsprechende Konfigurationsdatei. Üblicherweise heißt sie etc/systemd/journald.conf, bei Systemen, die nicht auf Debian beruhen, aber manchmal auch etc/systemd/journal.conf. Hier interessieren zunächst die Einträge SystemMaxUse und SystemKeepFree: Mit dem ersten legen Sie fest, wie viel Platz die Journaldateien in /var/log/journal insgesamt einnehmen dürfen. Der zweite Wert gibt vor, wie viel Platz Sie mindestens frei behalten möchten (Abbildung 1).

Abbildung 1: Das Systemd-Journal wächst unter Umständen recht schnell an. Damit die Platte nicht an die Grenze der Kapazität gelangt, begrenzen Sie die Größe der Journaldateien.

Beide Werte kommen beim Check zum Zug, es greift jeweils der kleinere. Tragen Sie hier keine Werte ein, gilt als Standard für den ersten Wert 10 Prozent des Dateisystems, 15 Prozent für den zweiten. Bei jeweils 4 GByte kappt das Programm automatisch.

Bei den heutigen Größen von Festplatten ist es also durchaus sinnvoll, zumindest bei SystemMaxUse einen Wert im Bereich von 50 MByte bis zu 1 GByte einzutragen. Damit reicht das Journal auf jeden Fall für den Alltagsgebrauch genügend weit zurück. Über SystemMaxFileSize begrenzen Sie bei Bedarf die Größe einzelner Dateien.

Als Einheiten für Größenvorgaben nutzen Sie für den Hausgebrauch K, M, G und T. Wenn Sie Optionen in der journald.conf ändern, entfernen Sie zum Aktivieren das Hash-Zeichen (#) vor der jeweiligen Zeile und starten anschließend den Journal-Daemon neu.

Beständig oder flüchtig

Üblicherweise konfigurieren Distributionen das System zum kontinuierlichen Speichern der Protokolle. Werfen Sie aber ungeachtet dessen einen Blick auf die Zeile Storage: Nur wenn hier als Option persistent steht, landen tatsächlich Logs in /var/log/journal. Möchten Sie die Logs hingegen nicht speichern, setzen Sie den Eintrag auf volatile. Die Logs stehen dann nur während der laufenden Sitzung unter /run/log/journal bereit, anschließend löscht der Daemon sie wieder.

Weitere Optionen zum präzisen Steuern der Journalgröße erläutert die Manpage zu journald.conf. Möchten Sie das Journal etwa im laufenden Betrieb verkleinern, gibt es dazu zwei Optionen. Mit folgendem Kommando kürzen Sie beispielsweise als Root das Journal auf 100 MByte:

# journalctl --vacuum-size=100M

Dabei löscht die Software die ältesten Einträge, bis das Protokoll die gewünschte Größe erreicht. Alternativ schneiden Sie unter Angabe einer Zeit alles Ältere heraus:

# journalctl --vacuum-time=1month

Dieser Befehl würde – ungeachtet der resultierenden Größe der Protokolldatei – alle Meldungen verwerfen, die älter als ein Monat sind (Abbildung 2).

Abbildung 2: Mit Schaltern wie --vacuum-time weisen Sie Journald an, die Protokolldateien zu verkleinern, ohne dazu die Konfiguration ändern zu müssen.

Früher und mehr

Journald zeichnet nicht nur wesentlich mehr Daten auf, als die früheren Protokollmechanismen, sondern beginnt damit früher im Boot-Prozess, als das bislang möglich war. Das hilft dabei, Probleme beim Systemstart leichter einzugrenzen. Wer erinnert sich nicht an Fotos von Monitoren mit einem Startbildschirm, auf dem eine Kernel Panic oder sonstige Probleme den Start des Rechners verhinderten? So etwas gehört mit Systemd weitestgehend der Vergangenheit an.

SysVinit speichert keine Meldungen aus sehr frühen Phasen des Betriebs, da zu diesem Zeitpunkt das Root-Dateisystem noch nicht zum Schreiben eingehängt ist. Systemd erstellt stattdessen zur Laufzeit einen Socket [4], aus dem der Dienst später die gesammelten Meldungen einliest. Damit bietet das Journal – trotz des oft als Problem angesehenen Speicherns als Binärdatei – einige wesentliche Vorteile.

Status und Überprüfung

Es existiert ein Journal für den User und eines für das System. Gehört der Benutzer zur Gruppe systemd-journal, so darf er das Journal als User aufrufen und erhält trotzdem die gesamte Ausgabe. Bevor Sie jedoch die eigentlichen Daten des Journals kennenlernen, stellen wir Ihnen die wichtigsten Befehle zum Überprüfen der Funktion vor.

Den aktuellen Status des Daemons stellen Sie über Systemctl fest (Listing 1). Mit journalctl --disk-usage überprüfen Sie die derzeitige Größe des Journals, während journalctl --verify die Integrität der einzelnen Daten testet (Listing 2).

$ systemctl status systemd-journald
 systemd-journald.service - Journal Service
   Loaded: loaded (/lib/systemd/system/systemd-journald.service; static; vendor preset: enabled)
   Active: active (running) since Mi 2017-02-08 07:16:11 CET; 2h 34min ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 241 (systemd-journal)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-journald.service
            241 /lib/systemd/systemd-journald
Feb 08 07:16:11 acer.local systemd-journald[241]: Runtime journal (/run/log/journal/) is 4.7M, max 38.3M, 33.5M free.
Feb 08 07:16:11 acer.local systemd-journald[241]: Journal started
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

$ sudo journalctl --disk-usage
Archived and active journals take up 4.7M on disk.
$ sudo journalctl --verify
PASS: /run/log/journal/747bced4498d729c8a19f23400000006/system.journal

Um festzustellen, ob die Zeitangaben des Logs zuverlässig sind, überprüfen Sie mit timedatectl status, ob die eingestellte Zeitzone Ihrem Standort entspricht (Listing 3). Die oberste Zeile sollte die aktuelle Zeit anzeigen. Betreiben Sie einen Rechner in einer anderen Zeitzone, passen Sie diese mithilfe des Befehls timedatectl set-timezone Zone an.

$ timedatectl status
      Local time: Mi 2017-02-08 09:47:12 CET
  Universal time: Mi 2017-02-08 08:47:12 UTC
        RTC time: Mi 2017-02-08 08:47:12
       Time zone: Europe/Berlin (CET, +0100)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

Grundsätzlich fordern Sie Auszüge aus dem Journal immer mit dem Befehl journalctl an. Standardmäßig kommt dabei zur Anzeige automatisch der Pager Less zum Einsatz. Er ermöglicht, zeilen- oder seitenweise vor und zurück durch das Protokoll zu blättern. Der Zugriff erfolgt als normaler User, Sie benötigen keine Root-Rechte. Da es sich um Binärdateien handelt, kehren Sie erst nach einem Druck auf [Q] wieder zum Prompt zurück.

Das komplette Journal

Die komplette Ausgabe – deren Umfang richtet sich nach der zulässigen Größe des gesamten Logs und der Laufzeit seit dem letzten Reboot – erhalten Sie mit der Eingabe von journalctl ohne Optionen. Damit sehen Sie alle gespeicherten Logs.

Für jeden Neustart des Rechners fügt die Software die Zeile -- Reboot -- an, um die Informationen voneinander abzugrenzen. Das erweist sich insbesondere dann als sinnvoll, wenn Sie verfolgen wollen, wie lange ein Fehler bereits auftritt. Mit journalctl -p err grenzen Sie dann die Ausgabe bei Bedarf ein: Die Option zeigt über das gesamte Journal hinweg nur Ausgaben des Log-Levels ERROR an.

Normalerweise liegt der Fokus aber eher auf zeitnahen oder gefilterten Ausgaben. So führt journalctl -b nur die Protokolle seit dem letzten Booten auf. Interessiert Sie dagegen der vorletzte Start, so kommt journalctl -b -1 zum Einsatz. Alle im Journal gespeicherten Boot-Vorgänge zeigt der Befehl journalctl --list-boots (Listing 4). Den Wert aus der ersten Spalte der Ausgabe nutzen Sie bei journalctl -b -Zahl anstelle des Platzhalters.

$ sudo journalctl --list-boots
 0 9e814cbee30a47ea85a58a5674829a95 Mi 2017-02-08 07:16:11 CET-Mi 2017-02-08 09:47:12 CET

Nach Zeit gefiltert

Bei Bedarf geht das alles noch viel genauer: Bei Rechnern oder Servern mit langen Laufzeiten zwischen den Starts greift eine Auswahl nach Boot-Vorgängen oft zu kurz. Hier bietet sich eher ein Zeitfenster in Kombination mit anderen Optionen an. Das Zeitfenster grenzen Sie mit den Optionen --since und --until bis auf die Sekunde genau ein.

In der Praxis sieht das etwa so aus wie in der ersten Zeile von Listing 5 oder – bei der Kombination beider Optionen – so wie in der zweiten Zeile. Es geht aber auch allgemeiner, wie die beiden letzten Zeilen demonstrieren. Dabei müssen Sie Datum und Zeit grundsätzlich in der Form YYYY-MM-DD HH:MM:SS angeben.

$ sudo journalctl --since "2017-01-20 15:15:23"
$ sudo journalctl --since "2017-01-20 15:15:23" --until "2017-01-20 15:23:12"
$ sudo journalctl --since yesterday
$ sudo journalctl --since 10:00 --until "now"

Filtern nach Komponenten

Es gibt weitere Filter, die nach bestimmten Ereignissen suchen. So besteht die Möglichkeit, Meldungen zu einzelnen Komponenten aufzuspüren. Macht etwa der Webserver Probleme, dann geben Sie mit journalctl -u apache2.service die betreffenden Ereignisse aus (Abbildung 3).

Abbildung 3: Journalctl ermöglicht die gezielte Abfrage der Protokolle für einzelne Dienste.

Haben Sie einen Verdacht, wo der Fehler im Zusammenhang mit dem Webserver stecken könne, verfeinern Sie den Filter, indem Sie etwa das Ihnen verdächtige PHP-Modul mit in die Abfrage packen (Listing 6, Zeile 1). Um hier spezifischer einzelne Prozesse, User oder Gruppen zu untersuchen, filtern Sie nach Prozess-, User- oder Gruppen-ID.

$ sudo journalctl -u apache2.service -u php-fpm.service --since yesterday
$ pidof apache2
$ ps aux | grep apache2
$ sudo journalctl _PID=PID
$ id -u www-data
$ sudo journalctl _UID=UID --since today

Dazu suchen Sie zunächst die entsprechende ID. Das gelingt für Prozesse beispielsweise mit Pidof oder ausführlicher mit Ps (Zeile 2 und 3). Den entsprechenden Prozess fragen Sie dann über die Option _PID ab (Zeile 4). Die ID des Users für den Webserver finden Sie unter Debian mit id -u www-data, etwa, um dann entsprechende Ereignisse seit Mitternacht zu ermitteln (Zeile 5 und 6). Alle Filter dieser umfangreichen Gruppe lassen Sie sich mit man systemd.journal-fields anzeigen.

Ebenso besteht die Möglichkeit, nach Meldungen über Anwendungen zu suchen, die sich nicht zu benehmen wissen. Dazu geben Sie lediglich den Pfad mit an. Bei Anwendungen, die Sie über das Paketmanagement installiert haben, lautet der Befehl etwa journalctl /usr/bin/amarok. Ansonsten hilft which Anwendung beim Ermitteln des Pfads für das ausführbare Element der Software.

Kernel-Log inbegriffen

Wollten Sie früher den Puffer für Nachrichten des Kernels auslesen, so kam dabei vermutlich der Befehl dmesg zum Einsatz. Das Journal zeigt diese Meldungen für die derzeitige Sitzung mit journalctl -k an. Informationen zu früheren Sitzungen holen Sie mit journalctl -k -b -n hervor.

Der Parameter -p kam bereits in einem anderen Beispiel zum Einsatz. Er bestimmt die Priorität der angezeigten Meldungen. So zeigt der oben genutzte Befehl journalctl -p err Nachrichten mit der Priorität Error sowie den darüberliegenden Prioritäten Critical, Alert und Emergency an. Sie verwenden diese entweder über den Namen oder über den zugeordneten Wert. Die Level haben die Entwickler von Syslog übernommen, Sie finden eine Erläuterung etwa in Wikipedia [5].

Auswertungsmöglichkeiten

In Zeiten vor Systemd mussten Sie, wenn das System etwa einen angesteckten USB-Stick nicht erkannte oder einhängte, die Ausgabe von Dmesg mit dem Kommando tail -n 10 untersuchen, um die letzten zehn Zeilen der Ausgabe zu sehen. Journalctl bringt eine solche Funktion bereits eingebaut mit: Hier genügt der Aufruf journalctl -n Anzahl zur Ausgabe der letzten Anzahl Zeilen.

Früher kam tail -f zum Einsatz, um die Ausgabe von Log-Files laufend zu verfolgen. Bei Systemd genügt ein schlichtes journalctl -f für diesen Zweck. Sie verfolgen so bei Bedarf sogar nur die Ausgaben einzelner Dienste live mit – um wieder im Beispiel zu bleiben, mit dem Befehl journalctl -u apache2 -f. Die fortlaufende Ausgabe stellen Sie mit [Strg]+[C] wieder ab.

Ausgabe in anderen Formaten

Wollen Sie ein Journal in irgendeiner Form weiterverarbeiten, so geben Sie dazu die Daten in verschiedenen Formaten aus, im einfachsten Fall als schlichte Textdatei für die Stufe Error (Listing 7). Andere Formate erzielen Sie mit dem Parameter -o oder --output und der Angabe des Formats. Die Standardausgabe heißt short und entspricht der Ausgabe von Syslog.

$ sudo journalctl -b -p err --no-pager >journal.txt

Die Option -o verbose führt zu einer umfangreicheren Ausgabe mit allen vorhandenen Metadaten und Feldern, wogegen -o cat zu einer gegenüber short nochmals verkürzten Ausgabe führt. Der Parameter -o short-monotonic erhöht die Präzision des Zeitstempels und erlaubt den sicheren Vergleich der Reihenfolge der Ausgaben verschiedener Quellen, der mit den üblichen Zeitangaben nicht immer zweifelsfrei gelingt.

Zum Weiterverarbeiten der Journaldaten mit Webtechnologien erzeugen Sie mit -o json oder, für Menschen besser leserlich, mit -o json-pretty eine Ausgabe in der Javascript Object Notation (JSON). Möchten Sie das Journal in binärer Form über ein Netzwerk exportieren, so hilft die Ausgabe mit -o export weiter.

Reparatur und Sicherheit

Den einzig stichhaltigen Kritikpunkt gegen binäre Log-Dateien stellen mögliche Schäden am Binärformat dar, denn eine Reparaturmöglichkeit gibt es bisher nicht. Jedoch bleiben die eigentlichen Inhalte selbst bei einem korrupten Log meist erhalten. Mit Bordmitteln wie Strings und Grep filtern Sie dann durch ein Kommando wie in Listing 8 noch Informationen heraus.

$ sudo strings /var/log/journal/ID | grep -i Suchbegriff

Für einen kryptografischen Schutz sicherheitskritischer Logs bringt Journal ebenfalls eine eigene Funktion mit. Sie stammt bereits aus dem Jahr 2012 und nennt sich Forward Secure Sealing. FSS erlaubt es, die Logs in zeitlich definierten Abständen zu verschlüsseln. Mit dem Befehl journalctl --setup-keys erzeugen Sie die beiden dazu nötigen Schlüssel. Anschließend drucken Sie den Schlüssel, der zur Verifikation dient, am besten aus oder transferieren ihn per QR-Code auf ein mobiles Gerät.

Fazit

Sobald der Umgang mit dem Journal-Daemon erst einmal in Fleisch und Blut übergegangen ist, dürfte kaum jemand zum Protokollieren vor Systemd zurückkehren wollen. Zu verlockend sind die ausführlicheren Logs, die wesentlich früher einsetzen und umfangreiche sowie einfache Möglichkeiten zum Auswerten bieten.

Falls Sie weiterhin das nicht binäre Format von Syslog nutzen möchten, steht dem trotzdem nichts entgegen: Mittels der Optionen ForwardToSyslog=yes und MaxLevelSyslog=debug in der Datei /etc/systemd/journald.conf leiten Sie die gesammelten Meldungen des Journals um. Dazu muss lediglich zusätzlich der Rsyslogd-Daemon laufen. Der umgekehrte Weg des Einfügens von Meldungen aus Syslog klappt über das Tool Omjournal [6].