In diesem Artikel
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
- journalctl-Handbuch aus Debian.
- systemd-cat: gezielte Übungsmeldung.
- systemd-journald: Speicherung und Zugriff.
- Cthulhus geprüfte NixOS-Datei: NetworkManager und PipeWire als Projektbezug.
Geprüfter Quellenstand: 8. Oktober 2026. Die Befehle sind Übungen; hier werden keine erfundenen Cthulhu-Fehlerlogs als reale Messung ausgegeben.