Provided by: manpages-de_2.16-1_all bug

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 BEDINGUNGsystemd-analyze [OPTIONEN…] syscall-filter [GRUPPE…]

       systemd-analyze [OPTIONEN…] calendar SPEZsystemd-analyze [OPTIONEN…] timestamp ZEITSTEMPELsystemd-analyze [OPTIONEN…] timespan SPANNEsystemd-analyze [OPTIONEN…] cat-config NAME|PFADsystemd-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>.