Thomas.will: Neue Seite: Baustein Fehlersuche und Analyse

2026-10-17T15:47:32Z

Neue Seite: Baustein Fehlersuche und Analyse

Neue Seite

[[Kategorie:systemd]]
{| class="wikitable"
! Baustein !! ab Stufe !! Lernpfad
|-
| '''Fehlersuche und Analyse''' || [[Systemd Stufe 1 Basic|Stufe 1]] bis [[Systemd Stufe 3 Security|Stufe 3]] || [[Systemd Lernpfad|Übersicht]]
|}

=Einfach erklärt=
*Fast jeder Fehler mit systemd lässt sich mit drei Befehlen eingrenzen: '''systemctl status''', '''journalctl''' und '''systemd-analyze'''.
*Startet das ganze System nicht mehr, gibt es Notfallwege: Rettungsmodus, Notfallmodus, eine Debug-Shell.
*Stürzt ein Programm ab, kann systemd den Speicherabzug (Coredump) aufheben, damit man später nachsehen kann, warum.

=Ein Dienst startet nicht=
*Immer in dieser Reihenfolge:
<pre>
systemctl status dienst
journalctl -u dienst -e
journalctl -xeu dienst
</pre>
*'''-x''' ergänzt Erklärungen zu bekannten Meldungen.
{| class="wikitable"
! Meldung in status !! Bedeutung !! Abhilfe
|-
| status=203/EXEC || Programm nicht gefunden oder nicht ausführbar || Pfad in ExecStart= prüfen, chmod +x
|-
| status=200/CHDIR || WorkingDirectory= gibt es nicht oder kein Zugriff || Verzeichnis und Rechte prüfen
|-
| status=217/USER || User= gibt es nicht || Benutzer anlegen oder DynamicUser=yes
|-
| code=killed, signal=SYS || ein verbotener Systemaufruf || SystemCallFilter= lockern, siehe [[Systemd Stufe 3 Security|Stufe 3]]
|-
| Start request repeated too quickly || zu oft neu gestartet || Ursache beheben, dann systemctl reset-failed dienst
|-
| changed on disk || Unit geändert, aber nicht neu geladen || systemctl daemon-reload
|}
*Alles, was gescheitert ist: '''systemctl --failed'''

=Unit-Dateien prüfen=
*systemd-analyze verify /etc/systemd/system/dienst.service
*Findet Tippfehler, unbekannte Optionen und fehlende Programme, bevor man startet.
*systemctl cat dienst zeigt, was systemd wirklich liest, mit allen Drop-ins.

=Der Start ist langsam=
{| class="wikitable"
! Befehl !! Wirkung
|-
| systemd-analyze || Zeit für Firmware, Bootloader, Kernel und Userspace
|-
| systemd-analyze blame || alle Units nach Startdauer sortiert
|-
| systemd-analyze critical-chain || die Kette, die den Start wirklich aufhält
|-
| systemd-analyze plot > start.svg || Zeitstrahl als Bild für den Browser
|}
*'''blame''' allein täuscht: Ein Dienst, der lange braucht, aber parallel läuft, bremst niemanden. Entscheidend ist '''critical-chain'''.
*Mehr dazu als Animation: [https://labs.xinux.net/systemd-start.html#4-1 Der Zeitstrahl]

=Das System startet nicht mehr=
{| class="wikitable"
! Bootparameter im GRUB-Editor !! Wirkung
|-
| systemd.unit=rescue.target || Rettungsmodus: Dateisysteme eingehängt, keine Dienste
|-
| systemd.unit=emergency.target || Notfallmodus: nur / nur lesbar
|-
| systemd.debug_shell || zusätzlich eine root-Shell auf tty9 (Strg+Alt+F9), ohne Passwort
|-
| systemd.log_level=debug || systemd meldet jeden Schritt ins Journal
|-
| init=/bin/bash || ganz ohne systemd, siehe [https://labs.xinux.net/kernel-initialisierung.html#10-1 Kernel-Initialisierung]
|}
*Die Debug-Shell nach der Fehlersuche wieder abschalten. Sie ist eine offene root-Shell.
*Nach dem Start mit Problemen: '''journalctl -b -1 -p err''' zeigt die Fehler vom letzten, gescheiterten Start.

=Abstürze: coredumpctl=
*Debian bringt es nicht von Haus aus mit: '''apt install systemd-coredump'''
{| class="wikitable"
! Befehl !! Wirkung
|-
| coredumpctl list || alle gespeicherten Abstürze
|-
| coredumpctl info PID || Programm, Signal, Zeitpunkt, Stack
|-
| coredumpctl debug PID || den Absturz direkt im Debugger gdb öffnen
|}
*Die Abzüge liegen unter /var/lib/systemd/coredump/.
*Für die Sicherheit: Ein Coredump enthält den Speicher des Programms, also eventuell Passwörter und Schlüssel. Zugriff nur für root.

=Stolperfallen=
*'''Nur status gelesen:''' status zeigt nur die letzten Zeilen. Der eigentliche Fehler steht oft weiter oben in journalctl -u.
*'''reset-failed vergessen:''' Nach Start request repeated too quickly startet systemd den Dienst nicht mehr, bis man reset-failed macht.
*'''Debug-Shell vergessen:''' systemd.debug_shell nur für die Fehlersuche, danach entfernen.

=Aufgaben=
==Grundaufgaben==
#Bauen Sie absichtlich drei kaputte Units: falscher Pfad, falscher Benutzer, falsches Verzeichnis. Welche Meldungen bekommen Sie?
#Prüfen Sie die drei Units mit systemd-analyze verify.
#Welcher Dienst bremst den Start Ihres Systems?
#Booten Sie einmal in den Rettungsmodus und wieder normal.
==Für Schnelle==
#Lassen Sie einen Dienst mit Restart=always sofort scheitern, bis systemd aufgibt. Starten Sie ihn danach wieder.
#Installieren Sie systemd-coredump, lassen Sie ein Programm mit kill -SEGV abstürzen und sehen Sie es mit coredumpctl an.
#Starten Sie mit systemd.debug_shell und finden Sie die Shell auf tty9.

=Weiter=
*[[Systemd Lernpfad|Übersicht: Lernpfad systemd]]
*Alte Seite: [[Systemd-analyze-beschreibung]]

Systemd Baustein Fehlersuche - Versionsgeschichte

Thomas.will: Neue Seite: Baustein Fehlersuche und Analyse