Systemd-analyze-beschreibung
Beschreibung
systemd-analyze kann verwendet werden, um Leistungsstatistiken beim Systemstart zu ermitteln und andere Zustands- und Ablaufverfolgungsinformationen vom System- und Dienstmanager abzurufen und die Korrektheit von Unit-Dateien zu überprüfen. Es wird auch verwendet, um auf spezielle Funktionen zuzugreifen, die für das erweiterte Systemmanager-Debugging nützlich sind.
- Wenn kein Befehl übergeben wird, wird systemd-analyze time impliziert.=
systemd-analyze time
Dieser Befehl gibt die Zeit aus, die im Kernel verbracht wurde, bevor der Userspace erreicht wurde, die Zeit, die in der initrd verbracht wurde, bevor der normale System-Userspace erreicht wurde, und die Zeit, die der normale System-Userspace zum Initialisieren benötigte. Beachten Sie, dass diese Messungen einfach die Zeit messen, die bis zu dem Punkt verstrichen ist, an dem alle Systemdienste gestartet wurden, aber nicht unbedingt bis sie die Initialisierung vollständig abgeschlossen haben oder die Festplatte im Leerlauf ist.
systemd-analyze blame
Dieser Befehl zeigt eine Liste aller laufenden Einheiten, sortiert nach der Zeit, die sie zum Initialisieren benötigt haben. Diese Informationen können verwendet werden, um die Startzeiten zu optimieren. Beachten Sie, dass die Ausgabe irreführend sein kann, da die Initialisierung eines Dienstes langsam sein kann, nur weil auf den Abschluss der Initialisierung eines anderen Dienstes gewartet wird. Beachten Sie auch: systemd-analyze-Schuld zeigt keine Ergebnisse für Dienste mit Type=simple an, da systemd solche Dienste als sofort gestartet betrachtet, daher kann keine Messung der Initialisierungsverzögerungen durchgeführt werden. Beachten Sie auch, dass dieser Befehl nur die Zeiteinheiten anzeigt, die für den Start benötigt wurden, er zeigt nicht an, wie lange Einheitsjobs in der Ausführungswarteschlange verbracht haben. Insbesondere zeigt es die Zeiteinheiten, die im "aktivierenden" Zustand verbracht wurden, was nicht für Einheiten wie Geräteeinheiten definiert ist, die direkt von "inaktiv" zu "aktiv" übergehen. Dieser Befehl vermittelt daher einen Eindruck von der Leistung des Programmcodes, kann jedoch die durch das Warten auf Hardware und ähnliche Ereignisse eingeführte Latenz nicht genau widerspiegeln.
- systemd-analyze blame
systemd-analyze critical-chain [UNIT...]
Dieser Befehl zeigt einen Baum der zeitkritischen Einheitenkette (für jede der angegebenen UNITs oder andernfalls für das Standardziel). Die Zeit, nachdem das Gerät aktiv oder gestartet wurde, wird nach dem „@“-Zeichen gedruckt. Die Zeit, die das Gerät zum Starten benötigt, wird nach dem „+“-Zeichen gedruckt. Beachten Sie, dass die Ausgabe irreführend sein kann, da die Initialisierung von Diensten von der Socket-Aktivierung und der parallelen Ausführung von Units abhängen kann. Außerdem berücksichtigt dies, ähnlich wie der Schuldzuweisungsbefehl, nur die Zeiteinheiten, die im "Aktivierungs"-Zustand verbracht wurden, und deckt daher keine Einheiten ab, die nie einen "Aktivierungs"-Zustand durchlaufen haben (z. B. Geräteeinheiten, die direkt von "inaktiv" wechseln). auf „aktiv“). Außerdem werden keine Informationen zu Jobs angezeigt (insbesondere nicht zu Jobs, die abgelaufen sind).
- systemd-analyze critical-chain
systemd-analyze dump [pattern…]
Ohne Parameter gibt dieser Befehl eine (normalerweise sehr lange) menschenlesbare Serialisierung des vollständigen Service-Manager-Zustands aus. Optional kann ein Glob-Muster angegeben werden, wodurch die Ausgabe auf Einheiten beschränkt wird, deren Namen mit einem der Muster übereinstimmen. Das Ausgabeformat kann ohne Vorankündigung geändert werden und sollte nicht von Anwendungen geparst werden.
systemd-analyze security [UNIT...]
Dieser Befehl analysiert die Sicherheits- und Sandboxing-Einstellungen einer oder mehrerer angegebener Diensteinheiten. Wenn mindestens ein Unit-Name angegeben ist, werden die Sicherheitseinstellungen der angegebenen Service-Units überprüft und eine detaillierte Analyse angezeigt. Wenn kein Unit-Name angegeben ist, werden alle aktuell geladenen Service-Units mit langer Laufzeit untersucht und eine knappe Tabelle mit Ergebnissen angezeigt. Der Befehl prüft auf verschiedene sicherheitsrelevante Diensteinstellungen und weist jeder einen numerischen „Exposure Level“-Wert zu, je nachdem, wie wichtig eine Einstellung ist. Anschließend wird ein Gesamtexpositionsniveau für die gesamte Einheit berechnet, bei dem es sich um eine Schätzung im Bereich von 0,0 bis 10,0 handelt, die angibt, wie exponiert ein Dienst sicherheitstechnisch ist. Hohe Expositionswerte weisen auf sehr wenig angewendetes Sandboxing hin. Niedrige Expositionsniveaus weisen auf strenges Sandboxing und stärkste Sicherheitsbeschränkungen hin. Beachten Sie, dass dies nur die Sicherheitsfunktionen pro Dienst analysiert, die systemd selbst implementiert. Dies bedeutet, dass zusätzliche Sicherheitsmechanismen, die durch den Dienstcode selbst angewendet werden, nicht berücksichtigt werden. Die auf diese Weise ermittelte Gefährdungsstufe sollte nicht missverstanden werden: Eine hohe Gefährdungsstufe bedeutet weder, dass kein effektives Sandboxing durch den Dienstcode selbst angewendet wird, noch dass der Dienst tatsächlich anfällig für entfernte oder lokale Angriffe ist. Hohe Expositionsniveaus weisen jedoch darauf hin, dass der Dienst höchstwahrscheinlich von zusätzlichen Einstellungen profitieren könnte, die auf sie angewendet werden.
Bitte beachten Sie, dass viele der Sicherheits- und Sandboxing-Einstellungen einzeln umgangen werden können – sofern sie nicht mit anderen kombiniert werden. Wenn ein Dienst beispielsweise das Recht behält, Einhängepunkte einzurichten oder rückgängig zu machen, können viele der Sandboxing-Optionen durch den Dienstcode selbst rückgängig gemacht werden. Aus diesem Grund ist es wichtig, dass jeder Dienst die umfassendsten und strengsten Sandboxing- und Sicherheitseinstellungen verwendet, die möglich sind. Das Tool berücksichtigt einige dieser Kombinationen und Beziehungen zwischen den Einstellungen, aber nicht alle. Beachten Sie auch, dass die hier analysierten Sicherheits- und Sandboxing-Einstellungen nur für die Vorgänge gelten, die vom Dienstcode selbst ausgeführt werden. Wenn ein Dienst Zugriff auf ein IPC-System (wie etwa D-Bus) hat, kann er Operationen von anderen Diensten anfordern, die nicht denselben Beschränkungen unterliegen. Jede umfassende Sicherheits- und Sandboxing-Analyse ist daher unvollständig, wenn die IPC-Zugriffsrichtlinie nicht ebenfalls validiert wird
Example 20. Analyze systemd-logind.service
$ 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 🙂