SYSTEMD-ANALYZE(1)

BEZEICHNUNG
systemd-analyze - System-Manager analysieren und auf Fehler überprüfen

ÜBERSICHT

systemd-analyze [OPTIONEN…] [Zeit]

systemd-analyze [OPTIONEN…] blame

systemd-analyze [OPTIONEN…] critical-chain [UNIT…]

systemd-analyze [OPTIONEN…] plot [> Datei.svg]

systemd-analyze [OPTIONEN…] dot [PATTERN…] [> Datei.dot]

systemd-analyze [OPTIONEN…] dump

systemd-analyze [OPTIONEN…] cat-config NAME|PFAD…

systemd-analyze [OPTIONEN…] unit-paths

systemd-analyze [OPTIONEN…] log-level [STUFE]

systemd-analyze [OPTIONEN…] log-target [ZIEL]

systemd-analyze [OPTIONEN…] syscall-filter [GRUPPE…]

systemd-analyze [OPTIONEN…] verify [DATEIEN…]

systemd-analyze [OPTIONEN…] calendar SPEZ…

systemd-analyze [OPTIONEN…] service-watchdogs [LOGISCH]

BESCHREIBUNG

systemd-analyze kann zur Bestimmung der Systemstartleistungsstatistik benutzt werden. Es kann Status- und Nachverfolgungsinformationen aus dem System- und Diensteverwalter abrufen und die Korrektheit von Unit-Dateien überprüfen. Es wird auch dazu verwandt, auf besondere Funktionen zuzugreifen, die für fortgeschrittene Systemverwalterfehlersuche nützlich sind.

systemd-analyze time gibt die im Kernel verbrachte Zeit, bevor der Anwendungsbereich erreicht wurde, die Zeit, die in der anfänglichen RAM-Platte (Initrd), bevor der normale System-Benutzerbereich erreicht wurde und die Zeit, die der normale Systembenutzerbereich zur Initialisierung benötigte, aus. Beachten Sie, dass diese Messungen einfach die Zeit zu dem Punkt messen, an dem alle Systemdienste gestartet wurden, aber nicht notwendigerweise bis sie ihre Initialisierung abgeschlossen hatten oder die Platte im Leerlauf war.

systemd-analyze blame gibt eine Liste aller laufenden Units, sortiert nach der Initialisierungszeitdauer, aus. Diese Informationen können zur Optimierung der Systemstartzeit verwandt werden. Beachten Sie, dass die Ausgabe irreführend sein kann, da die Initialisierung eines Dienstes einfach deshalb langsam sein kann, da sie auf den Abschluss der Initialisierung eines anderen Dienstes wartet. Beachten Sie auch: systemd-analyze blame zeigt keine Ergebnisse für Dienste mit Type=simple an, da Systemd solche Dienste als sofort gestartet betrachtet und daher keine Messungen der Initialisierungsverzögerungen erfolgen können.

systemd-analyze critical-chain [UNIT…] gibt einen Baum der zeitkritischen Unit-Kette (für jede der festgelegten UNITs oder andernfalls für das Standardziel) aus. Die Zeit nach der die Unit aktiv oder gestartet ist wird nach dem Zeichen »@« ausgegeben. Die Zeit, die die Unit zum Starten benötigt wird nach dem Zeichen »+« ausgegeben. Beachten Sie, dass die Ausgabe irreführend sein kann, da die Initialisierung eines Dienstes abhängig von der Aktivierung eines Sockets sein kann und da die Units parallel ausgeführt werden.

systemd-analyze plot gibt eine SVG-Graphik aus, die detailliert, welche Systemdienste zu welcher Zeit gestartet wurden und hervorhebt, welche Zeit sie zur Initialisierung verbraucht haben.

systemd-analyze dot erstellt eine textuale Abhägigkeitsgraphbeschreibung im Dot-Format zur weiteren Verarbeitung mit dem GraphViz-Werkzeug dot(1). Verwenden Sie eine Befehlszeile der Art systemd-analyze dot | dot -Tsvg > systemd.svg, um einen graphischen Abhängigkeitsbaum zu erstellen. Falls weder --order noch --require angegeben sind, wird der erstellte Graph sowohl Ordnungs- als auch Anforderungsabhängigkeiten darstellen. Optional können am Ende Muster-Festlegungen im Glob-Stil (z.B. *.target) angegeben werden. Eine Unit-Abhängigkeit ist im Graph enthalten, falls eines dieser Muster entweder auf den Quell- oder den Zielknoten passt.

systemd-analyze dump gibt eine (normalerweise sehr lange) menschenlesbare Serialisierung des kompletten Serverzustandes aus. Sein Format unterliegt ohne Ankündigungen Änderungen und sollte nicht durch Anwendungen ausgewertet werden.

systemd-analyze cat-config ist ähnlich zu systemctl cat, agiert aber auf Konfigurationsdateien. Es kopiert den Inhalt einer Konfigurationsdatei und aller Reinlege-Dateien in die Standardausgabe; dabei berücksichtigt es die normalen Gruppe an Systemd-Verzeichnissen und Regeln bezüglich des Vorrangs. Jedes Argument muss entweder ein absoluter Pfad einschließlich des Präfixes (wie /etc/systemd/logind.conf oder /usr/lib/systemd/logind.conf) oder ein Name relative zu dem Präfix (wie systemd/logind.conf) sein.

Beispiel 1. Anzeige der Logind-Konfiguration

    $ systemd-analyze cat-config systemd/logind.conf
    # /etc/systemd/logind.conf
    ...
    [Login]
    NAutoVTs=8
    ...
    # /usr/lib/systemd/logind.conf.d/20-test.conf
    … und einiges aus einem anderen Paket, das außer Kraft setzt
    # /etc/systemd/logind.conf.d/50-override.conf
    … und was vom Administrator, das außer Kraft setzt

systemd-analyze unit-paths gibt eine Liste aller Verzeichnisse, aus denen Unit-Dateien, .d overrides- und .wants-, .requires-Symlinks geladen werden können. Kombinieren Sie dies mit --user, um die Liste für die Benutzerverwalterinstanz abzufragen und --global für die globale Konfiguration der Benutzerverwalterinstanzen. Beachten Sie, dass dieses Verb die Liste ausgibt, die in systemd-analyze selbst einkompiliert wurde und keine Kommunikation mit dem laufenen Verwalter stattfindet. Verwenden Sie

    systemctl [--user] [--global] show -p Unit-Pfad --value

um die tatsächliche Liste, die der Verwalter benutzt, abzufragen, wobei alle leeren Verzeichnisse ausgelassen werden.

systemd-analyze log-level gibt die aktuellen Protokollierstufe des systemd-Daemons aus. Falls ein optionales Argument STUFE bereitgestellt wird, dann wird die aktuelle Protokollierstufe des systemd-Daemons auf STUFE geändert (akzeptiert die gleichen Werte wie das in systemd(1) beschriebene --log-level=).

systemd-analyze log-target gibt das aktuelle Protokollierziel des Daemons systemd aus. Falls das optionale Argument ZIEL bereitgestellt wird, dann ändert der Befehl das aktuelle Protokollierziel des Daemons systemd auf ZIEL (akzeptiert die gleichen Werte wie das in systemd(1) beschriebene --log-target=).

systemd-analyze syscall-filter [GRUPPE…] wird die in der festgelegten GRUPPE enthaltenen Systemaufrufe filtern oder alle bekannten Gruppen erlauben, falls keine Gruppen festgelegt sind. Das Argument GRUPPE muss das Präfix »@« enthalten.

systemd-analyze verify wird Unit-Dateien laden und Warnungen ausgeben, falls irgendwelche Fehler erkannt werden. Auf der Befehlszeile festgelegte Dateien werden geladen, aber auch alle von diesen referenzierte Dateien. Der komplette Unit-Suchpfad wird durch Kombination der Verzeichnisse für alle Befehlzeilenargumente zusammengestellt und die normalen Unit-Ladepfade (Variable $SYSTEMD_UNIT_PATH) wird unterstützt und kann zum Ersetzen oder Erweitern der einkompilierten Gruppe von Unit-Ladepfaden verwandt werden; siehe systemd.unit(5)). Alle Unit-Dateien, die in den in der Befehlszeile enthaltenen Verzeichnissen vorhanden sind, werden gegenüber den in anderen Pfaden vorgezogen.

systemd-analyze calendar wird wiederholende Kalenderzeitereignisse auswerten und normieren und berechnen, wann sie das nächste Mal ablaufen. Dies akzeptiert die gleiche Eingabe wie die Einstellung OnCalendar= in systemd.timer(5) und folgt der in systemd.time(7) beschriebenen Syntax.

systemd-analyze service-watchdogs gibt den aktuelle Zustand des Dienste-Laufzeit-Watchdogs des Daemons systemd aus. Falls ein optionales logisches Argument bereitgestellt wird, dann werden die Dienste-Laufzeit-Watchdogs (WatchdogSec=) und Notfallaktionen (z.B. OnFailure= oder StartLimitAction=) global aktiviert oder deaktiviert; siehe systemd.service(5). Der Hardware-Watchdog ist von dieser Einstellung nicht betroffen.

Falls kein Befehl übergeben wird, wird systemd-analyze time impliziert.

OPTIONEN

Die folgenden Optionen werden verstanden:

--system
    Agiert auf der System-Systemd-Instanz. Dies ist die implizierte Vorgabe.

--user
    Agiert auf der Benutzer-Systemd-Instanz.

--global
    Agiert auf der systemweiten Konfiguration für Benutzer-Systemd-Instanzen.

--order, --require
    Wählt bei der Verwendung mit dem Befehl dot (siehe oben) die im Abhängigkeitsgraph zu zeigenden Abhängigkeiten aus. Falls --order übergeben wird, werden nur Abhängigkeiten vom Typ After= oder Before= gezeigt. Falls --require übergeben wird, werden nur Abhängigkeiten vom Typ Requires=, Requisite=, Wants= und Conflicts= gezeigt. Falls keines davon übergeben wird, werden die Abhängigkeiten aller dieser Typen gezeigt.

--from-pattern=, --to-pattern=
    Wählt bei der Verwendung mit dem Befehl dot (siehe oben) aus, welche Beziehungen im Abhängigkeitsgraph gezeigt werden. Beide Optionen benötigen ein glob(7)-Muster als Argument, das mit den Knoten auf der rechten bzw. linken Seite einer Beziehung übereinstimmen muss.

    Jeder davon kann mehr als einmal verwandt werden, dann müssen die Unit-Namen auf jeden der Werte passen. Falls Test für beide Seiten der Relation vorhanden sind, muss eine Relation beide Tests bestehen, um angezeigt zu werden. Wenn Muster zudem als positionsabhängige Argumente festgelegt werden, müssen sie auf mindestens einer Seite der Relation passen. Mit anderen Worten, Muster, die mit diesen zwei Optionen festgelegt werden, verkürzen die Liste der Kanten, auf die die positionsabhängigen Argumente passen, falls welche angegeben werden, und zeigen die komplette Liste der Kanten andernfalls.

--fuzz=Zeitspanne
    Zeigt bei der Verwendung mit dem Befehl critical-chain (siehe oben) auch Units, die sich eine Zeitspanne früher beendeten, als die letzte Unit auf der gleichen Stufe. Die Einheit von Zeitspanne ist Sekunden, außer es wird eine andere Einheit festgelegt, z.B. »50ms«.

--man=no
    Ruft man nicht auf, um die Existenz von in Documentation= aufgeführten Handbuchseiten zu überprüfen.

--generators
    Ruft Unit-Generatoren auf, siehe systemd.generator(7). Einige Generatoren benötigen Root-Rechte. Beim Betrieb mit aktivierten Generatoren kommt es als normaler Benutzer im Allgemeinen zu einigen Warnmeldungen.

--root=PFAD
    Zeigt mit cat-files Konfigurationsdateien unterhalb des festgelegten Wurzelpfades PFAD an.

-H, --host=
    Führt die Aktion aus der Ferne aus. Geben Sie den Rechnernamen oder einen Benutzernamen und Rechnernamen (getrennt durch »@«) an, zu dem verbunden werden soll. Dem Rechnernamen darf optional ein Container-Name angehängt werden, getrennt durch »:«, womit direkt zu einem bestimmten Container auf dem angegebenen Rechner verbunden wird. Dies verwendet SSH, um mit der Maschinen-Manager-Instanz auf dem Rechner in der Ferne zu sprechen. Container-Namen dürfen mit machinectl -H RECHNER aufgezählt werden.

-M, --machine=
    Führt die Aktion auf einem lokalen Container aus. Geben Sie den Namen des Containers an, zu dem verbunden werden soll.

-h, --help
    zeigt einen kurzen Hilfetext an und beendet das Programm.

--version
    zeigt eine kurze Versionszeichenkette an und beendet das Programm.

--no-pager
    Die Ausgabe nicht an einen Pager weiterleiten.

RÜCKGABEWERT

Bei Erfolg wird 0 zurückgegeben, anderenfalls ein Fehlercode ungleich Null.

BEISPIELE FÜR DOT

Beispiel 2. Zeichnet alle Abhängigeiten von jeder Unit, deren Name mit »avahi-daemon« beginnt

    $ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > avahi.svg
    $ eog avahi.svg

Beispiel 3. Zeichnet alle Abhängigkeiten zwischen allen bekannten Ziel-Units

    $ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' | dot -Tsvg > Ziele.svg
    $ eog Ziele.svg

BEISPIELE FÜR VERIFY

Derzeit werden die folgenden Fehler erkannt:

    • unbekannte Abschnitte und Direktiven,

    • fehlende Abhängigkeiten, die zum Starten der übergegebenen Unit notwendig sind,

    • in Documentation= aufgeführte Handbuchseiten, die im System nicht gefunden werden,

    • in ExecStart= und ähnlichen aufgeführte Befehle, die nicht im System gefunden oder nicht ausführbar sind.

Beispiel 4. Falschgeschriebene Direktiven

    $ cat ./user.slice
    [Unit]
    WhatIsThis=11
    Documentation=man:nosuchfile(1)
    Requires=different.service
    [Service]
    Description=x
    $ systemd-analyze verify ./user.slice
    [./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'
    [./user.slice:13] Unknown section 'Service'. Ignoring.
    Error: org.freedesktop.systemd1.LoadFailed:
       Unit different.service failed to load:
       No such file or directory.
    Failed to create user.slice/start: Invalid argument
    user.slice: man nosuchfile(1) command failed with code 16

Beispiel 5. Fehlende Dienste-Units

    $ tail ./a.socket ./b.socket
    ==> ./a.socket <==
    [Socket]
    ListenStream=100
    ==> ./b.socket <==
    [Socket]
    ListenStream=100
    Accept=yes
    $ systemd-analyze verify ./a.socket ./b.socket
    Service a.service not loaded, a.socket cannot be started.
    Service b@0.service not loaded, b.socket cannot be started.

UMGEBUNGSVARIABLEN

$SYSTEMD_PAGER
    Zu verwendender Pager, wenn --no-pager nicht angegeben ist, setzt $PAGER außer Kraft. Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe gut-bekannter Pagerimplementierungen der Reihe nach ausprobiert, einschließlich less(1) und more(1), bis einer gefunden wird. Falls keine Pager-Implementierung gefunden wird, wird keiner aufgerufen. Setzten der Umgebungsvariablen auf die leere Zeichenkette oder den Wert »cat« is äquivalent zur Übergabe von --no-pager.

$SYSTEMD_LESS
    Setzt die an less weitergegebenen Optionen (standardmäßig »FRSXMK«) außer Kraft.

$SYSTEMD_LESSCHARSET
    Setzt den an less weitergegebenen Zeichensatz (standardmäßig »utf-8«, falls das aufrufende Terminal als UTF-8-kompatibel erkannt wurde) außer Kraft.

SIEHE AUCH

systemd(1), systemctl(1)

ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an <debian-l10n-german@lists.debian.org>.