SYSTEMD-ANALYZE(1) systemd-analyze SYSTEMD-ANALYZE(1) BEZEICHNUNG systemd-analyze - Systemverwalter analysieren und auf Fehler uberprufen UBERSICHT 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 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] 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 uberprufen. Es wird auch dazu verwandt, auf besondere Funktionen zuzugreifen, die fur fortgeschrittene Systemverwalterfehlersuche nutzlich sind. Falls kein Befehl ubergeben 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 benotigte, 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 konnen zur Optimierung der Systemstartzeit verwandt werden. Beachten Sie, dass die Ausgabe irrefuhrend 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 fur Dienste mit Type=simple an, da Systemd solche Dienste als sofort gestartet betrachtet und daher keine Messungen der Initialisierungsverzogerungen erfolgen konnen. Beachten Sie auch, dass dieser Befehl nur die Zeit anzeigt, die die Units fur das Hochfahren benotigten, er zeigt nicht an, wie lange sich die Units in der Ausfuhrungswarteschlange befanden. Insbesondere zeigt er die Zeit, die die Units im Zustand >>activating<< verbrachten; dieser Zustand ist fur Units wie Gerate-Units nicht definiert, die direkt von >>inactive<< nach >>active<< ubergehen. Dieser Befehl gibt daher den Eindruck der Leistung von Programmcode, kann aber nicht die durch das Warten auf Hardware und ahnliche 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 (fur jede der angegebenen UNITs oder andernfalls fur 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 benotigt, wird nach dem Zeichen >>+<< ausgegeben. Beachten Sie, dass die Ausgabe irrefuhrend sein kann, da die Initialisierung von Diensten abhangig von der Aktivierung eines Sockets sein kann und da die Units parallel ausgefuhrt werden. Dies berucksichtigt auch ahnlich 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 Gerate-Units, die direkt von >>inactive<< zu >>active<< ubergehen). Desweiteren zeigt es keine Informationen uber Auftrage an (und insbesondere uber Auftrage, die eine Zeituberschreitung 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 konnen optionale Glob-Muster angegeben werden, die dazu fuhren, dass die Ausgabe auf Units beschrankt wird, die auf eines der Muster passen. Das Ausgabeformat unterliegt ohne Ankundigungen Anderungen und sollte nicht durch Anwendungen ausgewertet werden. Fur 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) zuruckgeliefert) 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 fur 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 Systemstartubersicht darstellen $ systemd-analyze plot >bootup.svg $ eog bootup.svg& Beachten Sie, dass diese Darstellung auf den jungsten 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 konnten Units, die von keiner anderen Unit uber eine Abhangigkeit 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 Abhangigkeitsgraphbeschreibung 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 Abhangigkeitsbaum zu erstellen. Falls weder --order noch --require angegeben sind, wird der erstellte Graph sowohl Ordnungs- als auch Anforderungsabhangigkeiten darstellen. Optional konnen am Ende Muster-Festlegungen im Glob-Stil (z.B. *.target) angegeben werden. Eine Unit-Abhangigkeit ist im Graph enthalten, falls eines dieser Muster entweder auf den Quell- oder den Zielknoten passt. Beispiel 6. Zeichnet alle Abhangigkeiten 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 Abhangigkeiten 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 konnen. Kombinieren Sie dies mit --user, um die Liste fur die Benutzerverwalterinstanz abzufragen und --global fur die globale Konfiguration der Benutzerverwalterinstanzen. Beispiel 8. Alle Pfade fur 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 tatsachliche 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 zusatzlichen Argumente angegeben sind, werden alle bekannten Status angezeigt. Andernfalls werden nur die Definitionen fur 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) fur Details. Falls kein Argument angegeben ist, wird die vollstandige 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, konnen sich diese optional auch auf bestimmte Capabilities uber 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) fur eine Liste der verfugbaren Bedingungen und Zusicherungen. Beispiel 11. Bedingungen auswerten, die Kernelversionen prufen $ 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 fuhrt die in der angegebenen GRUPPE enthaltenen Systemaufrufe auf oder alle bekannten Gruppen, falls keine Gruppen angegeben sind. Das Argument GRUPPE muss das Prafix >>@<< enthalten. systemd-analyze filesystems [GRUPPE] Dieser Befehl fuhrt die in der angegebenen Dateisystemgruppe GRUPPE enthaltenen Dateisysteme auf oder alle bekannten Gruppen, falls keine Gruppen angegeben sind. Das Argument GRUPPE muss das Prafix >>@<< enthalten. systemd-analyze calendar AUSDRUCK Dieser Befehl wertet wiederholende Kalenderzeitereignisse aus und normiert und berechnet, wann sie das nachste Mal ablaufen. Dies akzeptiert die gleiche Eingabe wie die Einstellung OnCalendar= in systemd.timer(5) und folgt der in systemd.time(7) beschriebenen Syntax. Standardmassig wird nur der nachste Zeitpunkt angezeigt, zu dem der Kalenderausdruck ablauft; verwenden Sie --iterations=, um die angegebene Anzahl der nachsten Male anzuzeigen, zu denen der Ausdruck ablauft. Jedes Mal, wenn der Ausdruck ablauft, wird ein Zeitstempel gebildet, siehe den Unterbefehl timestamp weiter unten. Beispiel 12. Schalttage in der naheren 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 Aquivalent 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 ahnlich zu systemctl cat, agiert aber auf Konfigurationsdateien. Er kopiert den Inhalt einer Konfigurationsdatei und aller Erganzungsdateien in die Standardausgabe; dabei berucksichtigt es die normale Gruppe an Systemd-Verzeichnissen und Regeln bezuglich des Vorrangs. Jedes Argument muss entweder ein absoluter Pfad einschliesslich des Prafixes (wie /etc/systemd/logind.conf oder /usr/lib/systemd/logind.conf) oder ein Name relativ zu dem Prafix (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 ausser Kraft setzt # /etc/systemd/logind.conf.d/50-override.conf und was vom Administrator, das ausser Kraft setzt systemd-analyze compare-versions VERSION1 [OP] VERSION2 Dieser Befehl hat zwei unterschiedliche Betriebsmodi, abhangig 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) zuruckliefern, falls die Bedingung erfullt 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 ladt 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 ausser Kraft gesetzt werden, indem nach dem Dopppelpunkt ein Alias angegeben wird, ein Beispiel hierfur ist weiter unten zu finden. Der komplette Unit-Suchpfad wird durch Kombination der Verzeichnisse fur alle Befehlzeilenargumente und dem normalen Unit-Ladepfad zusammengestellt. Die Variable $SYSTEMD_UNIT_PATH wird unterstutzt 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 gegenuber den in anderen Pfaden vorgezogen. Derzeit werden die folgenden Fehler erkannt: o unbekannte Abschnitte und Anweisungen, o fehlende Abhangigkeiten, die zum Starten der ubergegebenen Unit notwendig sind, o in Documentation= aufgefuhrte Handbuchseiten, die im System nicht gefunden werden, o in ExecStart= und ahnlichen aufgefuhrte Befehle, die nicht im System gefunden wurden oder nicht ausfuhrbar 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 fur 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 pruft auf verschiedene sicherheitsbezogene Diensteeinstellungen, weist jeder einen >>Gefahrdungsstufen<<-Wert zu, abhangig davon, wie wichtig die Einstellung ist. Dann berechnet es eine Gesamtgefahrdungsstufe fur die gesamte Unit, die eine Abschatzung im Bereich 0.010.0 ist und anzeigt, wie aus Sicherheitssicht ein Dienst gefahrdet ist. Hohe Gefahrdungsstufen deuten an, dass Sandboxing nur im geringen Umfang verwandt wird. Geringe Gefahrdungsstufen deuten an, dass enges Sandboxing und starkste Sicherheitsbeschrankungen angewandt werden. Beachten Sie, dass dies nur die Sicherheitsfunktionalitaten pro Dienst analysiert, die Systemd selbst implementiert. Das bedeutet, dass samtliche zusatzlichen Sicherheitsmechanismen, die vom Dienste-Code selbst erbracht werden, nicht berucksichtigt werden. Die auf diese Art bestimmte Gefahrdungsstufe sollte nicht missverstanden werden: eine hohe Gefahrdungsstufe bedeutet weder, dass vom Dienste-Code selbst kein wirksames Sandboxing angewandt wird, noch dass der Dienst tatsachlich fur lokale Angriffe oder solche aus der Ferne verwundbar ist. Hohe Gefahrdungsstufen deuten allerdings an, dass der Dienst am wahrscheinlichsten von zusatzlichen Einstellungen fur sie Nutzen ziehen wurde. Bitte beachten Sie, dass viele der Sicherheits- und Sandboxing-Einstellungen jeweils einzeln umgangen werden konnen -- ausser sie werden mit anderen kombiniert. Falls ein Dienst beispielsweise das Privileg behalt, Einhangepunkte zu etablieren oder ruckgangig zu machen, konnen viele der Sandboxing-Optionen durch den System-Code selbst ruckgangig gemacht werden. Daher ist es wesentlich, dass jeder Dienst die umfassendsten und strengsten Sicherheits- und Sandboxing-Einstellungen, die moglich sind, verwendet. Das Werkzeug wird einige dieser Kombinationen und Beziehungen zwischen den Einstellungen berucksichtigen, aber nicht alle. Beachten Sie auch, dass die Sicherheits- und Sandboxing-Einstellungen, die hier analysiert werden, nur fur vom Dienste-Code selbst ausgefuhrte Aktionen greifen. Falls ein Dienst Zugriff auf ein IPC-System (wie D-Bus) hat, konnte er Aktionen von anderen Diensten erbitten, die nicht den gleichen Beschrankungen unterliegen. Daher ist jede umfassende Sicherheits- und Sandboxing-Analyse unvollstandig, falls die IPC-Zugriffsregeln nicht auch gegengepruft 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] fur weitere Informationen. Beispiel 21. Informationen uber 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, Geratenummern, Inode-Nummern, Pfade und Offnungsmodi der offenen Dateideskriptoren an. Die angegebenen Units mussen 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 Gerateknotens, der dem Dateisystem zu Grunde liegt, auf dem die Inode des Dateideskriptors ist. Die Spalte >>RDEVNO<< bezieht sich auf die Major-/Minor-Nummern des Gerateknotens 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 aufgefuhrten 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 gemass systemd.image-policy(7). Die Richtlinie wird normalisiert und vereinfacht. Fur jeden aktuell definierten Partitionskennzeichner (gemass der Spezifikation fur 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 Speicherwurzelschlussel (SRK) aus dem TPM2-Gerat 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. Hinzugefugt in Version 209. --user Agiert auf der Benutzer-Systemd-Instanz. Hinzugefugt in Version 186. --global Agiert auf der systemweiten Konfiguration fur Benutzer-Systemd-Instanzen. Hinzugefugt in Version 238. --order, --require Wahlt bei der Verwendung mit dem Befehl dot (siehe oben) die im Abhangigkeitsgraph zu zeigenden Abhangigkeiten aus. Falls --order ubergeben wird, werden nur Abhangigkeiten vom Typ After= oder Before= gezeigt. Falls --require ubergeben wird, werden nur Abhangigkeiten vom Typ Requires=, Requisite=, Wants= und Conflicts= gezeigt. Falls keines davon ubergeben wird, werden die Abhangigkeiten aller dieser Typen gezeigt. Hinzugefugt in Version 198. --from-pattern=, --to-pattern= Wahlt bei der Verwendung mit dem Befehl dot (siehe oben) aus, welche Beziehungen im Abhangigkeitsgraph gezeigt werden. Beide Optionen benotigen ein glob(7)-Muster als Argument, das mit den Knoten auf der rechten bzw. linken Seite einer Beziehung ubereinstimmen muss. Jeder davon kann mehr als einmal verwandt werden, dann mussen die Unit-Namen auf jeden der Werte passen. Falls Tests fur beide Seiten der Relation vorhanden sind, muss eine Relation beide Tests bestehen, um angezeigt zu werden. Wenn Muster zudem als positionsabhangige Argumente angegeben werden, mussen sie auf mindestens einer Seite der Relation passen. Mit anderen Worten, Muster, die mit diesen zwei Optionen angegeben werden, verkurzen die Liste der Kanten, auf die die positionsabhangigen Argumente passen, falls welche angegeben werden, und zeigen die komplette Liste der Kanten andernfalls. Hinzugefugt in Version 201. --fuzz=Zeitspanne Zeigt bei der Verwendung mit dem Befehl critical-chain (siehe oben) auch Units, die sich eine Zeitspanne fruher beendeten, als die letzte Unit auf der gleichen Stufe. Die Einheit von Zeitspanne ist Sekunden, ausser es wird eine andere Einheit angegeben, z.B. >>50ms<<. Hinzugefugt in Version 203. --man=no Ruft man(1) nicht auf, um die Existenz von in Documentation= aufgefuhrten Handbuchseiten zu uberprufen. Hinzugefugt in Version 235. --generators Ruft Unit-Generatoren auf, siehe systemd.generator(7). Einige Generatoren benotigen Root-Rechte. Beim Betrieb mit aktivierten Generatoren kommt es als normaler Benutzer im Allgemeinen zu einigen Warnmeldungen. Hinzugefugt in Version 235. --recursive-errors=MODUS Steuert die Uberprufung von Units und ihrere Abhangigkeiten 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 zuruckgeliefert, wenn wahrend der Uberprufung von entweder der angegebenen Unit oder einer ihrer zugeordneten Abhangigkeiten Warnungen auftreten. Mit no wird wird ein von Null verschiedener Prozess-Exit-Status zuruckgeliefert, wenn Warnungen wahrend der Uberprufung nur der angegebenen Unit auftreten. Mit one wird ein von Null verschiedener Prozess-Exit-Status zuruckgeliefert, wenn entweder bei der angegebenen Unit oder seiner direkten Abhangigkeit Warnungen auftreten Falls dies Option nicht angegegeben ist, wird Null als Exit-Status zuruckgegeben, unabhangig davon, ob wahrend der Uberprufung Warnungen auftraten oder nicht. Hinzugefugt in Version 250. --root=PFAD Agiert mit cat-files und verify auf Dateien unterhalb des angegebenen Wurzelpfades PFAD. Hinzugefugt in Version 239. --image=PFAD Agiert mit cat-files und verify auf Dateien innerhalb des angebebenen Abbildpfades PFAD. Hinzugefugt in Version 250. --image-policy=Richtlinie Akzeptiert gemass 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 Fuhrt mit security eine Offline-Sicherheitsuberprufung der angegebenen Unit-Dateien durch, d.h. verlasst sich nicht auf PID 1, um Sicherheitsinformationen fur 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 zuruckliefern. Hinzugefugt in Version 250. --profile=PFAD Berucksichtigt mit security --offline= beim Zugriff auf die Unit-Einstellungen die angegeben portablen Profile. Das Profil kann als Name ubergeben werden, wodurch die gut bekannten Systemorte durchsucht werden, oder es kann der vollstandige Pfad zu einer angegebenen Erganzungsdatei sein. Hinzugefugt in Version 250. --threshold=WERT Erlaubt mit security dem Benutzer einen angepassten Wert zu setzen, mit dem das Gesamtoffenlegungsniveau fur die angegebenen Unit-Dateien verglichen wird. Falls das Offenlegungsniveau einer Unit grosser als das vom Benutzer gesetzte ist, wird security einen Fehler zuruckliefern. --threshold= kann auch mit --offline= verwandt werden und sein Vorgabewert ist 100. Hinzugefugt 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<<. Hinzugefugt 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.010.0, wobei eine hohere Zahl einer hoheren Sicherheitsbedrohung entspricht). Die JSON-Version der Tabelle wird auf die Standardausgabe ausgegeben. Der an die Option ubergebene MODUS kann einer der drei folgenden sein: off (die Vorgabe), pretty und short, die eine verschonerte bzw. gekurzte 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, enthalt; time, dass die Zeit enthalt, die der Dienst zum Aktivieren benotigte, nachdem er anfanglich gestartet wurde; deactivated, das die Zeit nach dem Starten, die der Dienst deaktiviert war, enthalt und deactivating, das die Zeit nach dem Starten enthalt, nach der der Dienst anfanglich gebeten wurde, sich zu deaktivieren. Hinzugefugt in Version 250. --iterations=ANZAHL Zeigt bei der Verwendung zusammen mit dem Befehl calendar die angegebene Anzahl an Iterationen, zu denen die angegebenen Kalenderausdrucke das nachste Mal ablaufen. Standardmassig 1. Hinzugefugt in Version 242. --base-time=ZEITSTEMPEL Zeigt bei der Verwendung zusammen mit dem Befehl calendar die nachste Iteration relativ zum angegebenen Zeitpunkt an. Falls nicht angegeben, ist die Vorgabe die aktuelle Zeit. Hinzugefugt 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 fur die angegebene Unit mit dem normalen Unit-Ladepfad zusammengestellt. Die Variable $SYSTEMD_UNIT_PATH wird unterstutzt 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 enthalt, werden gegenuber den in anderen Pfaden vorgezogen. Hinzugefugt in Version 250. --table Bei der Verwendung mit dem Befehl plot werden die rohen Zeitdaten in einer Tabelle ausgegeben. Hinzugefugt 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. Hinzugefugt in Version 253. -H, --host= Fuhrt 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 angehangt 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 durfen mit machinectl -H RECHNER aufgezahlt werden. Stellen Sie IPv6-Adressen in Klammern. -M, --machine= Fuhrt 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 nutzlich, 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 Unterdruckt Hinweise und andere nicht wesentliche Ausgaben. Hinzugefugt 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 ubersprungen. Hinzugefugt 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 Fur die meisten Befehle wird bei Erfolg 0 zuruckgegeben, anderenfalls ein Fehlercode ungleich Null. Mit dem Unterbefehl compare-versions in der 2-Argumente-Form wird 12, 0, 11 zuruckgeliefert, falls die zweite Versionszeichenkette grosser, 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 hoheren Protokollierstufe, d.h. weniger wichtige, werden unterdruckt). Sie muss (in absteigender Reihenfolge) entweder alert, crit, err, warning, notice, info, debug oder eine Ganzzahl im Bereich 07 sein. Siehe syslog(3) fur weitere Informationen. $SYSTEMD_LOG_COLOR Ein logischer Wert. Falls wahr, werden auf das TTY geschriebene Nachrichten gemass ihrer Prioritat eingefarbt. Diese Einstellung ist nur nutzlich, falls die Nachrichten direkt auf das Terminal geschrieben werden, da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen, selbstandig Nachrichten gemass ihrer Protokollierungsstufe einfarben. $SYSTEMD_LOG_TIME Ein logischer Wert. Falls wahr, wird den Protokollnachrichten der Konsole ein Zeitstempel vorangestellt. Diese Einstellung ist nur nutzlich, falls die Nachrichten direkt auf das Terminal oder in eine Datei geschrieben werden, da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen, selbstandig Zeitstempel basierend auf ihren Metadaten den Nachrichten anhangen 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-Eintragen angehangt 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 Metadaten an Journal-Eintrage angehangt wird. Die Aufnahme direkt im Nachrichtentext kann aber trotzdem bei der Fehlersuche in Programmen praktisch sein. $SYSTEMD_LOG_TARGET Das Ziel fur Protokolliernachrichten. Entweder console (auf das angehangte TTY protokollieren), console-prefixed (auf das angehangte TTY protokollieren, aber die Protokollierstufe und >>Einrichtung<< voranstellen, siehe syslog(3)), kmsg (in den zirkularen Kernel-Protokollpuffer protokollieren), journal (in das Journal protokollieren (journal-or-kmsg (in das Journal protokollieren, falls verfugbar, 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. Standardmassig >>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 ausser Kraft. Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe wohlbekannter Implementierungen von Textanzeigeprogrammen der Reihe nach ausprobiert, einschliesslich 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 aquivalent zur Ubergabe von --no-pager. Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, dann wird $SYSTEMD_PAGER (sowie $PAGER) ohne Ruckmeldung ignoriert. $SYSTEMD_LESS Setzt die an less ubergebenen Optionen (standardmassig >>FRSXMK<<) ausser Kraft. Benutzer konnten insbesondere zwei Optionen andern 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 zuruck. Falls der Wert von $SYSTEMD_LESS kein >>K<< enthalt 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 standardmassig gesetzt, damit die Darstellung von Befehlen selbst nach dem Beenden des Textanzeigeprogramms sichtbar bleibt. Allerdings stehen dadurch einige Funktionen des Textanzeigeprogramms nicht zur Verfugung; insbesondere ist das Scrollen in der Ausgabe mit der Maus nicht moglich. Siehe less(1) fur weitere Ausfuhrungen. $SYSTEMD_LESSCHARSET Setzt den an less zu ubergebenden Zeichensatz (standardmassig >>utf-8<<, falls das aufrufende Terminal als UTF-8-kompatibel erkannt wurde) ausser Kraft. $SYSTEMD_PAGERSECURE Akzeptiert einen logischen Wert. Wenn wahr, wird der >>sichere<< Modus des Textanzeigeprogramms verwandt, falls falsch, wird dieser deaktiviert. Falls $SYSTEMD_PAGERSECURE uberhaupt nicht gesetzt ist, dann wird der sichere Modus aktiviert, falls die effektive Kennung nicht identisch zu dem Eigentumer 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 offnen oder erstellen oder die einen neuen Unterprozess starten. Falls $SYSTEMD_PAGERSECURE uberhaupt 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 erhohten Rechten ausgefuhrt werden, beispielsweise mittels sudo(8) oder pkexec(1), muss Vorsicht walten gelassen werden, um sicherzustellen, dass keine ungeplanten interaktiven Funktionalitaten aktiviert werden. Der >>sichere<< Modus fur 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 ermoglicht, beliebige Befehle auszufuhren. Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt werden muss, falls die Variablen $SYSTEMD_PAGER oder $PAGER berucksichtigt werden sollen. Es kann sinnvoll sein, stattdessen das Textanzeigeprogramm 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. Zusatzlich 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 beschranken. Dies kann festgelegt werden, um die auf $TERM und der vorliegenden Verbindung der Konsole basierende automatische Entscheidung ausser Kraft zu setzen. $SYSTEMD_URLIFY Dies muss ein logischer Wert sein. Er steuert, ob anklickbare Links fur Terminal-Emulatoren, die dies unterstutzen, erstellt werden sollen. Dies kann angegeben werden, um die Entscheidung, die systemd basierend auf $TERM und anderen Bedingungen trifft, ausser Kraft zu setzen. BEISPIELE Beispiel 25. JSON-Richtlinie Die als Pfadparameter an --security-policy= ubergebene JSON-Datei hat ein JSON-Objekt oberster Stufe, wobei die Schlussel die oben erwahnten 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 standardmassig der eingebaute Vorgabefeldwert, der der gleichen Kennung entspricht, fur 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 uber alle Einstellungen in der Unit-Datei aufsummiert, auf den Bereich 1100 normiert und dazu verwandt, die Gesamtoffenlegungsstufe der Unit zu bestimmen. Indem Benutzer diese Felder verandern konnen, gibt der >>security<<-Unterbefehl ihnen die Moglichkeit, fur sich selbst zu entscheiden, welche Kennungen wichtiger sind und daher einen grosseren Effekt auf die Offenlegungsstufe haben sollten. Ein Gewicht von >>0<< bedeutet, dass die Einstellung nicht gepruft wird. { "PrivateDevices": { "description_good": "Dienst hat keinen Zugriff auf Hardware-Gerate", "description_bad": "Dienst hat moglicherweise Zugriff auf Hardware-Gerate", "weight": 1000, "range": 1 }, "PrivateMounts": { "description_good": "Dienst kann keine Systemeinhangungen installieren", "description_bad": "Dienst darf Systemeinhangungen 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 temporaren Dateien anderer Software", "description_bad": "Dienst hat Zugriff auf die temporaren 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 fur auffindbare Partitionen https://uapi-group.org/specifications/specs/discoverable_partitions_specification UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 SYSTEMD-ANALYZE(1)