Provided by: manpages-de_4.26.0-1_all 
BEZEICHNUNG
systemd-analyze - Systemverwalter analysieren und auf Fehler überprüfen
ÜBERSICHT
systemd-analyze [OPTIONEN…] [Zeit]
systemd-analyze [OPTIONEN…] blame
systemd-analyze [OPTIONEN…] critical-chain [UNIT…]
systemd-analyze [OPTIONEN…] 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… | {-m | --mask} MASKE]
systemd-analyze [OPTIONEN…] condition BEDINGUNG…
systemd-analyze [OPTIONEN…] syscall-filter [GRUPPE…]
systemd-analyze [OPTIONEN…] filesystems [GRUPPE…]
systemd-analyze [OPTIONEN…] calendar SPEZ…
systemd-analyze [OPTIONEN…] timestamp ZEITSTEMPEL…
systemd-analyze [OPTIONEN…] timespan SPANNE…
systemd-analyze [OPTIONEN…] cat-config NAME|PFAD…
systemd-analyze [OPTIONEN…] compare-versions VERSION1 [OP] VERSION2
systemd-analyze [OPTIONEN…] verify DATEI…
systemd-analyze [OPTIONEN…] security [UNIT…]
systemd-analyze [OPTIONEN…] inspect-elf DATEI…
systemd-analyze [OPTIONEN…] malloc [D-BUS-DIENST…]
systemd-analyze [OPTIONEN…] fdstore UNIT…
systemd-analyze [OPTIONEN…] image-policy RICHTLINIE…
systemd-analyze [OPTIONEN…] has-tpm2
systemd-analyze [OPTIONEN…] pcrs [PCR…]
systemd-analyze [OPTIONEN…] srk [>DATEI]
systemd-analyze [OPTIONEN…] architectures [NAME…]
systemd-analyze [OPTIONEN…] smbios11
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… | {-m | --mask} MASKE]
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.
Falls alternativ --mask angegeben ist, muss ein einzelnes, numerisches Argument angegeben werden, das als
hexadezimale Capability-Maske interpretiert wird. In diesem Fall werden in der Tabelle nur die in der
Maske vorkommenden Capabilitys angezeigt. Dieser Modus ist als Hilfe beim Dekodieren von
Capability-Gruppen gedacht, die über verschiedene Fehlersuchschnittstellen (z.B. "/proc/PID/status")
verfügbar sind.
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
Beispiel 1. Eine aus /proc extrahierte Capability-Maske dekodieren
$ systemd-analyze capability -m 0000000000003c00
NAME NUMBER
cap_net_bind_service 10
cap_net_broadcast 11
cap_net_admin 12
cap_net_raw 13
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 12. 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 13. 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 14. 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 15. 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 16. 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 17. 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. Falls eine Vorlagen-Unit ohne Instanznamen angegeben wird (z.B. foo@.service) wird
»test_instance« als Instanzenname verwandt, was über die Option --instance= gesteuert werden kann.
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 18. Falschgeschriebene Anweisungen
$ 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 19. 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 20. 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 21. 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 22. 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 23. 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 24. 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 has-tpm2
Berichtet, ob das System über ein benutzbares TPM2-Gerät verfügt. Falls ein TPM2-Gerät erkannt wurde, das
unterstützt wird und von der Firmware, den Betriebssystemkerneltreibern und durch den Anwendungsraum
(d.h. durch Systemd) unterstützt wird, dann wird »yes« ausgegeben und mit einem Exit-Status von Null
beendet. Falls kein solches Gerät erkannt/unterstützt/verwandt wird, wird »no« ausgegeben. Andernfalls
wird »partial« ausgegeben. In jedem dieser zwei Fälle wird mit einem von Null verschiedenen Exit-Status
beendet. Es werden auch fünf Zeilen angezeigt, die getrennt anzeigen, ob die Firmware, die Treiber, das
System, der Kernel und die Bibliotheken TPM2 erkennen/unterstützen/verwenden. Derzeit werden die
Bibliotheken libtss2-esys.so.0, libtss2-rc.so.0 und libtss2-mu.so benötigt.0 Diese Anforderungen können
sich in zukünftigen Veröffentlichungen ändern.
Beachten Sie, dass dies nur auf TPM 2.0-Geräte prüft und TPM 1.2 überhaupt nicht betrachtet.
Kombinieren Sie dies mit --quiet, um die Ausgabe zu unterdrücken.
Beispiel 25. Beispielausgabe
yes
+firmware
+driver
+system
+subsystem
+libraries
+libtss2-esys.so.0
+libtss2-rc.so.0
+libtss2-mu.so.0
Hinzugefügt in Version 257.
systemd-analyze pcrs [PCR…]
Dieser Befehl zeigt die bekannten TPM2-PCRs zusammen mit ihren kennzeichnenden Namen und aktuellen
Werten.
Beispiel 26. 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. Die Ausgabe sind nicht darstellbare Daten, sie sollte in eine
Datei oder eine Pipe umgeleitet werden.
Beispiel 27. Den Speicherwurzelschlüssel in srk.tpm2b_public speichern
systemd-analyze srk >srk.tpm2b_public
systemd-analyze architectures [NAME…]
Listet alle bekannten CPU-Architekturen auf und welche davon nativ sind. Die aufgeführten
Architekturnamen sind diejenigen, die ConditionArchitecture= unterstützt, siehe systemd.unit(5) zu
Details. Falls Architekturnamen angegeben werden, werden nur die angegebenen aufgeführt.
Beispiel 28. Tabellenausgabe
$ systemd-analyze architectures
NAME SUPPORT
alpha foreign
arc foreign
arc-be foreign
arm foreign
arm64 foreign
…
sparc foreign
sparc64 foreign
tilegx foreign
x86 secondary
x86-64 native
systemd-analyze smbios11
Zeigt eine Liste von SMBIOS-Typ-#11-Zeichenketten, die an das System übergeben wurden. Siehe auch
smbios-type-11(7).
Beispiel 29. Beispielausgabe
$ systemd-analyze smbios11
io.systemd.stub.kernel-cmdline-extra=console=ttyS0
io.systemd.credential.binary:ssh.ephemeral-authorized_keys-all=c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSURGd20xbFp4WlRGclJteG9ZQlozOTYzcE1uYlJCaDMwM1MxVXhLSUM2NmYgbGVubmFydEB6ZXRhCg==
io.systemd.credential:vmm.notify_socket=vsock-stream:2:254570042
3 SMBIOS Type #11 strings passed.
Hinzugefügt in Version 257.
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=, BindsTo=, 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.
--instance=NAME
Legt Rückfallinstanznamen für Vorlagen-Units fest. Dies wird verwandt, wenn eine oder mehrere
Vorlagen-Units ohne Instanzname (z.B. foo@.service) für systemd-analyze condition mit --unit=,
systemd-analyze security und systemd-analyze verify angegeben wurden. Falls nicht angegeben, wird
»test_instance« verwandt.
Hinzugefügt in Version 257.
--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 diese 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
Bei der Verwendung mit --offline= agiert mit cat-config, verify, condition und security auf Dateien
unterhalb des angegebenen Wurzelpfades PFAD.
Hinzugefügt in Version 239.
--image=PFAD
Bei der Verwendung mit --offline= agiert mit cat-config, verify, condition und security 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. Falls eine
Vorlagen-Unit ohne Instanznamen angegeben wird (z.B. foo@.service) wird »test_instance« als
Instanzenname verwandt, was über die Option --instance= gesteuert werden kann.
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-Name, abgetrennt
durch »/«, folgen, 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. Setzen 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.
-q, --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.
--scale-svg=FAKTOR
Bei der Verwendung mit dem Befehl plot kann die X-Achse der Darstellung mit dem FAKTOR gestreckt
werden (Vorgabe: 1.0).
Hinzugefügt in Version 257.
--detailed
Bei der Verwendung mit dem Befehl plot können Aktivierungszeitstempel-Details in den
SVG-Darstellungen gesehen werden.
Hinzugefügt in Version 257.
-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 true bzw. false ist.
has-tpm2 liefert 0 zurück, falls ein TPM2-Gerät erkannt wurde, von der Firmware, den Treibern und dem
Anwendungsraum (d.h. Systemd) unterstützt wird. Andernfalls werden der Wert 1 (falls die
Firmware-Unterstützung fehlt), 2 (falls die Treiberunterstützung fehlt) und 4 (falls die
Anwendungsraumunterstützung fehlt) mit ODER kombiniert und zurückgeliefert. Daher wird der Wert 7
zurückgeliefert, wenn überhaupt keine TPM2-Unterstützung verfügbar ist.
UMGEBUNGSVARIABLEN
$SYSTEMD_LOG_LEVEL
Die maximale Protokollierstufe für ausgegebene Meldungen (Meldungen mit einer höheren
Protokollierstufe, d.h. weniger wichtige, werden unterdrückt). Akzeptiert eine Kommata-getrennte
Liste von Werten. Ein Wert kann einer der folgenden sein (in Reihenfolge absteigender Bedeutung):
emerg, alert, crit, err, warning, notice, info, debug oder eine Ganzzahl im Bereich 0…7. Siehe
syslog(3) für weitere Informationen. Jedem Wert kann optional eine Zeichenkette aus console, syslog,
kmsg oder journal gefolgt von einem Doppelpunkt vorangestellt werden, um die maximale
Protokollierstufe für dieses spezielle Protokollierziel zu setzen (d.h.
SYSTEMD_LOG_LEVEL=debug,console:info legt fest, dass auf der Stufe »debug« protokolliert werden soll,
außer beim Protokollieren auf die Konsole, die auf Stufe »info« erfolgen soll). Beachten Sie, dass
die globale maximale Protokollierstufe Priorität gegenüber jeder zielbezogenen maximalen
Protokollierstufe hat.
$SYSTEMD_LOG_COLOR
Ein logischer Wert. Falls true, 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 true, 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.
$SYSTEMD_LOG_LOCATION
Ein logischer Wert. Falls true, wird den Protokollnachrichten ein Dateiname 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 true, wird den Nachrichten die aktuelle numerische Thread-Kennung (TID)
vorangestellt.
Beachten Sie, dass diese Informationen sowieso als Metadaten 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 Implementierungen
von Textanzeigeprogrammen der Reihe nach ausprobiert, einschließlich less(1) und more(1), bis eines
gefunden wird. Falls keine Implementierung eines Textanzeigeprogramms 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.
Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESS keine Auswirkungen auf die
Ausführung von less(1) durch systemd(1)-Werkzeuge hat.
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.
Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESSCHARSET keine Auswirkungen auf
die Ausführungen von less(1) durch systemd(1)-Werkzeuge hat.
$SYSTEMD_PAGERSECURE
Akzeptiert einen logischen Wert. Wenn true, wird der »sichere« Modus des Textanzeigeprogramms
verwandt, falls false, 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 Textanzeigeprogramms gesetzt und das Textanzeigeprogramm muss
Befehle deaktivieren, die neue Dateien öffnen oder erstellen oder die einen neuen Unterprozess
starten. Falls $SYSTEMD_PAGERSECURE überhaupt nicht gesetzt ist, werden Textanzeigeprogramme, 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 Textanzeigeprogramm 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
das Textanzeigeprogramm komplett mit --no-pager zu deaktivieren.
$SYSTEMD_COLORS
Akzeptiert ein logisches Argument. Wenn true, 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 30. 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 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.
systemd 257.3 SYSTEMD-ANALYZE(1)