systemd-analyze(1)

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)EN 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:

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