Provided by: manpages-de_2.16-1_all 
BEZEICHNUNG
systemd-analyze - Systemverwalter analysieren und auf Fehler überprüfen
ÜBERSICHT
systemd-analyze [OPTIONEN…] [Zeit]
systemd-analyze [OPTIONEN…] blame
systemd-analyze [OPTIONEN…] critical-chain [UNIT…]
systemd-analyze [OPTIONEN…] log-level [STUFE]
systemd-analyze [OPTIONEN…] log-target [ZIEL]
systemd-analyze [OPTIONEN…] service-watchdogs [LOGISCH]
systemd-analyze [OPTIONEN…] dump
systemd-analyze [OPTIONEN…] plot [>Datei.svg]
systemd-analyze [OPTIONEN…] dot [MUSTER…] [>Datei.dot]
systemd-analyze [OPTIONEN…] unit-paths
systemd-analyze [OPTIONEN…] exit-status [STATUS…]
systemd-analyze [OPTIONEN…] condition BEDINGUNG…
systemd-analyze [OPTIONEN…] syscall-filter [GRUPPE…]
systemd-analyze [OPTIONEN…] calendar SPEZ…
systemd-analyze [OPTIONEN…] timestamp ZEITSTEMPEL…
systemd-analyze [OPTIONEN…] timespan SPANNE…
systemd-analyze [OPTIONEN…] cat-config NAME|PFAD…
systemd-analyze [OPTIONEN…] verify [DATEI…]
systemd-analyze [OPTIONEN…] security UNIT…
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.
Falls kein Befehl übergeben wird, wird systemd-analyze time impliziert.
systemd-analyze time
Dieser Befehl gibt die im Kernel verbrachte Zeit, bevor der Anwendungsbereich erreicht wurde, die Zeit,
die in der anfänglichen RAM-Platte (Initrd), bevor die normale Systemanwendungsebene erreicht wurde und
die Zeit, die die normale Systemanwendungsebene 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.
Beispiel 1. Anzeigen, wie lange ein Systemstart brauchte
# in einem Container
$ systemd-analyze time
Startup finished in 296ms (userspace)
multi-user.target reached after 275ms in userspace
# in einer echten Maschine
$ systemd-analyze time
Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s
multi-user.target reached after 47.820s in userspace
systemd-analyze blame
Dieser Befehl 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. Beachten Sie auch, dass dieser Befehl nur die Zeit anzeigt, die die Units für das Hochfahren
benötigten, er zeigt nicht an, wie lange sich die Units in der Ausführungswarteschlange befanden.
Insbesondere zeigt er die Zeit, die die Units im Zustand »activating« verbrachten; dieser Zustand ist für
Units wie Geräte-Units nicht definiert, die direkt von »inactive« nach »active« übergehen. Dieser Befehl
gibt daher den Eindruck der Leistung von Programmcode, kann aber nicht die durch das Warten auf Hardware
und ähnliche Ereignisse verursachte Latenz genau wiedergeben.
Beispiel 2. Zeigt, welche Units beim Systemstart die meiste Zeit verbrauchten
$ systemd-analyze blame
32.875s pmlogger.service
20.905s systemd-networkd-wait-online.service
13.299s dev-vda1.device
...
23ms sysroot.mount
11ms initrd-udevadm-cleanup-db.service
3ms sys-kernel-config.mount
systemd-analyze critical-chain [UNIT…]
Dieser Befehl 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 von Diensten
abhängig von der Aktivierung eines Sockets sein kann und da die Units parallel ausgeführt werden. Dies
berücksichtigt auch ähnlich zu dem Befehl blame nur die Zeit, die die Unit im Zustand »activating«
verbringt und deckt daher Units nicht ab, die niemals durch den Zustand »inactive« laufen (wie
beispielsweise Geräte-Units, die direkt von »inactive« zu »active« übergehen). Desweiteren zeigt es keine
Informationen über Aufträge an (und insbesondere über Aufträge, die eine Zeitüberschreitung erlebten).
Beispiel 3. systemd-analyze time
$ systemd-analyze critical-chain
multi-user.target @47.820s
ââpmie.service @35.968s +548ms
ââpmcd.service @33.715s +2.247s
âânetwork-online.target @33.712s
ââsystemd-networkd-wait-online.service @12.804s +20.905s
ââsystemd-networkd.service @11.109s +1.690s
ââsystemd-udevd.service @9.201s +1.904s
ââsystemd-tmpfiles-setup-dev.service @7.306s +1.776s
ââkmod-static-nodes.service @6.976s +177ms
ââsystemd-journald.socket
ââsystem.slice
ââ-.slice
systemd-analyze log-level [STUFE]
systemd-analyze log-level gibt die aktuelle 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 [ZIEL]
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 service-watchdogs [yes|no]
systemd-analyze service-watchdogs gibt den aktuellen 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.
systemd-analyze dump
Dieser Befehl 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.
Beispiel 4. Den internen Zustand des Benutzerverwalters anzeigen
$ systemd-analyze --user dump
Timestamp userspace: Thu 2019-03-14 23:28:07 CET
Timestamp finish: Thu 2019-03-14 23:28:07 CET
Timestamp generators-start: Thu 2019-03-14 23:28:07 CET
Timestamp generators-finish: Thu 2019-03-14 23:28:07 CET
Timestamp units-load-start: Thu 2019-03-14 23:28:07 CET
Timestamp units-load-finish: Thu 2019-03-14 23:28:07 CET
-> Unit proc-timer_list.mount:
Description: /proc/timer_list
...
-> Unit default.target:
Description: Main user target
…
systemd-analyze plot
Dieser Befehl gibt eine SVG-Graphik aus, die detailliert, welche Systemdienste zu welcher Zeit gestartet
wurden und hervorhebt, welche Zeit sie zur Initialisierung verbraucht haben.
Beispiel 5. Eine Systemstartübersicht darstellen
$ systemd-analyze plot >bootup.svg
$ eog bootup.svg&
systemd-analyze dot [Muster…]
Dieser Befehl erstellt eine textuelle Abhängigkeitsgraphbeschreibung 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.
Beispiel 6. Zeichnet alle Abhängigkeiten von jeder Unit, deren Name mit »avahi-daemon« beginnt
$ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg
$ eog avahi.svg
Beispiel 7. 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
systemd-analyze unit-paths
Dieser Befehl gibt eine Liste aller Verzeichnisse aus, 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.
Beispiel 8. Alle Pfade für erstellte Units anzeigen
$ systemd-analyze unit-paths | grep '^/run'
/run/systemd/system.control
/run/systemd/transient
/run/systemd/generator.early
/run/systemd/system
/run/systemd/system.attached
/run/systemd/generator
/run/systemd/generator.late
Beachten Sie, dass dieses Verb die Liste ausgibt, die in systemd-analyze selbst einkompiliert wurde und
keine Kommunikation mit dem laufenden 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 exit-status [STATUS…]
Dieser Befehl gibt eine Liste von Exit-Status zusammen mit ihrer »Klasse« aus, d.h. der Quelle der
Definition (entweder »glibc«, »systemd«, »LSB« oder »BSD«), siehe den Abschnitt PROZESS-EXIT-CODES in
systemd.exec(5). Falls keine zusätzlichen Argumente festgelegt sind, werden alle bekannten Status
angezeigt. Andernfalls werden nur die Definitionen für die festgelegten Codes angezeigt.
Beispiel 4. Ein paar Beispiel-Exit-Staus anzeigen
$ systemd-analyze exit-status 0 1 {63..65}
NAME STATUS CLASS
SUCCESS 0 glibc
FAILURE 1 glibc
- 63 -
USAGE 64 BSD
DATAERR 65 BSD
systemd-analyze condition BEDINGUNG…
Dieser Befehl wertet die Zuweisungen Condition*=… und Assert*=… aus und gibt ihre Werte und den daraus
ergebenen Wert des kombinierten Bedingungssatzes aus. Siehe systemd.unit(5) für eine Liste der
verfügbaren Bedingungen und Zusicherungen.
Beispiel 10. Bedingungen auswerten, die Kernelversionen prüfen
$ systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \
'ConditionKernelVersion = >=5.1' \
'ConditionACPower=|false' \
'ConditionArchitecture=|!arm' \
'AssertPathExists=/etc/os-release'
test.service: AssertPathExists=/etc/os-release succeeded.
Asserts succeeded.
test.service: ConditionArchitecture=|!arm succeeded.
test.service: ConditionACPower=|false failed.
test.service: ConditionKernelVersion=>=5.1 succeeded.
test.service: ConditionKernelVersion=!<4.0 succeeded.
Conditions succeeded.
systemd-analyze syscall-filter [GRUPPE…]
Dieser Befehl 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 calendar AUSDRUCK…
Dieser Befehl 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. Standardmäßig wird nur der
nächste Zeitpunkt angezeigt, zu dem der Kalenderausdruck abläuft; verwenden Sie --iterations=, um die
festgelegte Anzahl der nächsten Male anzuzeigen, zu denen der Ausdruck abläuft. Jedes Mal, wenn der
Ausdruck abläuft, wird ein Zeitstempel gebildet, siehe das Verb timestamp weiter unten.
Beispiel 11. Schalttage in der näheren Zukunft anzeigen
$ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0'
Original form: *-2-29 0:0:0
Normalized form: *-02-29 00:00:00
Next elapse: Sat 2020-02-29 00:00:00 UTC
From now: 11 months 15 days left
Iter. #2: Thu 2024-02-29 00:00:00 UTC
From now: 4 years 11 months left
Iter. #3: Tue 2028-02-29 00:00:00 UTC
From now: 8 years 11 months left
Iter. #4: Sun 2032-02-29 00:00:00 UTC
From now: 12 years 11 months left
Iter. #5: Fri 2036-02-29 00:00:00 UTC
From now: 16 years 11 months left
systemd-analyze timestamp ZEITSTEMPEL…
Dieser Befehl wertet den Zeitstempel (d.h. einen einzelnen Zeitpunkt) aus und gibt die normalisierte Form
und den Unterschied zwischen diesem Zeitstempel und jetzt aus. Der Zeitstempel sollte daher der Syntax
wie in systemd.time(7), Abschnitt »ZEITSTEMPEL AUSWERTEN« dokumentiert folgen.
Beispiel 12. Die Auswertung von Zeitstempeln anzeigen
$ systemd-analyze timestamp yesterday now tomorrow
Original form: yesterday
Normalized form: Mon 2019-05-20 00:00:00 CEST
(in UTC): Sun 2019-05-19 22:00:00 UTC
UNIX seconds: @15583032000
From now: 1 day 9h ago
Original form: now
Normalized form: Tue 2019-05-21 09:48:39 CEST
(in UTC): Tue 2019-05-21 07:48:39 UTC
UNIX seconds: @1558424919.659757
From now: 43us ago
Original form: tomorrow
Normalized form: Wed 2019-05-22 00:00:00 CEST
(in UTC): Tue 2019-05-21 22:00:00 UTC
UNIX seconds: @15584760000
From now: 14h left
systemd-analyze timespan AUSDRUCK…
Dieser Befehl wertet die Zeitspanne (d.h. die Differenz zwischen zwei Zeitstempeln) aus und gibt die
normalisierte Form und das Äquivalent in Mikrosekunden aus. Die Zeitspanne sollte daher der Syntax wie in
systemd.time(7), Abschnitt »ZEITSPANNEN AUSWERTEN« dokumentiert folgen. Werte ohne Einheit werden als
Sekunden ausgewertet.
Beispiel 13. Die Auswertung von Zeitspannen anzeigen
$ systemd-analyze timespan 1s 300s '1year 0.000001s'
Original: 1s
μs: 1000000
Human: 1s
Original: 300s
μs: 300000000
Human: 5min
Original: 1year 0.000001s
μs: 31557600000001
Human: 1y 1us
systemd-analyze cat-config NAME|PFAD…
Dieser Befehl ist ähnlich zu systemctl cat, agiert aber auf Konfigurationsdateien. Es kopiert den Inhalt
einer Konfigurationsdatei und aller Ergänzungsdateien in die Standardausgabe; dabei berücksichtigt es die
normale 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 relativ zu dem Präfix (wie systemd/logind.conf) sein.
Beispiel 14. 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 verify DATEI…
Dieser Befehl 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) werden unterstützt und
können 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.
Derzeit werden die folgenden Fehler erkannt:
• unbekannte Abschnitte und Anweisungen,
• 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 wurden oder nicht
ausführbar sind.
Beispiel 15. Falschgeschriebene Anweisung
$ 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 16. 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.
systemd-analyze security [UNIT…]
Dieser Befehl analysiert die Sicherheits- und Sandbox-Einstellungen einer oder mehrerer festgelegter
Units. Falls mindestens ein Unit-Name festgelegt ist, werden die Sicherheitseinstellungen der
festgelegten Dienste-Units untersucht und eine detaillierte Analyse angezeigt. Falls kein Unit-Name
festgelegt ist, werden alle derzeit geladenen, langlaufenden Dienste-Units untersucht und eine knappe
Tabelle mit den Ergebnissen angezeigt. Der Befehl prüft auf verschiedene sicherheitsbezogene
Diensteeinstellungen, weist jeder einen »Gefährdungsstufen«-Wert zu, abhängig davon, wie wichtig die
Einstellung ist. Dann berechnet es eine Gesamtgefährdungsstufe für die gesamte Unit, die eine Abschätzung
im Bereich 0.0…10.0 ist und anzeigt, wie aus Sicherheitssicht ein Dienst gefährdet ist. Hohe
Gefährdungsstufen deuten an, dass Sandboxing nur im geringen Umfang verwandt wird. Geringe
Gefährdungsstufen deuten an, dass enges Sandboxing und stärkste Sicherheitsbeschränkungen angewandt
werden. Beachten Sie, dass dies nur die Sicherheitsfunktionalitäten pro Dienst analysiert, die Systemd
selbst implementiert. Das bedeutet, dass sämtliche zusätzlichen Sicherheitsmechanismen, die vom
Dienste-Code selbst erbracht werden, nicht berücksichtigt werden. Die auf diese Art bestimmte
Gefährdungsstufe sollte nicht missverstanden werden: eine hohe Gefährdungsstufe bedeutet weder, dass vom
Dienste-Code selbst kein wirksames Sandboxing angewandt wird, noch dass der Dienst tatsächlich für lokale
Angriffe oder solche aus der Ferne verwundbar ist. Hohe Gefährdungsstufen deuten allerdings an, dass der
Dienst am wahrscheinlichsten von zusätzlichen Einstellungen für sie Nutzen ziehen würde.
Bitte beachten Sie, dass viele der Sicherheits- und Sandboxing-Einstellungen jeweils einzeln umgangen
werden können — außer sie werden mit anderen kombiniert. Falls ein Dienst beispielsweise das Privileg
behält, Einhängepunkte zu etablieren oder rückgängig zu machen, können viele der Sandboxing-Optionen
durch den System-Code selbst rückgängig gemacht werden. Daher ist es wesentlich, dass jeder Dienst die
umfassendsten und strengsten Sicherheits- und Sandboxing-Einstellungen, die möglich sind, verwendet. Das
Werkzeug wird einige dieser Kombinationen und Beziehungen zwischen den Einstellungen berücksichtigen,
aber nicht alle. Beachten Sie auch, dass die Sicherheits- und Sandboxing-Einstellungen, die hier
analysiert werden, nur für vom Dienste-Code selbst ausgeführte Aktionen greifen. Falls ein Dienst Zugriff
auf ein IPC-System (wie D-Bus) hat, könnte er Aktionen von anderen Diensten erbitten, die nicht den
gleichen Beschränkungen unterliegen. Daher ist jede umfassende Sicherheits- und Sandboxing-Analyse
unvollständig, falls die IPC-Zugriffsregeln nicht auch gegengeprüft werden.
Beispiel 17. systemd-logind.service analysieren
$ systemd-analyze security --no-pager systemd-logind.service
NAME DESCRIPTION EXPOSURE
â PrivateNetwork= Service has access to the host's network 0.5
â User=/DynamicUser= Service runs as root user 0.4
â DeviceAllow= Service has no device ACL 0.2
â IPAddressDeny= Service blocks all IP address ranges
...
â Overall exposure level for systemd-logind.service: 4.1 OK ð
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 Tests 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(1) 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.
--iterations=ANZAHL
Zeigt bei der Verwendung zusammen mit dem Befehl calendar die festgelegte Anzahl an Iterationen, zu
denen die festgelegten Kalenderausdrücke das nächste Mal ablaufen. Standardmäßig 1.
-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 Port, auf dem SSH auf Anfragen wartet, getrennt durch »:« und dann ein Container auf dem
festgelegten Host angehängt werden, womit direkt zu einem bestimmten Container auf dem angegebenen
Rechner verbunden wird. Dies verwendet SSH, um mit der Maschinen-Verwalterinstanz auf dem Rechner in
der Ferne zu kommunizieren. Container-Namen dürfen mit machinectl -H RECHNER aufgezählt werden.
Stellen Sie IPv6-Adressen in Klammern.
-M, --machine=
Führt die Aktion in 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 ein Textanzeigeprogramm weiterleiten.
EXIT-STATUS
Bei Erfolg wird 0 zurückgegeben, anderenfalls ein Fehlercode ungleich Null.
UMGEBUNGSVARIABLEN
$SYSTEMD_PAGER
Zu verwendendes Textanzeigeprogramm, wenn --no-pager nicht angegeben ist, setzt $PAGER außer Kraft.
Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe wohlbekannter
Textanzeigeprogrammimplementierungen der Reihe nach ausprobiert, einschließlich less(1) und more(1),
bis eines gefunden wird. Falls keine Textanzeigeprogrammimplementierung gefunden wird, wird keines
aufgerufen. Setzen der Umgebungsvariablen auf die leere Zeichenkette oder den Wert »cat« ist
äquivalent zur Übergabe von --no-pager.
$SYSTEMD_LESS
Setzt die an less übergebenen Optionen (standardmäßig »FRSXMK«) außer Kraft.
Benutzer könnten insbesondere zwei Optionen ändern wollen:
K
Diese Option weist den Seitenbetrachter an, sich sofort beim Druck von Strg-C zu beenden. Um less
die Handhabung von Strg-C selbst zum Umschalten auf die Eingabeaufforderung zu erlauben, setzen
Sie diese Option zurück.
Falls der Wert von $SYSTEMD_LESS kein »K« enthält und less das aufgerufene Textanzeigeprogramm
ist, wird Strg+C durch das Programm ignoriert und muss durch das Textanzeigeprogramm selbst
gehandhabt werden.
X
Diese Option weist den Seitenbetrachter an, keine Termcap-Initialisierungs- und
-Deinitalisierungszeichenketten an das Terminal zu senden. Dies ist standardmäßig gesetzt, damit
die Darstellung von Befehlen selbst nach dem Beenden des Seitenanzeigeprogramms sichtbar bleibt.
Allerdings verhindert dies, dass ein Teil der Funktionalität des Seitenbetrachtungsprogramms
funktioniert, insbesondere kann die Ausgabe des Seitenbetrachtungsprogramms nicht mit der Maus
durchlaufen werden.
Siehe less(1) für weitere Ausführungen.
$SYSTEMD_LESSCHARSET
Setzt den an less übergebenen 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>.
systemd 243 SYSTEMD-ANALYZE(1)