Der Log-Betrachter Journalctl und das YaST-Modul Systemd-Journal unterstützen Sie beim Auswerten der Systemprotokolle und der Fehlersuche.

Der Webserver startet nicht, die Desktop-Umgebung hängt oder Firefox stürzt gleich nach dem Start ab. Einfach nur im Internet nach “Apache startet nicht”, “Plasma hängt” oder “Firefox stürzt ab” zu suchen, hilft selten weiter: Es gibt viele mögliche Ursachen für solche Fehlfunktionen. Selbst ein genau lokalisiertes Problem lässt sich mit unterschiedlichen Worten beschreiben; per Schlagwortsuche gelangt man oft nur schwer an Informationen.

Die Fehlermeldungen einer streikenden Software dagegen fallen in aller Regel distributionsübergreifend gleich aus und eignen sich daher viel besser, um per Suchmaschine nach einer Lösung zu suchen, als das Beschreiben der Problematik alleine. Fast immer sind andere Anwender schon über dasselbe Problem gestolpert, und konnten in vielen Fällen, oft mit Unterstützung der Entwickler der betroffenen Software, eine Lösung finden.

Alles mitschreiben

Wie die letzte Ausgabe der OpenSuse-Tipps erläutert hat, ist Systemd zum Standard für die Steuerung der Systemdienste avanciert. Doch diese noch vergleichsweise neue Systemkomponente startet nicht nur Hintergrunddienste, sie sammelt auch deren Meldungen und bündelt sie in einer durchsuchbaren Datenbank. Wie so oft bei der Systemadministration arbeitet das primäre Werkzeug zum Durchsuchen dieser Datenbank, Journalctl, auf der Kommandozeile (Abbildung 1).

Abbildung 1: Die erste rote Zeile im Systemlog dokumentiert einen Absturz des Programms Tracker-extract. Der folgende Stack-Trace gibt Software-Entwicklern Aufschluss über die inneren Vorgänge im Programm, die zum Absturz geführt haben.

Die letzten OpenSuse-Tipps haben bereits einen Journalctl-Aufruf vorgestellt. Diesmal starten wir mit dem YaST-Modul Systemd-Journal, das eine grafische Oberfläche dafür bereitstellt (Abbildung 2). Nach dem Start zeigt es eine Tabelle aller Meldungen der letzten 24 Stunden an. In der Zeile Quelle zeigt das Programm den Urheber der Meldung an: entweder ein Systemdienst, der Linux-Kernel oder auch eine normale Anwendung wie Firefox.

Abbildung 2: Das YaST-Modul Systemd-Journal zeigt nach dem Start das ganze System-Log eines Tages, bietet aber etliche Möglichkeiten, Informationen aus dem Zeichensalat herauszufiltern (unten).

Das Systemd-Log und der Log-Viewer Journalctl ersetzen das klassische Syslog, das unter OpenSuse in der Standardkonfiguration allerdings immer noch mitläuft und die Meldungen parallel in der Textdatei /var/log/messages mitschreibt. Sie bleibt nach einem Neustart des Systems erhalten, während das modernere Journalctl-Log bei OpenSuse in der Standardeinstellung mit jedem Neustart verfällt.

Das können Sie jedoch durch Anpassen einer Zeile in einer Konfigurationsdatei ändern: Öffnen Sie als Root die Konfigurationsdatei /etc/systemd/journald.conf, und ändern Sie die Zeile #Storage=auto in Storage=persistent, entfernen Sie also das Raute-Zeichen am Anfang, und korrigieren Sie den Wert hinter dem Gleichheitszeichen. Starten Sie anschließend, ebenfalls als Root, den Journal-Dienst mit systemctl restart systemd-journald neu.

In der Textflut in Abbildung 2 erscheint es schwierig, Meldungen zu einem bestimmten Thema zu finden. Einen erster Ansatz, die Anzahl der Meldungen einzudämmen, bietet das Suchfeld oben im Fenster. Doch diese Suchfunktion durchkämmt undifferenziert alle Textfelder: Die Eingabe von kernel filtert nicht nur Meldungen der Quelle kernel heraus, sondern auch alle anderen, deren Meldungstext das Wort “Kernel” enthält.

Für eine bessere Eingrenzung klicken Sie daher auf den Button Filter ändern rechts unten. Im daraufhin erscheinenden Dialogfenster schränken Sie in der ersten Zeile den Zeitraum ein. Auf diese Weise lassen Sie sich etwa gleich nach Auftreten eines Problems die Meldungen nur der letzten fünf Minuten anzeigen. Wenn Sie davon ausgehen, dass das Problem seit dem Neustart nach einem Update auftritt, dann wählen Sie statt zwischen diesen Datumsangaben die Option Seit dem Systemstart eine Zeile weiter unten.

Die Option Mit mindestens dieser Priorität trennt Fehlermeldungen von rein informativen Meldungen. Die englische Bezeichnung dieser Meldungseinstufung heißt severity, also eigentlich Schweregrad. Sieben Stufen von 0 (Emerg, für “emergency”) bis 7 (Debug) sind gebräuchlich. Schweregrad 0 steht für ein Ereignis, das das ganze System unbenutzbar macht. Fehler der Stufe Crit (“critical”) bedeuten in der Regel, dass ein Datenverlust droht. Bei Stufe 3 handelt es sich um normale Fehler, bei denen etwas nicht wie gewünscht funktioniert. Warnings stehen für mögliche oder drohende Fehler. Bei den Stufen 5 bis 7 handelt es sich um informative Hinweise unterschiedlicher Wichtigkeit.

Um nur Fehlermeldungen zu sehen, schränken Sie die Anzeige im Dropdown-Feld Mit mindestens der Priorität auf err ein (YaST benutzt teilweise, aber nicht durchgängig Abkürzungen der englischen Schweregrade). Abbildung 3 zeigt sieben Meldungen, die auf einem Testsystem nach Eingrenzen auf den Schweregrad err in der Liste verbleiben.

Abbildung 3: Grenzen Sie die Anzeige des YaST-Moduls auf die Priorität err ein, dann verschwinden rein informative Angaben, und nur echte Fehlermeldungen bleiben zurück.

Startproblem

Gehen wir davon aus, Sie haben, wie in der letzten Ausgabe der OpenSuse-Tipps beschrieben, den Apache-Webserver-Dienst gestartet und dabei auch dessen Konfigurationsdateien angepasst. Sie können jedoch keine Verbindung zu http://localhost aufbauen (Abbildung 4) – kein Wunder, in der YaST-Liste sehen Sie die Meldung von Systemd, dass es den Webserver Apache nicht starten konnte (Abbildung 5).

Abbildung 4: Unter http://localhost sollte sich der zuvor installierte Webserver melden, doch es kommt keine Verbindung zustande.

Abbildung 5: Dass der Server aufgrund eines Syntax-Fehlers in einer Konfigurationsdatei nicht starten konnte, stuft Apache als bloße Info ein.

Nun wäre es angemessen, wenn der Apache-Dienst aussagekräftige Meldungen der Stufe Error ausgegeben hätte, die dann in der nach diesem Schweregrad gefilterten Liste sichtbar sein müssten. Schließlich schlug der Start des Diensts fehl. Die Realität sieht anders aus: Apache stuft die Meldungen, die im Zusammenhang mit seinem gescheiterten Start stehen, als bloße unkritische Informationen ein.

Um dennoch an die Meldungen zu gelangen, die Ihnen weiterhelfen, filtern Sie die Anzeige daher nach der Systemd-Einheit apache2 und nicht nach Priorität, wie in Abbildung 5. Unter den nun ausgegebenen Meldungen finden Sie schnell die Ursache für den missglückten Start: Die Konfigurationsdatei /etc/apache2/default-server.conf enthält in Zeile 12 einen Syntax error.

Den Namen des Diensts apache2 erschließen Sie sich, wie in der letzten Ausgabe erläutert, indem Sie im Paketmanager das Paket Apache nach einer Datei mit der Endung .service im Verzeichnis /usr/lib/systemd/system durchforsten.

Schneller geht es, wenn Sie auf der Kommandozeile systemctl status apach tippen und zur automatischen Vervollständigung des Dienstnamens die Tabulatortaste drücken. Beim Warten auf die Vervollständigung ist Geduld gefragt, sie dauert manchmal mehrere Sekunden. Gelegentlich lautet der Unit-Name auch anders als erwartet; dann hilft nur die Suche im Paketmanager.

Vordergrundprogramme

Unterhalb des Filterfelds für Systemd-Einheiten (Units) gibt es noch ein Suchfeld für ausführbare Dateien oder Gerätedateien. Darüber filtern Sie Meldungstexte eines bestimmten Programms oder einer Systemkomponente heraus, bei der es sich nicht um einen von Systemd gestarteten Hintergrunddienst handelt. Dabei kann es sich um eine normale Anwendung wie Firefox handeln, die Sie per Startmenü aufrufen, aber auch um eine Komponente der Desktop-Umgebung, wie KDEs Plasma-Shell, die für die Desktop-Oberfläche und die Leisten zuständig ist.

In dieses Suchfeld gehört der gesamte Dateipfad zur ausführbaren Datei eines Programms. Auch wenn Sie Firefox auf der Konsole mit firefox starten können, weil die Shell automatisch alle in der Variablen PATH genannten Verzeichnisse nach einer passenden Datei durchsucht, lautet der volle Pfad /usr/bin/firefox. /usr/bin/ ist dabei fast immer die richtige Ergänzung.

Möchten Sie sichergehen, geben Sie auf der Konsole which firefox ein, um den vollständigen Pfad herauszufinden. Wissen Sie nicht, wie ein Programm auf der Kommandozeile zu starten ist, dann bleibt nur die Suche nach unter /usr/bin/ abgelegten ausführbaren Dateien im zugehörigen Programmpaket (Abbildung 6).

Abbildung 6: Der Reiter Dateiliste zeigt die ausführbare Programmdatei /usr/bin/firefox fett hervorgehoben an.

Abbildung 7 zeigt die nach der ausführbaren Datei /usr/bin/plasmashell gefilterte Log-Ausgabe, zusätzlich eingeschränkt nach Schweregrad Warnung. Erfahrungsgemäß treten solche Warnungen bei der Benutzung von KDE ständig auf, ohne dass es zu erkennbaren Fehlfunktionen kommt. Sollte aber der Desktop Probleme bereiten, so wissen Sie nun, wie Sie die Log-Meldungen der Plasma-Shell – immerhin einer der Hauptkomponenten von KDE – prüfen.

Abbildung 7: Obwohl augenscheinlich alles normal funktioniert, wirft die KDE-Komponente Plasma-Shell wild mit Warnungen um sich.

Sie können diese Meldungen in Foren posten. Versierte Anwender oder vorbeischauende Entwickler erkennen dann viel genauer, woran es hakt, als wenn Sie das Problem nur in eigenen Worten beschreiben. Auch bei Bugreports (Abbildung 8) erhöhen mitgelieferte Fehler- oder Warnmeldungen die Chance, dass die Entwickler den Fehler finden und ausbügeln.

Abbildung 8: Mit Bugreports, die außer der Beschreibung eines Problems auch noch die Fehlerausgabe mitliefern, können die Entwickler der Software deutlich mehr anfangen.

Um an solche Meldungen zu gelangen, könnten Sie bei bekannten Problemen auch die betreffende Anwendung auf der Konsole starten und die dort ausgegebenen Meldungen beobachten und aufzeichnen. Mit diesem Verfahren können Sie aber, anders als beim Auslesen des Logs, nicht in die Vergangenheit blicken.

Direktzugriff

Das YaST-Modul Systemd-Journal dient wie schon erwähnt nur als grafische Oberfläche für das Kommandozeilenprogramm Journalctl, das auf jedem aktuellen OpenSuse-System zur Verfügung steht. Tatsächlich ist der Leistungsumfang des YaST-Moduls nicht besonders groß, und die wenigen Kommandozeilenoptionen, mit denen es Journalctl im Hintergrund aufruft, lassen sich leicht verstehen.

Um Systemmeldungen zu erhalten, müssen Sie Journalctl stets als Root aufrufen. Die Meldungen der letzten fünf Minuten sehen Sie mit dem Kommando journalctl --since "5 minutes ago" ein. Journalctl ist recht intelligent beim Verstehen von Zeitangaben: Sie können auch --since 3 days ago angeben, --since "2019-9-12" oder --since "2019-9-12 15:13".

Nach Eingabe von journalctl -b erscheinen alle Meldungen seit dem Systemstart auf der Konsole. Haben Sie wie beschreiben das Journal auf persistente Festplattenspeicherung umgestellt, dann sind auch die Optionen -b -1, -b -2 und so weiter für den Zeitraum ab dem vorletzten, vorvorletzten und weiterer Systemstarts verfügbar.

Mit der Option -u Unit.service filtern Sie die Meldungen nach der Systemd-Einheit oder Unit. Um nur Meldungen zu sehen, die zu einer ausführbaren Datei wie /usr/bin/firefox gehören, rufen Sie einfach journalctl /usr/bin/firefox auf. Der Befehl journalctl -f zeigt live die Meldungen, die ab dem Aufruf von Journalctl auflaufen. Rechnen Sie schon beim Start eines Diensts mit Komplikationen, empfiehlt es sich, die Option -u für eine bestimmte Unit und -f für laufende Aktualisierung zu kombinieren.

Fazit

Wann immer Sie Probleme mit Software lösen möchten, lautet der Königsweg: Konsultieren Sie die Meldungen in den Logs. Zwar ist dort nicht immer etwas Relevantes zu sehen: Nicht alle Entwickler schenken dem Logging die eigentlich gebotene Aufmerksamkeit. Meist zeigen die protokollierten Informationen jedoch versierten Anwendern oder den Entwicklern der fraglichen Software viel genauer, was klemmt, als jede noch so minutiöse Problembeschreibung. Auch gelingt es anhand der Fehlermeldungen am leichtesten, im Internet andere Benutzer aufzuspüren, die mit demselben Problem kämpfen.

Das YaST-Modul Systemd-Journal bietet einen guten Einstieg für Anwender, die sich ungern mit der Konsole befassen. Die wichtigsten Filterfunktionen für das umfangreiche System-Log, das Filtern nach Start- und Endzeit, nach Systemd-Unit oder ausführbarer Datei sowie nach Schweregrad sind bequem per Texteingabefeld umgesetzt. Wer sich nicht vor dem Einsatz von Konsolenprogrammen scheut, bekommt mit Journalctl dieselben Recherchemöglichkeiten und noch einige mehr [1].

Unverständlich bleibt, warum OpenSuse das Systemd-Journal, das mit seinen Filtern die Fehlersuche gegenüber der unstrukturierten Textdatei /var/log/messages erheblich erleichtert, immer noch stiefmütterlich behandelt und nicht über einen Systemneustart hinweg aufbewahrt. Abhilfe schafft allerdings wie erläutert das Anpassen einer einzigen Zeile einer Konfigurationsdatei.