Linux ist primär als Serverbetriebssystem konzipiert, darum gehen wichtige Systemmeldungen im Desktop-Kontext leicht unter. Mithilfe von Journalctl bleiben Sie dennoch jederzeit informiert.

Manchmal, wenn auch sehr selten, tritt bei Linux ein Systemabsturz auf, der sich nur noch durch einen Neustart beheben lässt. Bislang kündet nur ein dezentes Blinken der NumLock-LED von diesem Ausnahmezustand. Nun planen die Kernel-Entwickler, das wie bei Windows durch einen Bluescreen zu signalisieren. Das hat in der Community für einige Furore gesorgt [1].

Doch was der Bildschirm anzeigt, wenn ohnehin nichts mehr geht, spielt eine eher untergeordnete Rolle. Wichtig für Anwender ist es zu wissen, dass Meldungen des laufenden Systems, sprich des Kernels und der systemweiten Dienste, innerhalb der grafischen Umgebung eben nicht als Fehlermeldungen auftauchen. Anwender müssen mit dem Aufruf sudo journalctl aktiv nachsehen (Abbildung 1), um diese mitunter wichtigen Meldungen überhaupt zu Gesicht zu bekommen.

Abbildung 1: Der Aufruf von Journalctl als Root verschafft Anwendern Zugriff auf die von Programmen wie Firefox, KDE-Komponenten oder Diensten wie der Dateisynchronisierungssoftware Syncthing ausgesandten Meldungen.

Vorab ein Tipp, der einen Blick in das systemweite Log-Journal manchmal erübrigt: Starten Sie Anwendungen, die Probleme machen, als ersten Schritt immer auf der Konsole. Viele Programme geben hier bereits Meldungen aus, die meist umfassender ausfallen als die keineswegs von allen Programmen eingeblendeten Meldungsdialoge. Damit kommen Sie bei Internetrecherchen schon recht weit.

Buchhaltung

Rufen Sie Journalctl [2] als Root auf, erscheinen die Meldungen des Kernels, der Systemdienste und vieler Anwendungsprogramme in chronologischer Reihenfolge. Ohne Blättern sehen Sie also zunächst die mehrere Wochen bis Monate alten Einträge. Der Aufrufparameter -r dreht die Reihenfolge um, sodass Sie von aktuellen zu älteren Log-Einträgen blättern. Noch immer sehen Sie sämtliche Meldungen, die die Autoren des Kernels, der Systemdienste, der Desktop-Umgebung und der genutzten Anwendungsprogramme für erwähnenswert hielten. Viele davon sind vorwiegend für Entwickler der Programme von Nutzen.

Die Ansicht ändert sich, wenn Sie die Anzeige des Fehlerjournals mit journalctl -p 3 -b 3 auf reine Fehlermeldungen einschränken (Abbildung 2). Diese wirken auf Durchschnittsanwender zwar oft kryptisch, doch irrelevant sind sie keineswegs: Solche Meldungen laufen nur auf, wenn etwas nicht wie erwartet funktioniert. Immerhin sehen Sie am Beginn jeder Zeile den Namen der betroffenen Komponente, sodass die Zuordnung leichtfällt. Man muss diese Protokollzeilen zudem nicht im Detail verstehen, um im Internet nachrecherchieren zu können.

Abbildung 2: Alles auf Rot: Der Parameter -p 3 beschränkt die Ausgabe von Journalctl auf reine Fehler und schließt unkritische informative Meldungen aus.

Die 3 hinter der Option -p steht dabei für die Prioritätsstufe Fehler, die Stufen 0 bis 2 für besonders kritische Fehler. Die Stufe 4 entspricht Warnungen oder potenzielle Fehlerquellen. Die Stufen 5 und 6 umfassen eigentlich unkritische, im Kontext von Fehlfunktionen trotzdem oft interessante Meldungen. Debug-Ausgaben (Stufe 7) sagen meist wirklich nur den Entwicklern einer Software selbst etwas. Der Parameter -p siebt alle Einträge mit niedrigerer als der angegebenen Priorität aus.

Abbildung 2 zeigt ein auf Meldungen der Stufe 3 – sprich: echte Fehler – beschränktes System-Log. Es fällt auf, dass der KDE-Plasma-Window-Manager KWin in der Wayland-Spielart eine Fehlfunktion aufweist. Möchten Sie Problemen bei KWin nachgehen, dann rufen Sie zunächst den Befehl aus der ersten Zeile von Listing 1 auf. Sie sehen nun alle Fehlermeldungen, die den Text kwin_wayland enthalten. Die Größer-als-Zeichen am rechten Rand zeigen an, dass Sie abgeschnittenen Text durch Blättern nach rechts mit den Pfeiltasten einblenden können.

$ sudo journalctl -r -p3 -g kwin_wayland
$ sudo journalctl -g "kwin_(wayland|x11)"
$ sudo journalctl -g kwin_wayland --since "Okt 28:*00:00:00"

Die Option -g von Journalctl verarbeitet wie das klassische Textfilterprogramm Grep [3] nicht nur simplen Text (wie im Beispiel), sondern bei Bedarf auch reguläre Ausdrücke [4]. Das Kommando aus der zweiten Zeile von Listing 1 findet zum Beispiel Einträge mit den Texten kwin_wayland und kwin_x11, also solche zu KWin-Wayland- und KWin-X11-Sitzungen.

Abbildung 3 zeigt einen sogenannten Core-Dump von KWin nach einem Absturz des Plasma-Window-Managers. Ein sinnvoller nächster Schritt bestünde darin, die Meldungen niedrigerer Priorität zu inspizieren, die KWin vor dem Absturz ausgegeben hat. Das gelingt mit dem Aufruf aus der letzten Zeile von Listing 1 und zeigt im Beispiel aus der Abbildung, dass in der halben Stunde vor dem Absturz keine zugehörigen Meldungen vorliegen: Fehlanzeige also.

Abbildung 3: Diese Meldung im System-Journal entstand bei einem Absturz des KDE-Window-Managers.

Möchten Sie bei Problemen mit Hardware oder den Dateisystemen die Meldungen des Linux-Kernels gesondert betrachten, verwenden Sie dazu die Option -k. Sie lässt sich mit allen anderen vorgestellten Optionen wie -r oder --since kombinieren.

Außerdem kennt Journalctl mit --until eine Option zur Anzeige von Log-Einträgen vor einem bestimmten Zeitpunkt, der sich mit --since kombinieren lässt. Dabei versteht Journalctl viele für den Anwender praktische Zeitformate wie 3 weeks ago, kurz 3w ago, 3d ago/3 days ago oder 24-10-15 11:30 (Jahr-Monat-Datum, fakultativ mit Uhrzeit). Details zeigt die Manpage von Systemd.time, die Sie mit man systemd.time aufrufen.

Manchmal identifiziert man das Auftreten von Fehlern leichter anhand von Systemneustarts als über Uhrzeiten. Hier hilft der Aufruf von Journalctl mit -b 0 oder -b 1 für die Zeit seit dem letzten respektive vorletzten Systemstart weiter. Ein journalctl --list-boots zeigt, wie viele Bootvorgänge die Daten zurückreichen.

Interessieren Sie sich nur für systemweite Meldungen, fügen Sie den Filter --system hinzu. Analog funktioniert --user für Benutzerdienste wie die Desktop-Umgebung sowie Anwendungsprogramme.

Statussymbol

Der Parameter -u Unit isoliert Nachrichten für eine bestimmte Systemkomponente. Um diesen Filter zu nutzen, müssen Sie allerdings den Namen kennen, unter dem Systemd den Dienst verwaltet. Eine Liste aller aktiven Dienste zeigt der als Root aufgerufene Befehl systemctl status [5]. Sie sehen darin, welche Dienste auf Ihrem Rechner laufen und nicht zuletzt, ob der Start von Diensten fehlgeschlagen ist. War das der Fall, dann erscheint am Anfang der Ausgabe der Systemstatus degraded in Rot, ansonsten running in grüner Schrift (Abbildung 4).

Abbildung 4: Dieser Aufruf von systemctl status zeigt neben der mit den Pfeiltasten durchblätterbaren Liste aller laufenden Hintergrundprogramme ganz oben den Status degraded. Hier ist ein Dienst nicht gestartet oder abgestürzt (Failed: 1 units, vierte Zeile).

Der Befehl systemctl --failed nennt alle Dienste, die entweder nicht gestartet sind oder unerwartet mit einem Fehlerstatus beendet wurden. Weist zum Beispiel der Webserver Apache2 den Status failed auf, verweigern lokale Webseiten oder Webanwendungen im Browser den Aufruf.

Den Status eines bestimmten Diensts prüfen Sie per systemctl status Unit. Hier steht Unit wieder für den Dienstnamen. Die wichtigsten Zustände heißen inaktiv/dead (installiert, aber nicht aktiviert), running, und failed. Dass ein Dienst den Start verweigert oder mit einem Fehler terminiert, ist nie normal. Sie sollten solchen Angelegenheiten stets per Internetrecherche auf den Grund gehen.

Doch selbst damit sind die Informationsquellen auf Ihrem System noch nicht ganz ausgeschöpft: Sie können das Journal mit journalctl -u Unit gezielt nach Meldungen zu einem bestimmten Dienst befragen. Die Option -u lässt sich mit den anderen vorgestellten Filterparametern kombinieren.

Die geringe Verständlichkeit der Meldungen im Systemlogs entmutigt Laien oft und irritiert gelegentlich selbst alte Hasen. Bedenken Sie aber, dass Sie selten der Einzige sind, bei dem ein bestimmter Fehler auftritt. Um Information dazu im Internet aufzustöbern, brauchen Sie nichts weiter zu tun, als online nach einer konkreten Fehlermeldung zu suchen. Dieser Ansatz liefert viel wahrscheinlicher eine Lösung als die Recherche nach vagen Symptombeschreibungen wie “Firefox stürzt ab”.

Verschlimmbessert

Es muss einen dafür Grund geben, wenn etwas, was bisher klaglos seinen Dienst versah, plötzlich nicht mehr funktioniert. Die naheliegendsten Ursachen sind Aktualisierungen, die eine installierte Software verändert haben, oder Modifikationen in der Konfiguration.

Dass Updates unter Tumbleweed häufiger Probleme verursachen als unter Leap, liegt in der Natur der Sache: In der Rolling-Release-Variante spielen Sie zeitnah neue Softwareversionen ein. Sie bieten zwar verbesserte Funktionen und Lösungen für bekannte Bugs, doch wo gehobelt wird, fallen Späne: Es passiert immer wieder, dass Programmierer beim Weiterentwickeln ihrer Software Regressionen übersehen. So nennt man es, wenn Codeteile, die eigentlich weiterhin unverändert funktionieren sollten, das nicht mehr tun.

Leap dagegen konzentriert sich bei den Aktualisierungen auf Sicherheitslücken, die Veränderungen fallen weitaus geringer aus. Allerdings bergen Backports ihr eigenes Problempotenzial. Dabei pflegen Distributionen und nicht die eigentlichen Entwickler einer Software Fehlerbehebungen aus der neuesten Version in ein ausgeliefertes Paket ein. Die Maintainer geben zwar ihr Bestes, möglichst schnell alle klaffenden Lücken mit auffindbaren Fixes zu verschließen, können die Auswirkungen der Änderungen aber manchmal nicht ausreichend nachvollziehen. So können sich auch bei Leap-Updates Fehler einschleichen.

Falls Sie sich nicht mehr genau erinnern, wann Sie Ihr System zuletzt aufgefrischt haben, rufen Sie als Root zypper-log auf. Das Kommando zeigt Update-Vorgänge als zypper up an, sofern Sie den Aktualisierungsbefehl auf der Konsole ausgeführt haben, wie es ohnehin zu empfehlen ist. Als Nächstes gilt es zu klären, ob das Update überhaupt Pakete aufgefrischt hat, die mit dem zu untersuchenden Problem in Verbindung stehen.

Antwort darauf gibt das Kommando rpm -qa --last | sort -k2 (Abbildung 5). Der erste Teil dieses Aufrufs führt für alle installierten Pakete das Datum der letzten Veränderung auf. Der zweite Teil nach dem Pipe-Symbol (|) sortiert die Liste in der Reihenfolge von alt nach neu. Gehen Sie von dem Zeitpunkt des ersten Auftretens des Problems so weit zurück, bis Sie auf ein damit möglicherweise in Zusammenhang stehendes Paket stoßen.

Abbildung 5: Die RPM-Paketdatenbank hält Installations- und Aktualisierungszeiten aller Paket fest, das Standardwerkzeug Sort sortiert sie chronologisch.

Nicht nur Paketaktualisierungen lösen unter Umständen Fehlfunktionen aus. Manchmal entstehen Probleme im Zusammenspiel mit Hilfsfunktionen, sprich den Abhängigkeiten eines Pakets. YaST, Zypper und RPM geben dann aber nicht die Paketnamen aus, sondern die sogenannten Sonames. Dabei handelt es sich um interne Bezeichner der Bibliothek mit einer Versionsnummer, die so lang konstant bleibt, bis es zu nicht mehr rückwärtskompatiblen Änderungen kommt.

Um die eigentlichen Paketnamen der Abhängigkeiten eines Pakets zu erfahren, installieren Sie das Paket rpmorphan und nutzen das dort enthaltene Skript Rpmdep. In Abbildung 6 zeigt rpmdep inkscape die zwar immer noch lange Liste der Abhängigkeiten von Inkscape. Nun erkennen Sie jedoch immerhin die konkreten Paketnamen, wie sie in der Liste der aktualisierten Pakete stehen.

Abbildung 6: Allein die Zuordnung der Abhängigkeiten des Programms Inkscape zu jüngsten Aktualisierungen bedeutet viel Aufwand. Wer Erfahrung hat, pickt zuerst wahrscheinliche Kandidaten wie Pakete aus dem GTK-Umfeld heraus.

Jedes Update einer Abhängigkeit der streikenden Software ist ein potenzieller Auslöser der Fehlfunktion. Ein höheres Problempotenzial weisen aber naturgemäß große Bibliotheken wie Qt für KDE-Programme und GTK für Gnome-Anwendungen auf. Programme, die die 3D-Beschleunigung der Grafikkarte nutzen, sind eng an Pakete gebunden, deren Namen mit mesa- oder libgl beginnen. Hinzu kommen Pakete mit den Namensbestandteilen nvidia (Nvidia-GPUs) oder amdgup (AMD-Karten).

Kaputtkonfiguriert

Lässt sich kein Update ausmachen, das für Probleme mit dem OpenSuse-System oder einer Anwendung darauf verantwortlich sein könnte, liegt es nahe, nach Veränderungen in der Konfiguration Ausschau zu halten. Dabei sollten Sie damit rechnen, dass Einstellungsänderungen gelegentlich nicht nur wie gewünscht das Verhalten der Software verändern, sondern manchmal Abstürze oder beliebige Fehlfunktionen auslösen.

Am besten nachvollziehen lassen sich Änderungen, die Sie selbst direkt in einer Datei im Verzeichnis /etc oder ~/.config/ vorgenommen haben – zumindest, solang Sie sich noch daran erinnern. Viele Konfigurationsdateien unterstützen Kommentare als Hilfestellung. Es empfiehlt sich, jegliche Änderungen zu dokumentieren und dabei die alten Werte im Kommentar festzuhalten (Abbildung 7).

Abbildung 7: Konfigurationsdateien, die schon von Haus aus Kommentare mitbringen (meist eingeleitet von #), erweitern Sie getrost um eigene Anmerkungen.

Verändern Sie eine Konfiguration per GUI, also über die KDE- oder Gnome-Systemsteuerung oder den Konfigurationsdialog eines Programms, gibt es keine Möglichkeit, Modifikationen zu kommentieren oder alte Werte festzuhalten. Praktisch alle Linux-Programme speichern ihre Konfiguration dennoch in simplen Textdateien, heute meist unterhalb der Verzeichnisse ~/.config/ oder ~/.share/.

Die alte Praxis, Konfigurationen in einem versteckten Verzeichnis abzulegen, dessen Name mit . beginnt und ansonsten dem Programmnamen entspricht, ist noch nicht ganz ausgestorben. Firefox zum Beispiel speichert seine Konfigurationsprofile unter ~/.mozilla/firefox/.

Wer sucht, der findet

Insgesamt ist es also oft nicht einfach, die Dateien zu identifizieren, in der Programme ihre Konfiguration ablegen. Die Dateimanager von KDE und Gnome helfen mit einer handlichen Suchfunktion (Abbildung 8). Bei Dolphin aktivieren Sie sie mit [Strg]+[I], im Gnome-Dateimanager tippen Sie einfach drauflos.

Abbildung 8: Wer im KDE- oder Gnome-Dateimanager per Filterfunktion zum Beispiel nach “akonadi” sucht, findet die zuständigen Konfigurationsdateien im Ordner ~/.config/ schnell.

Lassen sich die Konfigurationsdateien nicht anhand ihres Namens im Dateisystem aufspüren, dann hilft ein simpler Kniff weiter. Verändern Sie einen Konfigurationswert und machen Sie die Änderung gleich wieder rückgängig. Wechseln Sie dann in Ihr Home-Verzeichnis und durchsuchen Sie es mit find . -name ".*" -type f -mmin -1 nach während der letzten Minute veränderten Kandidaten für Konfigurationsdateien. In aller Regel fällt die Liste handlich genug aus, um die richtige Datei schnell auszumachen.

Möchten Sie die momentane Konfiguration mit den Default-Werten vergleichen, schließen Sie zuerst das betreffende Programm und benennen dann die fragliche Konfigurationsdatei um (Abbildung 9). Starten Sie nun das zugehörige Programm oder Ihre Desktop-Umgebung neu, dann legt die Software eine neue Version der Datei an, die Sie mit einem Diff-Viewer wie Meld [6] oder Kompare [7] mit der umbenannten Fassung vergleichen. Alternativ verwenden Sie gleich die Default-Werte weiter.

Abbildung 9: Das per Unterstrich an den Namen einer Konfigurationsdatei (hier für den Editor Kate) angehängte Datum zwingt das Programm dazu, eine neue Default-Version anzulegen, weil es die Konfigurationsdatei nicht mehr findet. Zudem können Sie die alte Konfiguration später wiederherstellen.

Von Anwendern ausgeführte Programme legen beim ersten Start ihre Konfigurationsdateien mit Vorgabewerten selbst an. Bei systemweiten, mit Root-Rechten laufenden Komponenten übernimmt das die Paketverwaltung. Auch hier können Sie Konfigurationsdateien umbenennen, müssen dann allerdings die Software zusätzlich neu installieren. Informationen zu bei der Reinstallation neu eingespielten Konfigurationsdateien liefert das Unterfenster Dateiliste in YaST: Halten Sie dort nach dem Verzeichnis /etc Ausschau (Abbildung 10).

Abbildung 10: Für systemweite Komponenten installiert die Dateiverwaltung die Konfiguration in der Regel unter /etc, überschreibt dabei aber vom Anwender modifizierte Dateien nicht. Erst eine Neuinstallation nach dem Entfernen oder Umbenennen der vorliegenden Dateien sorgt für einen Reset der Konfiguration.

Unter OpenSuse empfiehlt es sich, den ressourcenschonenden und zuverlässigen Snapshot-Mechanismus des standardmäßig genutzten Btrfs-Dateisystems einzusetzen und ihn auf das in der Ausgangskonfiguration ausgesparte Home-Volume auszuweiten: sudo snapper -c home create-config /home legt eine neue Snapper-Konfiguration an, die unter /home/.snapshots/ stündliche Momentaufnahmen des Home-Volumes anlegt. So stehen veränderte Konfigurationen der letzten Tage, Monate und sogar des letzten Jahrs zum Vergleich oder zur Wiederherstellung bereit.

Möchten Sie die identifizierte Konfigurationsdatei mit einer Version in einem Snapshot vergleichen, stehen Sie zunächst vor einem Problem: Unter /home/.snapshots/Ziffer/snapshot/User/ vorgehaltenen Dateien lassen sich mit Anwenderrechten nicht lesen. Kopieren Sie die fragliche Datei also zunächst mit Administratorrechten in Ihr Home und übernehmen Sie mit chown $USER Pfad/zur/Datei deren Besitz. Dann können Sie die Datei aus dem Snapshot und die eigentliche Konfigurationsdatei in einem Diff-Viewer vergleichen oder die gegenwärtige Fassung damit überschreiben.

Fazit

Man könnte es einen Dreisatz nennen: Wer in seinem OpenSuse-System auf neu auftretende Probleme trifft, durchforstet am besten zuerst das System-Journal, überprüft dann, ob die Updates der letzten Zeit als Ursache infrage kommen und überlegt letztlich, ob Konfigurationsänderungen schuld sein könnten. Die hier aufgezeigten Tricks helfen dabei. (uba)