Wenn unter Linux ein Programm abstürzt, verschwindet dessen Fenster in der Regel einfach vom Bildschirm. Wenn eine Festplatte ausfällt, merken Anwender oft erst etwas davon, wenn sie versuchen, auf die Daten zuzugreifen. Linux warnt Anwender in beiden Fällen nicht mit einem Dialogfeld.

Dafür sind alle Fehler und viele weitere informative Meldungen säuberlich mit genauem Zeitstempel, auslösender Komponente, Name des ausführenden Benutzers und vielen weiteren Informationen in einen zentralen Journal registriert (Abbildung 1). Auf modernen Linux-Systemen hat Systemd, die zentrale Managementkomponente für alle Dienste inklusive der grafischen Umgebung, auch das Sammeln der Logmeldungen übernommen.

Wer sucht, der findet

Im Systemd-Paket ist mit „journalctl“ auch gleich ein Werkzeug zur Recherche in diesem in seiner ungefilterten Form umfangreichen Log vorhanden, das das Auffinden einer bestimmten Meldung erleichtert: Die Parameter „–since“ und „–until“ filtern, wie zu erwarten, Einträge einer bestimmten Zeitspanne heraus. Journalctl versteht dabei Angaben wie „yesterday“ oder „20 minutes ago“ sowie Datumsangaben und Uhrzeiten. Die Option „-b“ zeigt Meldungen seit dem letzten oder ab einer bestimmten Anzahl zurückliegender Systemstarts.

Mit anderen Worten: Linux, primär ein remote verwaltetes Serversystem, erwartet vom Anwender, dass er bei Fehlern nachhakt, statt ihn proaktiv zu informieren. Dafür stellt es eine zentrale Logdatenbank zur Verfügung, deren Fähigkeiten weit über das früher übliche textbasierte Syslog hinausgehen, und einen Logviewer, der mit seinen Filterfunktionen (siehe Tabelle „Journalctl: Die wichtigsten Parameter“) das Auffinden von Logmeldungen erleichtert.

Dennoch ist klar, dass auf einem Desktopsystem, bei dem der Anwender vor dem Monitor sitzt, Warndialoge sinnvoll sind: Kritische Fehler bleiben so nicht unbemerkt. Auch ist es leichter, einen Zusammenhang zwischen Fehlern und Ursachen herzustellen, wenn man das Problem sofort bemerkt und nicht erst nach Tagen beim Durchkämmen des Systemlogs.

Liveticker JDN

Wie einfach sich das Einblenden solcher Dialoge auf der bestehenden technischen Basis umsetzten lässt, zeigt die Software Journalctl-Desktop-Notification (JDN, https://tinyurl.com/4bn892y4). Es handelt sich um ein reines Shell-Script, das das System-Journal im Abstand von einigen Sekunden prüft und bei Vorliegen einer neuen Fehlermeldung per Notitfy-Daemon, den viele Desktop­umgebungen unterstützen, ein Dialogfeld einblendet. Im Moment funktionieren bei JDN nur die Buttons „Open“, der das System-Journal in einem Konsolenfenster einblendet, und „Close“, der den Warndialog schließt. „Disable“ soll in Zukunft die gerade offene Fehlermeldung unterdrücken, wie ein offener Bugreport beschreibt. Im Moment ist dazu händisch ein Schlagwort in der Variablen „ERROR_FILTER“ in der Konfigurationsdatei „~/.config/journalctl-desktop-notification.conf“ hinzuzufügen. Zur Nutzung von JDN etwa unter Ubuntu gehen Sie auf https://gitlab.com/Zesko/journalctl-desktop-notification und klicken auf „Code –› tar.gz“, um sich das Tool gepackt herunterzuladen. Entpacken Sie den Download und wechseln Sie im Terminal in das Verzeichnis „journalctl-desktop-notification-master“. 

Mit dem Befehl

sudo cp -r usr/ etc/ /

kopieren Sie JDN-Dateien aus den Unterverzeichnissen „usr“ und „etc“ in die entsprechenden Ordner im Root. Erstellen Sie mit den folgenden Befehlen noch den Ordner „Autostart“ und kopieren Sie die Konfigurationsdatei von JDN in den neuen Ordner.

mkdir $HOME/.config/autostart/

cp /usr/share/applications/journalctl-desktop-notification.desktop $HOME/.config/autostart/

Nach einem Neustart ist das Script JDN aktiv. Zum Testen geben Sie den Befehl sudo echo hello | systemd-cat -p err ins Terminal ein. Es erscheint eine Warnmeldung mit dem Wort „hello“.

Logviewer Lnav

Das Bordmittel Journalctl bringt wie bereits erwähnt leistungsfähige Filterfunktionen mit und ermöglicht eine mit „/“ aktivierbare Volltextsuche. Es färbt jedoch lediglich Fundstellen gelb, Warnmeldungen orange und Fehlermeldungen rot, der restliche Text verbleibt in unübersichtlichem Einheitsgrau. Weitaus bunter treibt es der Logviewer Lnav (https://lnav.org), der außerdem das Navigieren im Log durch Tastatur-Shortcuts wie „1“ und „Shift + 1“ für im Log zehn Minuten vor- oder zurückspringen oder „E“ und „Shift + E“ zu vorherigen Fehlermeldungen in einer nicht auf Fehler begrenzten Loganzeige beherrscht. So kann man ein Log nach echten Fehlern durchkämmen und trotzdem die rein informativen Meldungen direkt davor konsultieren, die potenziell damit in Zusammenhang stehen. Lnav liegt als Snap (sudo snap install lnav) und RPM-Packet auf https://lnav.org bereit. 

Um Lnav im Zusammenspiel mit dem System-Journal einzusetzen, starten Sie ihn mit journalctl | lnav, sodass Journalctl seine Meldungen an Lnav weitergibt. Allerdings dauert es je nach vorgehaltener Systemloggröße lange, bis die Software alle Meldungen des ganzen Journals verarbeitet hat. Es ist daher zu empfehlen, die Journalctl-Ausgabe vorzufiltern: „journalctl -b | lnav“ listet die Einträge seit dem letzten Reboot, „journalctl –since yesterday | lnav“ alle Meldungen seit gestern um null Uhr.

Tipps zum Systemjournal

Die Maximalgröße des Systemjournals lässt sich in der Datei „/etc/systemd/journald.conf“ einstellen: Die Zeile „SystemMaxUse =8G“ (Kommentarzeichen „#“ entfernen) legt eine im Vergleich zum Standardwert verdoppelte Größe fest, sodass sich Fehler länger zurückverfolgen lassen.

Wer Journalctl nicht jedes Mal mit Root-Rechten starten möchte, fügt seinen Benutzeraccount der Gruppe „systemd-journal“ hinzu: „sudo usermod -a -G systemd-journal <Benutzername>“ erledigt dies. Die veränderten Rechte stehen nach einem Reboot zur Verfügung.

Zentrale Sammelstelle

Jede Zeile, die journalctl anzeigt, beginnt mit dem Datum, der Uhrzeit und dem Rechnernamen. Danach folgt die Einheit, die die Meldung erzeugt hat. In eckigen Klammern steht die PID – also die eindeutige Nummer des Prozesses. Anschließend folgt, nach einem Doppelpunkt, die eigentliche Meldung. Wer nach der Bedeutung eines solchen Eintrags im Internet recherchieren möchte, sollte den Namen der aussendenden Einheit gefolgt von der Meldung selbst in das Suchformular eingeben. Die PID variiert von System zu System und stört in der Suche.

Auf modernen Distributionen landen inzwischen alle Logeinträge, von den Meldungen der Systemdienste bis zu den aus dem Startmenü gestarteten Anwendungen, im zentralen Journal. Ausnahmen bilden per Flatpak- und Ubuntu-Snap-Paketen installierte Anwendungen. Denn es gehört zum Konzept von Containern, die darin laufende Software abzuschotten, und dies betrifft auch das Logging. Wie Sie die Meldungen aus dem Container sichtbar machen, ist in den Dokumentation der Paketformate nachzulesen: für Flatpak unter https://tinyurl.com/bd7h9x8c und für Snap unter
https://tinyurl.com/5xh6zdm5.

Softwaremeldungen

Wer die Ausgaben von Software aus distributionsspezifischen RPM- oder DEB-Paketen nachverfolgen möchte, muss das Programm lediglich aus einem Konsolenfenster heraus starten. Meldungen, die dann in der Konsole ausgegeben werden, erreichen das Systemjournal nicht, da eine Shell ihre Ausgabe nicht zum Logdienst weiterleitet.

Die Aufrufe zum Start einer Anwendung auf der Konsole lauten in der Regel wie der Programmname in Kleinbuchstaben. Die Vervollständigung mit der Tabulatortaste hilft dabei, ihn herauszufinden. KDE-Anwender können per Rechtsklick auf einen Startmenüeintrag die „Anwendung bearbeiten“, sprich, sie öffnen den Menüeintrag-Editor und sehen im Feld „Anwendung“ den aufgerufenen Befehl. Gnome-Anwender etwa unter Ubuntu installieren dazu das Programm Alacarte (Installation über sudo apt install alacarte).

Ein Programm auf der Konsole zu starten, ist die unter Linux-Anwendern gängige Erstmaßnahme, wenn ein Programm nach Klick auf den Menüeintrag nicht startet. Abbildung 5 zeigt einen der möglichen Gründe: Hier scheitert das Programm Dolphin aufgrund von unerfüllten Paketabhängigkeiten der Bibliothek „libsasl2.so.3“.

Unter Arch Linux kann dies bei Paketen aus dem AUR nach einem zwischenzeitlichen Distributionsupgrade passieren. Solche Fehler sollten bei offiziellen Distributionspaketen eigentlich nicht auftreten. Falls doch, hilft es oft, das Paket mit der betroffenen Bibliothek neu zu installieren. Welche Bibliothek gemeint ist, lässt sich zum Beispiel über Internetdienste wie https://rpmfind.net/ herausfinden.

Möglicherweise stützt das Programm gleich beim Start mit einem „Speicherzugriffsfehler“ ab (siehe Abbildung 6). Manchmal hilft es dann, die Konfigurationsdaten im Verzeichnis „~/.config“ für das Programm zu löschen: Eventuell verursacht eine bestimmte (Fehl-)Konfiguration den Absturz. Hilft dies nicht, können Sie in der Community nachfragen oder den Fehler an den Entwickler melden.

Hat ein Programm schon öfters Probleme gemacht, während es normal per Startmenü gestartet wurde, dann finden sich zugehörige Meldungen im Systemjournal. Nützlich ist dies unter anderem deswegen, weil sich so der Zeitpunkt des ersten Absturzes ermitteln und mit vorgenommen Updates korrelieren lässt. Es genügt hierfür, „journalct“ die ausführbare Datei zu nennen, zum Beispiel „journalctl usr/bin/kontact“.

Nachrecherchiert

Leider sind die Fehlermeldungen der freien Software aus unterschiedlichsten Quellen unter Linux nicht standardisiert. Doch wenn Softwareentwickler Fehlermeldungen formulieren, fallen sie oft aussagekräftig aus. Drei Beispiele sollen zeigen, wie Anwender die Einträge im Systemjournal mit Hilfe einer Internetrecherche klären und dabei auch Lösungsansätze finden.

1. Hardwarefehler: Abbildung 7 zeigt einen kritischen Fehler: Das Festplattengerät „/dev/sda“, die erste Festplatte, ist nicht mehr les- und beschreibbar, wie die Formulierung „I/O error, dev sda“ in der Abbildung erkennen lässt. Die diese Fehlermeldung ausgebende Einheit ist der „Kernel“ (dritte Spalte nach dem Zeitstempel und Hostnamen), der die Hardware verwaltet. Dass es sich hier um eine ausgefallene Festplatte handelt, lässt sich einfach durch eine Internetsuche „linux i/o error“ herausfinden. Dabei ist auch der Hinweis zu finden, dass es sich möglicherweise nur um einen lockeren SATA-Stecker handelt: Viele dieser Stecker rasten nicht ein und sitzen recht locker.

2. Speicherzugriffsfehler: Die Abbildung 6 zeigt den Absturz des Groupewareprogramms Kontact wegen eines Speicherzugriffsfehlers. Im Systemjournal lässt sich mit 

journalctl /usr/bin/kontact -p err 

ein so genannter Stack Trace des Absturzes finden, der unter anderem diese Zeilen liefert:

Jul 15 13:29:43 gloria6 systemd-coredump[68647]: Process 38676 (kontact)... 

Stack trace of thread 38676:

#0   0x00007fcd244a774c n/a (libc.so.6 + 0x9774c)… 

#3   0x00007fcd2444def0 n/a (libc.so.6 + 0x3def0) 

#4  0x00007fcd244ade22 n/a (libc.so.6 + 0x9de22) 

[...] 

Sie zeigen Softwareentwicklern, welcher Teil des Progammcodes den Absturz ausgelöst hat. Allerdings ist der hier gezeigte Stack Trace wegen der zahlreichen „not-available“/-Kennzeichnungen („n/a“) anstelle eines Funktionsnamens kaum brauchbar. Denn es fehlen auf dem System Entwicklerpakete wie „libstdc++-devel“ und „qt6-devel“. Die genauen Namen unterschieden sich in den Distributionen.

3. Fehlerfreiheit prüfen: Um die Fehlerfreiheit des Gesamtsystems zu testen, empfiehlt es sich, nach einen Systemneustart 

journalctl -k -b -p err 

einzugeben. Die Parameter „-k“ schränken die Ausgabe auf Meldungen des Kernels ein, „-b“ ohne weitere Parameter wählt den Zeitraum ab dem letzten Systemstart und „-p err“ schränkt die Ausgabe auf echte Fehler ein. Der Autor sieht dabei diese Zeilen:

Jul 12 10:28:23 gloria6 kernel: gspca_vc032x: reg_r err -32 

Jul 12 10:28:23 gloria6 kernel: vc032x 1-5.4:1.0: probe with driver vc032x failed with error -32 

Eine Recherche nach „gspca_vc032x“ ergibt, dass es sich hierbei um den Treiber einer Logitech-Webcam handelt, die trotz dieser Meldung einwandfrei funktioniert, sodass man diesen Fehler offenbar ignorieren kann. Doch das Entscheidende ist, dass diese Zeilen auf dem getesteten System die einzigen regelmäßig beim Booten auftretenden sind. Grundsätzliche Probleme bei der Hardwareunterstützung gibt es also nicht.

Eine abschließende Bemerkung: Man sieht Linux an, dass es, anders als Windows, aus lose gekoppelten und von unterschiedlichen Teams entwickelten Komponenten besteht: Das Kernsystem schreibt alle Fehler und informativen Meldungen zuverlässig in ein zentrales Log. Journalctl erschließt die Informationen so, dass sie trotz der Größe des einen Systemjournals leicht zu finden sind. Der Desktop und andere GUIs, die Warndialoge anzeigen können, nehmen den Ball jedoch nicht auf. Mit Journalctl-Desktop-Notification (siehe oben) gibt es dafür jedoch eine nachrüstbare Lösung. 

Journalctl: Die wichtigsten Parameter

Befehl mit Parametern	Kurzbeschreibung
journalctl -b	Log seit letztem Reboot
journalctl -b -1	Sitzung vom vorletzten bis zum letzten Reboot
journalctl -r	Reihenfolge umkehren: von neuer nach älter
journalctl –since/until „2025-06-20 18:17:16“ journalctl –since yesterday journalctl –untill now	Meldungen seit (–since) oder bis (–until) zu einem bestimmten Zeitpunkt mit Beispielen für Zeitangaben, die Journalctl versteht
journalctl -u httpd.service	zeige Meldungen des Systemdiensts „httpd“ (Webserver)
journalctl /usr/bin/kmail	zeige Meldungen des Programms Kmail
journalctl -g „buffer overrun“	Meldungen, die einen bestimmten Text enthalten
journalctl -f	laufend neu hinzukommende Meldungen anzeigen
journalctl -k	nur Meldungen des Kernels zeigen
journalctl -u	nur Meldungen von mit Benutzerrechten laufenden Prozessen zeigen (keine Meldungen vom Kernel und von Systemdiensten)
journalctl _UID=1000	nur Meldungen des Benutzers mit UID 1000 zeigen. Die UID lässt sich mit „id -u “ herausfinden
journalctl -p err	nur Fehlermeldungen zeigen
journalctl -p warning	Fehlermeldungen und Warnungen zeigen
journalctl -p notice	Fehlermeldungen, Warnungen und wichtige informative Meldungen anzeigen