Linux & Diagnose

journalctl für Einsteiger: Linux-Fehler in Systemlogs finden

Protokolle gezielt lokal lesen

Die Abfragen lesen lokale Journale und laden nichts hoch. Logs können Benutzernamen, IP-Adressen und vertrauliche Meldungen enthalten. Prüfe einen Ausschnitt vor dem Teilen.

In diesem Artikel
  1. Was steht im Journal?
  2. Den richtigen Boot auswählen
  3. Einen Dienst statt das gesamte System lesen
  4. Zeitraum und Priorität kombinieren
  5. Eine eigene Meldung wiederfinden
  6. Live-Ausgabe und ein sinnvoller Diagnoseablauf
  7. Einen Ausschnitt verantwortungsvoll teilen
  8. Quellen

Ein Dienst startet nicht, der Ton setzt aus oder nach dem Boot fehlt eine Funktion. Oft gibt es dazu bereits eine Meldung im Systemjournal. Mit journalctl suchst du gezielt nach dem relevanten Zeitraum und Dienst, statt eine riesige Ausgabe nach roten Zeilen zu durchsuchen.

Das Tutorial setzt Linux mit systemd und systemd-journald voraus. Cthulhus NixOS-Konfiguration ist ein solcher Bezug; ein anderes Init-System kann andere Log-Werkzeuge verwenden. Alle gezeigten Diagnoseabfragen sind lesend. Nur die ausdrücklich gekennzeichnete Übungsmeldung fügt einen harmlosen eigenen Journaleintrag hinzu.

Was steht im Journal?

Das Journal sammelt strukturierte Meldungen unter anderem von Diensten und Kernel. Neben dem Nachrichtentext gehören Zeit, Quelle und Priorität dazu. Ein Systemdienst wie NetworkManager und ein Benutzerdienst wie PipeWire leben dabei in unterschiedlichen Zusammenhängen.

Logs sind Beobachtungen, keine fertige Diagnose. Eine Warnung kann erwartbares Verhalten beschreiben; die tatsächliche Ursache kann einige Zeilen vor dem sichtbaren Ausfall liegen. Beginne daher mit einer konkreten Frage: Was funktionierte nicht, wann trat es auf und welcher Dienst war beteiligt?

Für einen ersten kleinen Ausschnitt:

journalctl --boot --lines=30 --no-pager

--boot begrenzt auf den aktuellen Start, --lines auf die letzten Einträge und --no-pager auf direkte Terminalausgabe. Ohne diese letzte Option öffnet sich häufig ein Pager, den du mit q verlässt.

Den richtigen Boot auswählen

Bei einem Problem nach dem Neustart brauchst du möglicherweise den vorherigen Boot. Zeige die vorhandenen Starts:

journalctl --list-boots

Nur wenn der vorherige Start dort vorhanden ist, kannst du ihn sinnvoll abfragen:

journalctl --boot=-1 --lines=50 --no-pager

0 ist der aktuelle, -1 der vorherige aufgezeichnete Boot. Ältere Starts fehlen, wenn Aufbewahrung, Speicherart oder Berechtigungen ihre Verfügbarkeit begrenzen. Eine leere Liste älterer Boots bedeutet nicht automatisch, dass dort keine Probleme auftraten.

Zugriff auf vollständige Systemlogs hängt von deiner Distribution und den Gruppenrechten ab. Beginne ohne sudo; falls genau diese Abfrage berechtigt mehr Zugriff braucht, kannst du sie gezielt mit sudo wiederholen. Ein Benutzerservice wird dadurch nicht zu einem Systemservice.

Einen Dienst statt das gesamte System lesen

Für ein Netzwerkproblem unter dem in meiner NixOS-Datei aktivierten NetworkManager:

journalctl --boot --unit=NetworkManager.service --lines=60 --no-pager

Der Unit-Name muss tatsächlich auf deinem Rechner gelten. Ein anderes Netzwerkwerkzeug produziert andere Dienstmeldungen. Prüfe den zugehörigen Status separat:

systemctl status NetworkManager.service

Für einen PipeWire-Benutzerdienst ist der Bezug anders:

journalctl --user --boot --unit=pipewire.service --lines=40 --no-pager

Diese Abfrage setzt verfügbare Benutzerjournale voraus. Findest du nichts, prüfe die Service-Verwaltung und Journalaufbewahrung. Ein von Hand gestartetes Programm kann seine Meldungen nur ins ursprüngliche Terminal schreiben; nicht jedes Problem landet automatisch in der erwarteten Unit.

Zeitraum und Priorität kombinieren

Ein enger Zeitraum macht die Ausgabe nachvollziehbarer. Für die letzten zehn Minuten des aktuellen Boots:

journalctl --boot --since="10 minutes ago" --no-pager

Für Warnungen und schwerwiegendere Meldungen:

journalctl --boot --priority=warning --lines=50 --no-pager

warning als einzelne Prioritätsgrenze umfasst auch höhere Dringlichkeit, etwa Fehler. Die Filter kombinieren sich. Eine zu enge Auswahl kann deshalb gerade die erklärende Informationsmeldung ausblenden. Lies nach dem ersten Treffer auch den betroffenen Dienst im selben Zeitraum ohne Prioritätsfilter.

Notiere bei Problemen den ungefähren Beginn und die Zeitzone. Absolute Zeitangaben sind für wiederholbare Vergleiche besser als eine Stunde später erneut „vor zehn Minuten“ abzufragen. Die lokalen Zeitdarstellungen sollten zu deiner Beobachtung passen.

Eine eigene Meldung wiederfinden

Die folgende Übung schreibt einen einzelnen eigenen Log-Eintrag. Sie verändert keinen Dienst und ist kein echter Fehlerbericht:

systemd-cat --identifier=BlogTutorial echo "Lokale Journal-Uebung"

Suche anschließend nur nach diesem Bezeichner:

journalctl --identifier=BlogTutorial --since="5 minutes ago" --no-pager

Du solltest deine Meldung mit Zeit und Quelle wiederfinden, sofern die Journalrechte das erlauben. Der Text ist bewusst frei von persönlichen Daten. Ändere als zweite Übung den Bezeichner in beiden Befehlen und vergleiche die Auswahl.

Diese Methode hilft, die Filter zu verstehen, ohne einen Dienst absichtlich kaputtzumachen. Es ist auch nicht nötig, die Journaldateien zu löschen oder ihre Aufbewahrung für die Übung zu ändern.

Live-Ausgabe und ein sinnvoller Diagnoseablauf

Zum Beobachten eines Vorgangs kannst du einen Dienst verfolgen:

journalctl --boot --unit=NetworkManager.service --follow

Beende die Beobachtung mit Strg + C. Das stoppt nur den Leser, nicht NetworkManager. Starte keine Netzwerk-Neustarts allein als Übung, wenn deine Verbindung davon abhängt.

Ein brauchbarer Ablauf besteht aus: Verhalten beschreiben, Zeitpunkt festhalten, Dienst auswählen, Umfeld lesen, eine begründete Änderung testen und denselben Ausschnitt erneut vergleichen. Bei Tonproblemen passt dazu mein SPDIF-Artikel; bei NixOS-Systemänderungen der Rollback-Guide.

Einen Ausschnitt verantwortungsvoll teilen

Behalten Vor Veröffentlichung prüfen
Relevante Fehlerzeile und ihr Umfeld Namen, Hostnamen und private Dateipfade
Dienstname und Programmversion IP-Adressen und Netzwerkbezeichnungen
Zeitpunkt und getestete Änderung Tokens, URLs mit Zugangsdaten und Nachrichteninhalte

Kopiere einen gezielten Ausschnitt und schwärze sensible Werte. Ein vollständig hochgeladenes Journal ist selten die erste nötige Information. Die originale Datei sollte für deine eigene Untersuchung erhalten bleiben; eine gekürzte Veröffentlichung kann sonst später eine wichtige Zeile vermissen lassen.

Quellen

Geprüfter Quellenstand: 8. Oktober 2026. Die Befehle sind Übungen; hier werden keine erfundenen Cthulhu-Fehlerlogs als reale Messung ausgegeben.