Provided by: manpages-de_4.21.0-2_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…] dump [MUSTER…]

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

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

       systemd-analyze [OPTIONEN…] unit-files

       systemd-analyze [OPTIONEN…] unit-paths

       systemd-analyze [OPTIONEN…] exit-status [STATUS…]

       systemd-analyze [OPTIONEN…] capability [CAPABILITY…]

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

       systemd-analyze [OPTIONEN…] filesystems [GRUPPE…]

       systemd-analyze [OPTIONEN…] calendar SPEZsystemd-analyze [OPTIONEN…] timestamp ZEITSTEMPELsystemd-analyze [OPTIONEN…] timespan SPANNEsystemd-analyze [OPTIONEN…] cat-config NAME|PFADsystemd-analyze [OPTIONEN…] compare-versions VERSION1 [OP] VERSION2

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

       systemd-analyze [OPTIONEN…] security UNITsystemd-analyze [OPTIONEN…] inspect-elf DATEIsystemd-analyze [OPTIONEN…] malloc [D-BUS-DIENST…]

       systemd-analyze [OPTIONEN…] fdstore [UNIT…]

       systemd-analyze [OPTIONEN…] image-policy RICHTLINIEsystemd-analyze [OPTIONEN…] pcrs [PCR…]

       systemd-analyze [OPTIONEN…] srk > DATEI

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 Initrd verbracht wurde, 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 angegebenen
       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 critical-chain

           $ 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 dump [Muster…]
       Ohne jeden Parameter gibt dieser Befehl eine (normalerweise sehr lange) menschenlesbare
       Serialisierung des kompletten Diensteverwalterzustandes aus. Es können optionale
       Glob-Muster angegeben werden, die dazu führen, dass die Ausgabe auf Units beschränkt wird,
       die auf eines der Muster passen. Das Ausgabeformat unterliegt ohne Ankündigungen
       Änderungen und sollte nicht durch Anwendungen ausgewertet werden. Für nicht privilegierte
       Benutzer ist dieser Befehl ratenbegrenzt.

       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 malloc [D-Bus-Dienst…]
       Dieser Befehl kann zur Anfrage der Ausgabe des internen Speicherzustandes (wie von
       malloc_info(3) zurückgeliefert) eines D-Bus-Dienstes verwandt werden. Falls kein Dienst
       angegeben ist, wird die Anfrage an org.freedesktop.systemd1 (dem System- oder
       Benutzerdiensteverwalter) gesandt. Es wird nicht garantiert, dass das Ausgabeformat stabil
       ist und es sollte nicht von Anwendungen ausgewertet werden.

       Der Dienst muss die Schnittstelle org.freedesktop.MemoryAllocation1 implementieren. In der
       Systemd-Sammlung ist dies aktuell nur für den Verwalter der Fall.

   systemd-analyze plot
       Dieser Befehl gibt entweder eine SVG-Graphik aus, die detailliert, welche Systemdienste zu
       welcher Zeit gestartet wurden und hervorhebt, welche Zeit sie zur Initialisierung
       verbraucht haben oder die rohen Zeitdaten im JSON- oder Tabellenformat.

       Beispiel 5. Eine Systemstartübersicht darstellen

           $ systemd-analyze plot >bootup.svg
           $ eog bootup.svg&

       Beachten Sie, dass diese Darstellung auf den jüngsten Unit-bezogenen Zeitmessungsdaten von
       geladenen Units basiert. Das bedeutet, dass die angezeigten Informationen den letzten
       Startzyklus abdecken werden, falls eine Unit gestartet, gestoppt und dann wieder gestartet
       wird, nicht den ersten. Daher wird empfohlen, diese Informationen nur kurz nach dem
       Systemstart zu betrachten, so dass dieser Unterschied keine Rolle spielt. Desweiteren
       könnten Units, die von keiner anderen Unit über eine Abhängigkeit referenziert werden,
       durch den Diensteverwalter entladen werden, sobald sie sich beenden (und nicht
       fehlschlugen). Solche Units werden in der Darstellung nicht auftauchen.

   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 dieser Unterbefehl 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 angegeben sind,
       werden alle bekannten Status angezeigt. Andernfalls werden nur die Definitionen für die
       angegebenen Codes angezeigt.

       Beispiel 4. Ein paar Beispiel-Exit-Status 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 capability [CAPABILITY…]
       Dieser Befehl gibt eine Liste der Linux-Capabilities zusammen mit ihren numerischen
       Kennungen aus. Siehe capabilities(7) für Details. Falls kein Argument angegeben ist, wird
       die vollständige Liste der dem Diensteverwalter und dem Kernel bekannten Capabilities
       ausgegeben. Capabilities, die vom Kernel definiert werden aber dem Diensteverwalter nicht
       bekannt sind, werden als »cap_???« angezeigt. Falls Argumente angegeben sind, können sich
       diese optional auch auf bestimmte Capabilities über ihren Namen oder ihre numerische
       Kennung beziehen, wodurch dann nur die bezeichneten Capabilities in der Tabelle angezeigt
       werden.

       Beispiel 10. Ein paar Beispiel-Capability-Namen anzeigen

           $ systemd-analyze capability 0 1 {30..32}
           NAME              NUMBER
           cap_chown              0
           cap_dac_override       1
           cap_audit_control     30
           cap_setfcap           31
           cap_mac_override      32

   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 11. 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 führt die in der angegebenen GRUPPE enthaltenen Systemaufrufe auf oder alle
       bekannten Gruppen, falls keine Gruppen angegeben sind. Das Argument GRUPPE muss das Präfix
       »@« enthalten.

   systemd-analyze filesystems [GRUPPE…]
       Dieser Befehl führt die in der angegebenen Dateisystemgruppe GRUPPE enthaltenen
       Dateisysteme auf oder alle bekannten Gruppen, falls keine Gruppen angegeben sind. Das
       Argument GRUPPE muss das Präfix »@« enthalten.

   systemd-analyze calendar AUSDRUCK…
       Dieser Befehl wertet wiederholende Kalenderzeitereignisse aus und normiert und berechnet,
       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 angegebene Anzahl der nächsten Male
       anzuzeigen, zu denen der Ausdruck abläuft. Jedes Mal, wenn der Ausdruck abläuft, wird ein
       Zeitstempel gebildet, siehe den Unterbefehl timestamp weiter unten.

       Beispiel 12. 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 13. 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 14. 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. Er
       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 15. 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 compare-versions VERSION1 [OP] VERSION2
       Dieser Befehl hat zwei unterschiedliche Betriebsmodi, abhängig davon, ob der Operator OP
       angegeben wurde.

       Im ersten Modus – wenn OP nicht angegeben wurde – wird er die zwei Versionszeichenketten
       vergleichen und entweder »VERSION1 < VERSION2«, »VERSION1 == VERSION2« oder »VERSION1 >
       VERSION2« (je nachdem, was passt) ausgeben.

       Der Exit-Status ist 0, falls die Versionen identisch sind, 11, falls die Version auf der
       rechten Seite kleiner ist und 12, falls die Version auf der linken Seite kleiner ist.
       (Dies passt auf die von rpmdev-vercmp verwandten Konventionen.)

       Im zweiten Modus – wenn OP angegeben wurde – wird er die zwei Versionszeichenketten
       mittels der Operation OP vergleichen und 0 (Erfolg) zurückliefern, falls die Bedingung
       erfüllt ist und andernfalls 1 (Fehlschlag). OP kann lt, le, eq, ne, ge, gt sein. In diesem
       Modus erfolgt keine Ausgabe. (Dies passt auf die von dpkg(1) --compare-versions verwandte
       Konvention.)

       Beispiel 16. Versionen eines Paketes vergleichen

           $ systemd-analyze compare-versions systemd-250~rc1.fc36.aarch64 systemd-251.fc36.aarch64
           systemd-250~rc1.fc36.aarch64 < systemd-251.fc36.aarch64
           $ echo $?
           12

           $ systemd-analyze compare-versions 1 lt 2; echo $?
           0
           $ systemd-analyze compare-versions 1 ge 2; echo $?
           1

   systemd-analyze verify DATEI…
       Dieser Befehl lädt Unit-Dateien und gibt Warnungen aus, falls irgendwelche Fehler erkannt
       werden. Auf der Befehlszeile angegebene Dateien werden geladen, aber auch alle von diesen
       referenzierte Units. Der Unit-Name auf der Platte kann außer Kraft gesetzt werden, indem
       nach dem Dopppelpunkt ein Alias angegeben wird, ein Beispiel hierfür ist weiter unten zu
       finden. Der komplette Unit-Suchpfad wird durch Kombination der Verzeichnisse für alle
       Befehlzeilenargumente und dem normalen Unit-Ladepfad zusammengestellt. Die 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.

       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 17. 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 18. 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.

       Beispiel 19. Alias für eine Unit

           $ cat /tmp/source
           [Unit]
           Description=Hostname printer

           [Service]
           Type=simple
           ExecStart=/usr/bin/echo %H
           MysteryKey=true

           $ systemd-analyze verify /tmp/source
           Failed to prepare filename /tmp/source: Invalid argument

           $ systemd-analyze verify /tmp/source:alias.service
           alias.service:7: Unknown key name 'MysteryKey' in section 'Service', ignoring.

   systemd-analyze security [UNIT…]
       Dieser Befehl analysiert die Sicherheits- und Sandbox-Einstellungen einer oder mehrerer
       angegebener Units. Falls mindestens ein Unit-Name angegeben ist, werden die
       Sicherheitseinstellungen der angegebenen Dienste-Units untersucht und eine detaillierte
       Analyse angezeigt. Falls kein Unit-Name angegeben 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 20. 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 🙂

   systemd-analyze inspect-elf DATEI…
       Dieser Befehl wird die angegebenen Dateien laden, falls sie ELF-Objekte (Programme,
       Bibliotheken, Speicherauszugdateien usw.) sind wird es die eingebetteten
       Paketierungsmetadaten auswerten, falls vorhanden, und sie in einer Tabelle im JSON-Format
       ausgeben. Siehe die Dokumentation Metadaten-Paketierung[1] für weitere Informationen.

       Beispiel 21. Informationen über eine Speicherauszugsdatei als JSON ausgeben

           $ systemd-analyze inspect-elf --json=pretty \
                   core.fsverity.1000.f77dac5dc161402aa44e15b7dd9dcf97.58561.1637106137000000
           {
                   "elfType" : "coredump",
                   "elfArchitecture" : "AMD x86-64",
                   "/home/bluca/git/fsverity-utils/fsverity" : {
                           "type" : "deb",
                           "name" : "fsverity-utils",
                           "version" : "1.3-1",
                           "buildId" : "7c895ecd2a271f93e96268f479fdc3c64a2ec4ee"
                   },
                   "/home/bluca/git/fsverity-utils/libfsverity.so.0" : {
                           "type" : "deb",
                           "name" : "fsverity-utils",
                           "version" : "1.3-1",
                           "buildId" : "b5e428254abf14237b0ae70ed85fffbb98a78f88"
                   }
           }

   systemd-analyze fdstore [UNIT…]
       Listet die aktuellen Inhalte des Dateideskriptorspeichers der angegebenen Dienste-Unit
       auf. Dies zeigt Namen, Inode-Typen, Gerätenummern, Inode-Nummern, Pfade und Öffnungsmodi
       der offenen Dateideskriptoren an. Die angegebenen Units müssen FileDescriptorStoreMax=
       aktiviert haben, siehe systemd.service(5) zu Details.

       Beispiel 22. Tabellenausgabe

           $ systemd-analyze fdstore systemd-journald.service
           FDNAME TYPE DEVNO   INODE RDEVNO PATH             FLAGS
           stored sock 0:8   4218620 -      socket:[4218620] ro
           stored sock 0:8   4213198 -      socket:[4213198] ro
           stored sock 0:8   4213190 -      socket:[4213190] ro
           ...

       Hinweis: Die Spalte »DEVNO« bezieht sich auf die Major-/Minor-Nummern des Geräteknotens,
       der dem Dateisystem zu Grunde liegt, auf dem die Inode des Dateideskriptors ist. Die
       Spalte »RDEVNO« bezieht sich auf die Major-/Minor-Nummern des Geräteknotens selbst, falls
       der Dateideskriptor sich auf einen bezieht. Vergleichen Sie dies mit den entsprechenden
       Feldern .st_dev und .st_rdev in struct stat (siehe stat(2) zu Details). Die aufgeführten
       Inode-Nummern in der Spalte »INODE« sind auf dem durch »DEVNO« angezeigten Dateisystem.

   systemd-analyze image-policy [RICHTLINIE…]
       Dieser Befehl analysiert die angegebene Abbild-Richtlinienzeichenkette gemäß
       systemd.image-policy(7). Die Richtlinie wird normalisiert und vereinfacht. Für jeden
       aktuell definierten Partitionskennzeichner (gemäß der Spezifikation für auffindbare
       Partitionen[2]) wird die Auswirkung der Abbild-Richtlinienzeichenkette in Tabellenform
       dargestellt.

       Beispiel 23. Beispielausgabe

           $ systemd-analyze image-policy swap=encrypted:usr=read-only-on+verity:root=encrypted
           Analyzing policy: root=encrypted:usr=verity+read-only-on:swap=encrypted
                  Long form: root=encrypted:usr=verity+read-only-on:swap=encrypted:=unused+absent

           PARTITION       MODE        READ-ONLY GROWFS
           root            encrypted   -         -
           usr             verity      yes       -
           home            ignore      -         -
           srv             ignore      -         -
           esp             ignore      -         -
           xbootldr        ignore      -         -
           swap            encrypted   -         -
           root-verity     ignore      -         -
           usr-verity      unprotected yes       -
           root-verity-sig ignore      -         -
           usr-verity-sig  ignore      -         -
           tmp             ignore      -         -
           var             ignore      -         -
           default         ignore      -         -

   systemd-analyze pcrs [PCR…]
       Dieser Befehl zeigt die bekannten TPM2-PCRs zusammen mit ihren kennzeichnenden Namen und
       aktuellen Werten.

       Beispiel 24. Beispielausgabe

           $ systemd-analyze pcrs
           NR NAME                SHA256
            0 platform-code       bcd2eb527108bbb1f5528409bcbe310aa9b74f687854cc5857605993f3d9eb11
            1 platform-config     b60622856eb7ce52637b80f30a520e6e87c347daa679f3335f4f1a600681bb01
            2 external-code       1471262403e9a62f9c392941300b4807fbdb6f0bfdd50abfab752732087017dd
            3 external-config     3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
            4 boot-loader-code    939f7fa1458e1f7ce968874d908e524fc0debf890383d355e4ce347b7b78a95c
            5 boot-loader-config  864c61c5ea5ecbdb6951e6cb6d9c1f4b4eac79772f7fe13b8bece569d83d3768
            6 -                   3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
            7 secure-boot-policy  9c905bd9b9891bfb889b90a54c4b537b889cfa817c4389cc25754823a9443255
            8 -                   0000000000000000000000000000000000000000000000000000000000000000
            9 kernel-initrd       9caa29b128113ef42aa53d421f03437be57211e5ebafc0fa8b5d4514ee37ff0c
           10 ima                 5ea9e3dab53eb6b483b6ec9e3b2c712bea66bca1b155637841216e0094387400
           11 kernel-boot         0000000000000000000000000000000000000000000000000000000000000000
           12 kernel-config       627ffa4b405e911902fe1f1a8b0164693b31acab04f805f15bccfe2209c7eace
           13 sysexts             0000000000000000000000000000000000000000000000000000000000000000
           14 shim-policy         0000000000000000000000000000000000000000000000000000000000000000
           15 system-identity     0000000000000000000000000000000000000000000000000000000000000000
           16 debug               0000000000000000000000000000000000000000000000000000000000000000
           17 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
           18 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
           19 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
           20 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
           21 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
           22 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
           23 application-support 0000000000000000000000000000000000000000000000000000000000000000

   systemd-analyze srk > DATEI
       Dieser Befehl liest den Speicherwurzelschlüssel (SRK) aus dem TPM2-Gerät und schreibt ihn
       in angeordnetem TPM2B_PUBLIC-Format in die Standardausgabe. Beispiel:

           systemd-analyze srk > srk.tpm2b_public

OPTIONEN

       Die folgenden Optionen werden verstanden:

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

           Hinzugefügt in Version 209.

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

           Hinzugefügt in Version 186.

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

           Hinzugefügt in Version 238.

       --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.

           Hinzugefügt in Version 198.

       --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 angegeben werden, müssen sie auf mindestens einer Seite
           der Relation passen. Mit anderen Worten, Muster, die mit diesen zwei Optionen
           angegeben 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.

           Hinzugefügt in Version 201.

       --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 angegeben, z.B.
           »50ms«.

           Hinzugefügt in Version 203.

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

           Hinzugefügt in Version 235.

       --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.

           Hinzugefügt in Version 235.

       --recursive-errors=MODUS
           Steuert die Überprüfung von Units und ihrere Abhängigkeiten und ob systemd-analyze
           verify sich mit einem von Null verschiedenen Exit-Status beenden soll oder nicht. Mit
           yes wird ein von Null verschiedener Prozess-Exit-Status zurückgeliefert, wenn während
           der Überprüfung von entweder der angegebenen Unit oder einer ihrer zugeordneten
           Abhängigkeiten Warnungen auftreten. Mit no wird wird ein von Null verschiedener
           Prozess-Exit-Status zurückgeliefert, wenn Warnungen während der Überprüfung nur der
           angegebenen Unit auftreten. Mit one wird ein von Null verschiedener
           Prozess-Exit-Status zurückgeliefert, wenn entweder bei der angegebenen Unit oder
           seiner direkten Abhängigkeit Warnungen auftreten Falls dies Option nicht angegegeben
           ist, wird Null als Exit-Status zurückgegeben, unabhängig davon, ob während der
           Überprüfung Warnungen auftraten oder nicht.

           Hinzugefügt in Version 250.

       --root=PFAD
           Agiert mit cat-files und verify auf Dateien unterhalb des angegebenen Wurzelpfades
           PFAD.

           Hinzugefügt in Version 239.

       --image=PFAD
           Agiert mit cat-files und verify auf Dateien innerhalb des angebebenen Abbildpfades
           PFAD.

           Hinzugefügt in Version 250.

       --image-policy=Richtlinie
           Akzeptiert gemäß systemd.image-policy(7) eine Abbildrichtlinienzeichenkette als
           Argument. Die Richtlinie wird bei Aktionen auf dem mittels --image= angegebenen
           Plattenabbild durchgesetzt, siehe oben. Falls nicht angegeben ist die Vorgabe die
           Richtlinie »*«, d.h. alle erkannten Dateisysteme im Abbild werden verwandt.

       --offline=LOGISCH
           Führt mit security eine Offline-Sicherheitsüberprüfung der angegebenen Unit-Dateien
           durch, d.h. verlässt sich nicht auf PID 1, um Sicherheitsinformationen für die Dateien
           zu erlangen, wie es der Unterbefehl security alleine tut. Dies bedeutet, dass
           --offline= auch mit --root= und --image= verwandt werden kann. Falls das
           Offenlegungs-Niveau einer Unit oberhalb des mit --threshold= gesetzten ist
           (Standardwert 100), wird --offline= einen Fehler zurückliefern.

           Hinzugefügt in Version 250.

       --profile=PFAD
           Berücksichtigt mit security --offline= beim Zugriff auf die Unit-Einstellungen die
           angegeben portablen Profile. Das Profil kann als Name übergeben werden, wodurch die
           gut bekannten Systemorte durchsucht werden, oder es kann der vollständige Pfad zu
           einer angegebenen Ergänzungsdatei sein.

           Hinzugefügt in Version 250.

       --threshold=WERT
           Erlaubt mit security dem Benutzer einen angepassten Wert zu setzen, mit dem das
           Gesamtoffenlegungsniveau für die angegebenen Unit-Dateien verglichen wird. Falls das
           Offenlegungsniveau einer Unit größer als das vom Benutzer gesetzte ist, wird security
           einen Fehler zurückliefern. --threshold= kann auch mit --offline= verwandt werden und
           sein Vorgabewert ist 100.

           Hinzugefügt in Version 250.

       --security-policy=PFAD
           Erlaubt es mit security dem Benutzer, eine angepasste Gruppe an Anforderungen, die als
           JSON-Datei formatiert ist, zu definieren, mit der die angegebenen Unit-Datei(en)
           verglichen werden und ihr Gesamt-Offenlegungsniveau im Hinblick auf
           Sicherheitsbedrohungen bestimmt wird.

           Tabelle 1. Akzeptierte Bewertungs-Testkennzeichner
           ┌─────────────────────────────────────────────────────────┐
           │Bewertungs-Testkennzeichner                              │
           ├─────────────────────────────────────────────────────────┤
           │UserOrDynamicUser                                        │
           ├─────────────────────────────────────────────────────────┤
           │SupplementaryGroups                                      │
           ├─────────────────────────────────────────────────────────┤
           │PrivateMounts                                            │
           ├─────────────────────────────────────────────────────────┤
           │PrivateDevices                                           │
           ├─────────────────────────────────────────────────────────┤
           │PrivateTmp                                               │
           ├─────────────────────────────────────────────────────────┤
           │PrivateNetwork                                           │
           ├─────────────────────────────────────────────────────────┤
           │PrivateUsers                                             │
           ├─────────────────────────────────────────────────────────┤
           │ProtectControlGroups                                     │
           ├─────────────────────────────────────────────────────────┤
           │ProtectKernelModules                                     │
           ├─────────────────────────────────────────────────────────┤
           │ProtectKernelTunables                                    │
           ├─────────────────────────────────────────────────────────┤
           │ProtectKernelLogs                                        │
           ├─────────────────────────────────────────────────────────┤
           │ProtectClock                                             │
           ├─────────────────────────────────────────────────────────┤
           │ProtectHome                                              │
           ├─────────────────────────────────────────────────────────┤
           │ProtectHostname                                          │
           ├─────────────────────────────────────────────────────────┤
           │ProtectSystem                                            │
           ├─────────────────────────────────────────────────────────┤
           │RootDirectoryOrRootImage                                 │
           ├─────────────────────────────────────────────────────────┤
           │LockPersonality                                          │
           ├─────────────────────────────────────────────────────────┤
           │MemoryDenyWriteExecute                                   │
           ├─────────────────────────────────────────────────────────┤
           │NoNewPrivileges                                          │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_SYS_ADMIN                      │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_SET_UID_GID_PCAP               │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_SYS_PTRACE                     │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_SYS_TIME                       │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_NET_ADMIN                      │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_SYS_RAWIO                      │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_SYS_MODULE                     │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_AUDIT                          │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_SYSLOG                         │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_SYS_NICE_RESOURCE              │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_MKNOD                          │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_CHOWN_FSETID_SETFCAP           │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_DAC_FOWNER_IPC_OWNER           │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_KILL                           │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_NET_BIND_SERVICE_BROADCAST_RAW │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_SYS_BOOT                       │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_MAC                            │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_LINUX_IMMUTABLE                │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_IPC_LOCK                       │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_SYS_CHROOT                     │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_BLOCK_SUSPEND                  │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_WAKE_ALARM                     │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_LEASE                          │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_SYS_TTY_CONFIG                 │
           ├─────────────────────────────────────────────────────────┤
           │CapabilityBoundingSet_CAP_BPF                            │
           ├─────────────────────────────────────────────────────────┤
           │UMask                                                    │
           ├─────────────────────────────────────────────────────────┤
           │KeyringMode                                              │
           ├─────────────────────────────────────────────────────────┤
           │ProtectProc                                              │
           ├─────────────────────────────────────────────────────────┤
           │ProcSubset                                               │
           ├─────────────────────────────────────────────────────────┤
           │NotifyAccess                                             │
           ├─────────────────────────────────────────────────────────┤
           │RemoveIPC                                                │
           ├─────────────────────────────────────────────────────────┤
           │Delegate                                                 │
           ├─────────────────────────────────────────────────────────┤
           │RestrictRealtime                                         │
           ├─────────────────────────────────────────────────────────┤
           │RestrictSUIDSGID                                         │
           ├─────────────────────────────────────────────────────────┤
           │RestrictNamespaces_user                                  │
           ├─────────────────────────────────────────────────────────┤
           │RestrictNamespaces_mnt                                   │
           ├─────────────────────────────────────────────────────────┤
           │RestrictNamespaces_ipc                                   │
           ├─────────────────────────────────────────────────────────┤
           │RestrictNamespaces_pid                                   │
           ├─────────────────────────────────────────────────────────┤
           │RestrictNamespaces_cgroup                                │
           ├─────────────────────────────────────────────────────────┤
           │RestrictNamespaces_uts                                   │
           ├─────────────────────────────────────────────────────────┤
           │RestrictNamespaces_net                                   │
           ├─────────────────────────────────────────────────────────┤
           │RestrictAddressFamilies_AF_INET_INET6                    │
           ├─────────────────────────────────────────────────────────┤
           │RestrictAddressFamilies_AF_UNIX                          │
           ├─────────────────────────────────────────────────────────┤
           │RestrictAddressFamilies_AF_NETLINK                       │
           ├─────────────────────────────────────────────────────────┤
           │RestrictAddressFamilies_AF_PACKET                        │
           ├─────────────────────────────────────────────────────────┤
           │RestrictAddressFamilies_OTHER                            │
           ├─────────────────────────────────────────────────────────┤
           │SystemCallArchitectures                                  │
           ├─────────────────────────────────────────────────────────┤
           │SystemCallFilter_swap                                    │
           ├─────────────────────────────────────────────────────────┤
           │SystemCallFilter_obsolete                                │
           ├─────────────────────────────────────────────────────────┤
           │SystemCallFilter_clock                                   │
           ├─────────────────────────────────────────────────────────┤
           │SystemCallFilter_cpu_emulation                           │
           ├─────────────────────────────────────────────────────────┤
           │SystemCallFilter_debug                                   │
           ├─────────────────────────────────────────────────────────┤
           │SystemCallFilter_mount                                   │
           ├─────────────────────────────────────────────────────────┤
           │SystemCallFilter_module                                  │
           ├─────────────────────────────────────────────────────────┤
           │SystemCallFilter_raw_io                                  │
           ├─────────────────────────────────────────────────────────┤
           │SystemCallFilter_reboot                                  │
           ├─────────────────────────────────────────────────────────┤
           │SystemCallFilter_privileged                              │
           ├─────────────────────────────────────────────────────────┤
           │SystemCallFilter_resources                               │
           ├─────────────────────────────────────────────────────────┤
           │IPAddressDeny                                            │
           ├─────────────────────────────────────────────────────────┤
           │DeviceAllow                                              │
           ├─────────────────────────────────────────────────────────┤
           │AmbientCapabilities                                      │
           └─────────────────────────────────────────────────────────┘
           Siehe die nachfolgende beispielhafte »JSON-Richtlinie«.

           Hinzugefügt in Version 250.

       --json=MODUS
           Erstellt mit dem Befehl security eine JSON-formatierte Ausgabe der
           Sicherheitsanalysetabelle. Das Format ist ein JSON-Feld mit Objekten, die die
           folgenden Fehler enthalten: set (zeigt an, ob die Einstellung aktiviert wurde oder
           nicht), name (damit wird auf die Einstellung Bezug genommen), json_field
           (JSON-kompatible Kennung der Einstellung), description (Kurzfassung des Zustands der
           Einstellung) und exposure (eine Zahl im Bereich 0.0…10.0, wobei eine höhere Zahl einer
           höheren Sicherheitsbedrohung entspricht). Die JSON-Version der Tabelle wird auf die
           Standardausgabe ausgegeben. Der an die Option übergebene MODUS kann einer der drei
           folgenden sein: off (die Vorgabe), pretty und short, die eine verschönerte bzw.
           gekürzte JSON-Version der Sicherheitstabelle ausgeben. Mit dem Befehl plot wird eine
           JSON-formatierte Ausgabe der rohen Zeitdaten erstellt. Das Format ist ein JSON-Feld
           mit Objekten, die die folgenden Felder enthalten: name, der der Unit-Dateiname ist,
           activated, das die Zeit nach dem Starten, die der Dienst aktiviert wurde, enthält;
           time, dass die Zeit enthält, die der Dienst zum Aktivieren benötigte, nachdem er
           anfänglich gestartet wurde; deactivated, das die Zeit nach dem Starten, die der Dienst
           deaktiviert war, enthält und deactivating, das die Zeit nach dem Starten enthält, nach
           der der Dienst anfänglich gebeten wurde, sich zu deaktivieren.

           Hinzugefügt in Version 250.

       --iterations=ANZAHL
           Zeigt bei der Verwendung zusammen mit dem Befehl calendar die angegebene Anzahl an
           Iterationen, zu denen die angegebenen Kalenderausdrücke das nächste Mal ablaufen.
           Standardmäßig 1.

           Hinzugefügt in Version 242.

       --base-time=ZEITSTEMPEL
           Zeigt bei der Verwendung zusammen mit dem Befehl calendar die nächste Iteration
           relativ zum angegebenen Zeitpunkt an. Falls nicht angegeben, ist die Vorgabe die
           aktuelle Zeit.

           Hinzugefügt in Version 244.

       --unit=UNIT
           Wertet bei der Verwendung mit dem Befehl condition alle Zuweisungen Condition*=… und
           Assert*=… in der angegebenen Unit-Datei aus. Der komplette Unit-Suchpfad wird durch
           Kombination der Verzeichnisse für die angegebene Unit mit dem normalen Unit-Ladepfad
           zusammengestellt. Die 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 dem Verzeichnissen vorhanden
           sind, das die angegegebene Unit enthält, werden gegenüber den in anderen Pfaden
           vorgezogen.

           Hinzugefügt in Version 250.

       --table
           Bei der Verwendung mit dem Befehl plot werden die rohen Zeitdaten in einer Tabelle
           ausgegeben.

           Hinzugefügt in Version 253.

       --no-legend
           Bei der Verwendung mit dem Befehl plot in Kombination mit entweder --table oder
           --json= wird keine Legende oder keine Hinweise in der Ausgabe aufgenommen.

           Hinzugefügt in Version 253.

       -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 angegebenen 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. Optional kann diesem ein Benutzername, abgetrennt
           durch ein »@«-Zeichen, als der verbunden werden soll, vorangestellt werden. Falls die
           besondere Zeichenkette ».host« anstelle des Container-Names verwandt wird, wird eine
           Verbindung zu dem lokalen System aufgebaut (das ist nützlich, um sich zu dem
           Benutzerbus eines bestimmten Benutzers zu verbinden: »--user --machine=lennart@.host«.
           Falls die »@«-Syntax nicht verwandt wird, wird die Verbindung als Benutzer »root«
           vorgenommen. Falls die »@«-Syntax verwandt wird, kann entweder die linke oder die
           rechte Seite fortgelassen werden (aber nicht beide). In diesem Fall wird der lokale
           Benutzername und ».host« angenommen.

       --quiet
           Unterdrückt Hinweise und andere nicht wesentliche Ausgaben.

           Hinzugefügt in Version 250.

       --tldr
           Gibt mit cat-config nur die »interessanten« Teil der Konfigurationsdatei aus,
           Kommentare und leere Zeilen sowie Abschnittkopfzeilen, denen nur Kommentare und leere
           Zeilen folgen, werden übersprungen.

           Hinzugefügt in Version 255.

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

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

       --no-pager
           Leitet die Ausgabe nicht an ein Textanzeigeprogramm weiter.

EXIT-STATUS

       Für die meisten Befehle wird bei Erfolg 0 zurückgegeben, anderenfalls ein Fehlercode
       ungleich Null.

       Mit dem Unterbefehl compare-versions in der 2-Argumente-Form wird 12, 0, 11
       zurückgeliefert, falls die zweite Versionszeichenkette größer, gleich bzw. kleiner als die
       erste ist. In der 3-Argumente-Form 0 oder 1, falls die Bedingung wahr bzw. falsch ist.

UMGEBUNGSVARIABLEN

       $SYSTEMD_LOG_LEVEL
           Die maximale Protokollierstufe ausgesandter Nachrichten (Nachrichten mit einer höheren
           Protokollierstufe, d.h. weniger wichtige, werden unterdrückt). Sie muss (in
           absteigender Reihenfolge) entweder alert, crit, err, warning, notice, info, debug oder
           eine Ganzzahl im Bereich 0…7 sein. Siehe syslog(3) für weitere Informationen.

       $SYSTEMD_LOG_COLOR
           Ein logischer Wert. Falls wahr, werden auf das TTY geschriebene Nachrichten gemäß
           ihrer Priorität eingefärbt.

           Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal
           geschrieben werden, da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen,
           selbständig Nachrichten gemäß ihrer Protokollierungsstufe einfärben.

       $SYSTEMD_LOG_TIME
           Ein logischer Wert. Falls wahr, wird den Protokollnachrichten der Konsole ein
           Zeitstempel vorangestellt.

           Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal oder
           in eine Datei geschrieben werden, da journalctl(1) und andere Werkzeuge, die
           Protokolle anzeigen, selbständig Zeitstempel basierend auf ihren Metadaten den
           Nachrichten anhängen werden.

       $SYSTEMD_LOG_LOCATION
           Ein logischer Wert. Falls wahr, wird den Protokollnachrichten ein Dateinamen und eine
           Zeilenummer in dem Quellcode, aus dem die Nachrichten stammen, vorangestellt.

           Beachten Sie, dass der Protokollierort sowieso oft als Metadaten zu den
           Journal-Einträgen angehängt ist. Die Aufnahme in den Nachrichtentext kann bei der
           Fehlersuche in Programmen dennoch praktisch sein.

       $SYSTEMD_LOG_TID
           Ein logischer Wert. Falls wahr, wird den Nachrichten die aktuelle numerische
           Thread-Kennung (TID) vorangestellt.

           Beachten Sie, dass diese Informationen sowieso als Metadatan an Journal-Einträge
           angehängt wird. Die Aufnahme direkt im Nachrichtentext kann aber trotzdem bei der
           Fehlersuche in Programmen praktisch sein.

       $SYSTEMD_LOG_TARGET
           Das Ziel für Protokolliernachrichten. Entweder console (auf das angehängte TTY
           protokollieren), console-prefixed (auf das angehängte TTY protokollieren, aber die
           Protokollierstufe und »Einrichtung« voranstellen, siehe syslog(3)), kmsg (in den
           zirkulären Kernel-Protokollpuffer protokollieren), journal (in das Journal
           protokollieren (journal-or-kmsg (in das Journal protokollieren, falls verfügbar, und
           andernfalls nach Kmsg), auto (das geeignete Protokollierziel automatisch ermitteln,
           die Vorgabe) oder null (die Protokollierung deaktivieren).

       $SYSTEMD_LOG_RATELIMIT_KMSG
           Ob Kmsg ratenlimitiert werden soll oder nicht. Akzeptiert einen logischen Wert.
           Standardmäßig »true«. Falls deaktiviert, wird Systemd die nach Kmsg geschriebenen
           Meldungen nicht ratenlimitieren.

       $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.

           Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, dann wird $SYSTEMD_PAGER
           (sowie $PAGER) ohne Rückmeldung ignoriert.

       $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 das Textanzeigeprogramm 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 das Textanzeigeprogramm 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
               Textanzeigeprogramms sichtbar bleibt. Allerdings stehen dadurch einige Funktionen
               des Textanzeigeprogramms nicht zur Verfügung; insbesondere ist das Scrollen in der
               Ausgabe mit der Maus nicht möglich.

           Siehe less(1) für weitere Ausführungen.

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

       $SYSTEMD_PAGERSECURE
           Akzeptiert einen logischen Wert. Wenn wahr, wird der »sichere« Modus des
           Seitenanzeigeprogramms verwandt, falls falsch, wird dieser deaktiviert. Falls
           $SYSTEMD_PAGERSECURE überhaupt nicht gesetzt ist, dann wird der sichere Modus
           aktiviert, falls die effektive Kennung nicht identisch zu dem Eigentümer der
           Anmeldesitzung ist, siehe geteuid(2) und sd_pid_get_owner_uid(3). Im sicheren Modus
           wird LESSSECURE=1 beim Aufruf des Seitenanzeigeprogramms gesetzt und das
           Seitenanzeigeprogramm muss Befehle deaktivieren, die neue Dateien öffnen oder
           erstellen oder die einen neuen Unterprozess starten. Falls $SYSTEMD_PAGERSECURE
           überhaupt nicht gesetzt ist, werden Seitenanzeigeprogramme, bei denen unbekannt ist,
           ob sie einen sicheren Modus implementieren, nicht verwandt. (Derzeit implementiert nur
           less(1) einen sicheren Modus.)

           Hinweis: Wenn Befehle mit erhöhten Rechten ausgeführt werden, beispielsweise mittels
           sudo(8) oder pkexec(1), muss Vorsicht walten gelassen werden, um sicherzustellen, dass
           keine ungeplanten interaktiven Funktionalitäten aktiviert werden. Der »sichere« Modus
           für das Seitenanzeigeprogramm kann wie oben beschrieben automatisch aktiviert werden.
           Durch Setzen von SYSTEMD_PAGERSECURE=0 oder durch Nichtenfernen dieser Einstellung aus
           der ererbten Umgebung wird es dem Benutzer ermöglicht, beliebige Befehle auszuführen.
           Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt werden muss, falls die Variablen
           $SYSTEMD_PAGER oder $PAGER berücksichtigt werden sollen. Es kann sinnvoll sein,
           stattdessen den Seitenanzeiger komplett mit --no-pager zu deaktivieren.

       $SYSTEMD_COLORS
           Akzeptiert ein logisches Argument. Wenn wahr, werden systemd und verwandte
           Hilfswerkzeuge Farben in ihrer Ausgabe verwenden, andernfalls wird die Ausgabe
           einfarbig sein. Zusätzlich kann die Variable eine der folgenden besonderen Werte
           annehmen: »16«, »256«, um die Verwendung von Farbe auf die grundlegenden 16 bzw. 256
           ANSI-Farben zu beschränken. Dies kann festgelegt werden, um die auf $TERM und der
           vorliegenden Verbindung der Konsole basierende automatische Entscheidung außer Kraft
           zu setzen.

       $SYSTEMD_URLIFY
           Dies muss ein logischer Wert sein. Er steuert, ob anklickbare Links für
           Terminal-Emulatoren, die dies unterstützen, erstellt werden sollen. Dies kann
           angegeben werden, um die Entscheidung, die systemd basierend auf $TERM und anderen
           Bedingungen trifft, außer Kraft zu setzen.

BEISPIELE

       Beispiel 25. JSON-Richtlinie

       Die als Pfadparameter an --security-policy= übergebene JSON-Datei hat ein JSON-Objekt
       oberster Stufe, wobei die Schlüssel die oben erwähnten Bewertungstestkennzeichner sind.
       Die Werte in der Datei sollten JSON-Objekte mit einem oder mehreren der folgenden Felder
       sein: description_na (Zeichenkette), description_good (Zeichenkette), description_bad
       (Zeichenkette), weight (vorzeichenlose Ganzzahl) und range (vorzeichenlose Ganzzahl).
       Falls eines dieser Felder, die bestimmten Kennungen der Unit-Datei entsprechen, im
       JSON-Objekt fehlt, wird standardmäßig der eingebaute Vorgabefeldwert, der der gleichen
       Kennung entspricht, für die Sicherheitsanalyse verwandt. Die Felder »weight« und »range«
       werden zum Bestimmen der Gesamt-Offenlegungsstufe der Unit-Dateien verwandt: dem Wert
       jeder Einstellung wird ein Schlechtigkeitsstand zugewiesen, der mit dem Richtliniengewicht
       multipliziert und durch den Richtlinienbereich geteilt wird, um die Gesamtoffenlegung zu
       bestimmen, den diese Einstellung impliziert. Die berechnete Schlechtigkeit wird über alle
       Einstellungen in der Unit-Datei aufsummiert, auf den Bereich 1…100 normiert und dazu
       verwandt, die Gesamtoffenlegungsstufe der Unit zu bestimmen. Indem Benutzer diese Felder
       verändern können, gibt der »security«-Unterbefehl ihnen die Möglichkeit, für sich selbst
       zu entscheiden, welche Kennungen wichtiger sind und daher einen größeren Effekt auf die
       Offenlegungsstufe haben sollten. Ein Gewicht von »0« bedeutet, dass die Einstellung nicht
       geprüft wird.

           {
             "PrivateDevices":
               {
               "description_good": "Dienst hat keinen Zugriff auf Hardware-Geräte",
               "description_bad": "Dienst hat möglicherweise Zugriff auf Hardware-Geräte",
               "weight": 1000,
               "range": 1
               },
             "PrivateMounts":
               {
               "description_good": "Dienst kann keine Systemeinhängungen installieren",
               "description_bad": "Dienst darf Systemeinhängungen installieren",
               "weight": 1000,
               "range": 1
               },
             "PrivateNetwork":
               {
               "description_good": "Dienst hat keinen Zugriff auf das Netzwerk des Rechners",
               "description_bad": "Dienst hat Zugriff auf das Netzwerk des Rechners",
               "weight": 2500,
               "range": 1
               },
             "PrivateTmp":
               {
               "description_good": "Dienst hat keinen Zugriff auf die temporären Dateien anderer Software",
               "description_bad": "Dienst hat Zugriff auf die temporären Dateien anderer Software",
               "weight": 1000,
               "range": 1
               },
             "PrivateUsers":
               {
               "description_good": "Dienst hat keinen Zugriff auf andere Benutzer",
               "description_bad": "Dienst hat Zugriff auf andere Benutzer",
               "weight": 1000,
               "range": 1
               }
           }

SIEHE AUCH

       systemd(1), systemctl(1)

ANMERKUNGEN

        1. Metadaten-Paketierung
           https://systemd.io/COREDUMP_PACKAGE_METADATA/

        2. Spezifikation für auffindbare Partitionen
           https://uapi-group.org/specifications/specs/discoverable_partitions_specification

Ü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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.