systemctl - Steuern Sie den systemd-System- und Servicemanager
SYNOPSIS
systemctl [OPTIONEN...] BEFEHL [EINHEIT...]
BESCHREIBUNG
systemctl kann verwendet werden, um den Zustand des systemd-System- und Servicemanagers zu untersuchen und zu steuern. Bitte beachten Sie [systemd]({filename}../../systemd)(1) für eine Einführung in die grundlegenden Konzepte und Funktionen, die dieses Tool verwaltet.
BEFEHLE
Die folgenden Befehle werden unterstützt:
Einheitsbefehle (Introspektion und Änderung)
list-units [MUSTER...]
Listet die Einheiten auf, die systemd derzeit im Speicher hat. Dazu gehören Einheiten, die entweder direkt oder über eine Abhängigkeit referenziert werden, Einheiten, die von Anwendungen programmatisch angepinnt werden, oder Einheiten, die in der Vergangenheit aktiv waren und fehlgeschlagen sind. Standardmäßig werden nur Einheiten angezeigt, die aktiv sind, ausstehende Jobs haben oder fehlgeschlagen sind; dies kann mit der Option --all geändert werden. Wenn ein oder mehrere Muster angegeben werden, werden nur die Einheiten angezeigt, die mit einem der Muster übereinstimmen. Die angezeigten Einheiten werden zusätzlich mit --type= und --state= gefiltert, falls diese Optionen angegeben sind.
Beachten Sie, dass dieser Befehl keine Einheitenvorlagen anzeigt, sondern nur Instanzen von Einheitenvorlagen. Einheitenvorlagen, die nicht instanziiert sind, sind nicht ausführbar und werden daher niemals in der Ausgabe dieses Befehls angezeigt. Dies bedeutet insbesondere, dass [email protected] niemals in dieser Liste angezeigt wird - es sei denn, es wird instanziiert, z. B. als _. Verwenden Sie list-unit-files (siehe unten), um installierte Einheitenvorlagendateien aufzulisten.
Erzeugt eine Ausgabe ähnlich der folgenden:
EINHEIT LADEN AKTIV STATUS BESCHREIBUNG
sys-module-fuse.device geladen aktiv eingesteckt /sys/module/fuse
-.mount geladen aktiv eingehängt Root-Mount
boot-efi.mount geladen aktiv eingehängt /boot/efi
systemd-journald.service geladen aktiv wird ausgeführt Journal-Dienst
systemd-logind.service geladen aktiv wird ausgeführt Login-Dienst
● \_ geladen fehlgeschlagen fehlgeschlagen Benutzer-Manager für UID 1000
...
systemd-tmpfiles-clean.timer geladen aktiv wartet Tägliche Bereinigung temporärer Verzeichnisse
LADEN = Gibt an, ob die Einheitsdefinition ordnungsgemäß geladen wurde.
AKTIV = Der allgemeine Aktivierungsstatus der Einheit, d. h. eine Verallgemeinerung von STATUS.
STATUS = Der detaillierte Aktivierungsstatus der Einheit, die Werte hängen vom Einheitentyp ab.
123 geladene Einheiten werden aufgelistet. Verwenden Sie --all, um auch geladene, aber inaktive Einheiten anzuzeigen.
Um alle installierten Einheitendateien anzuzeigen, verwenden Sie 'systemctl list-unit-files'.
Die Kopfzeile und die letzte Einheit eines bestimmten Typs sind unterstrichen, wenn das Terminal dies unterstützt. Ein farbiges Symbol wird neben Diensten angezeigt, die maskiert, nicht gefunden oder anderweitig fehlgeschlagen sind.
Die Spalte LOAD zeigt den Ladestatus an, welcher einer der folgenden sein kann: geladen, nicht gefunden, fehlerhafte Einstellung, Fehler, maskiert. Die Spalte AKTIV zeigt den allgemeinen Geräte-Status an, welcher einer der folgenden sein kann:
Tabelle 1. Geräte-Status AKTIV
┌──────────────┬─────────────────────────────────────┐
│ Status │ Beschreibung │
├──────────────┼─────────────────────────────────────┤
│ aktiv │ Gestartet, verbunden, eingesteckt, ...,│
│ │ abhängig vom Gerätetyp. │
├──────────────┼─────────────────────────────────────┤
│ inaktiv │ Gestoppt, getrennt, ausgesteckt, ..., │
│ │ abhängig vom Gerätetyp. │
├──────────────┼─────────────────────────────────────┤
│ fehlgeschlagen│ Ähnlich wie inaktiv, aber das Gerät │
│ │ ist in irgendeiner Weise fehlgeschlagen│
│ │ (Prozess hat einen Fehlercode bei │
│ │ Beendigung zurückgegeben, ist │
│ │ abgestürzt, eine Operation ist │
│ │ abgelaufen oder nach zu vielen │
│ │ Neustarts). │
├──────────────┼─────────────────────────────────────┤
│ aktivierend │ Übergang von inaktiv zu aktiv. │
├──────────────┼─────────────────────────────────────┤
│ deaktivierend│ Übergang von aktiv zu inaktiv. │
├──────────────┼─────────────────────────────────────┤
│ Wartung │ Gerät ist inaktiv und eine │
│ │ Wartungsoperation ist im Gange. │
├──────────────┼─────────────────────────────────────┤
│ neu ladend │ Gerät ist aktiv und lädt seine │
│ │ Konfiguration neu. │
├──────────────┼─────────────────────────────────────┤
│ aktualisierend│ Gerät ist aktiv und eine neue │
│ │ Mount wird in seinem Namespace │
│ │ aktiviert. │
└──────────────┴─────────────────────────────────────┘
Die Spalte SUB zeigt den detaillierten, einheitsspezifischen Zustand der Einheit an. Die möglichen Werte variieren je nach Einheitstyp. Die Liste der möglichen Zustände LOAD, ACTIVE und SUB ist nicht konstant, und neue systemd-Versionen können Werte hinzufügen und entfernen.
systemctl --state=help
Dieser Befehl kann verwendet werden, um die aktuelle Liste der möglichen Werte anzuzeigen.
Dies ist der Standardbefehl.
list-automounts [PATTERN...]
Listet die derzeit im Speicher befindlichen Automount-Einheiten, sortiert nach Mount-Pfad, auf. Wenn ein oder mehrere PATTERNs angegeben werden, werden nur die Automount-Einheiten angezeigt, die mit einem der Muster übereinstimmen. Die Ausgabe ähnelt:
WHAT WHERE MOUNTED IDLE TIMEOUT UNIT
/dev/sdb1 /mnt/test no 120s mnt-test.automount
binfmt_misc /proc/sys/fs/binfmt_misc yes 0 proc-sys-fs-binfmt_misc.automount
2 Automount-Einheiten aufgelistet.
Weitere Informationen finden Sie unter --show-types, --all und --state=.
Hinzugefügt in Version 252.
list-paths [PATTERN...]
Listet die derzeit im Speicher befindlichen Pfad-Einheiten, sortiert nach Pfad, auf. Wenn ein oder mehrere PATTERNs angegeben werden, werden nur die Pfad-Einheiten angezeigt, die mit einem der Muster übereinstimmen. Die Ausgabe ähnelt:
PATH CONDITION UNIT ACTIVATES
/run/systemd/ask-password DirectoryNotEmpty systemd-ask-password-plymouth.path systemd-ask-password-plymouth.service
/run/systemd/ask-password DirectoryNotEmpty systemd-ask-password-wall.path systemd-ask-password-wall.service
/var/cache/cups/org.cups.cupsd PathExists cups.path cups.service
3 Pfad-Einheiten aufgelistet.
Weitere Informationen finden Sie unter --show-types, --all und --state=.
Hinzugefügt in Version 254.
list-sockets [PATTERN...]
Listet die derzeit im Speicher befindlichen Socket-Einheiten, sortiert nach der Adresse, an der sie lauschen, auf. Wenn ein oder mehrere PATTERNs angegeben werden, werden nur die Socket-Einheiten angezeigt, die mit einem der Muster übereinstimmen. Die Ausgabe ähnelt:
LISTEN UNIT ACTIVATES
kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
/dev/rfkill systemd-rfkill.socket systemd-rfkill.service
...
5 Socket-Einheiten aufgelistet.
Hinweis: Da die Adressen Leerzeichen enthalten können, ist diese Ausgabe nicht für die programmatische Verwendung geeignet.
Weitere Informationen finden Sie unter --show-types, --all und --state=.
Hinzugefügt in Version 202.
list-timers [PATTERN...]
Listet die derzeit im Speicher befindlichen Timer-Einheiten, sortiert nach der Zeit, zu der sie als Nächstes ablaufen, auf. Wenn ein oder mehrere PATTERNs angegeben werden, werden nur die Einheiten angezeigt, die mit einem der Muster übereinstimmen. Die Ausgabe ähnelt:
NEXT LEFT LAST PASSED UNIT ACTIVATES
- - Thu 2017-02-23 13:40:29 EST 3 days ago ureadahead-stop.timer ureadahead-stop.service
Sun 2017-02-26 18:55:42 EST 1min 14s left Thu 2017-02-23 13:54:44 EST 3 days ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sun 2017-02-26 20:37:16 EST 1h 42min left Sun 2017-02-26 11:56:36 EST 6h ago apt-daily.timer apt-daily.service
Sun 2017-02-26 20:57:49 EST 2h 3min left Sun 2017-02-26 11:56:36 EST 6h ago snapd.refresh.timer snapd.refresh.service
NEXT zeigt das nächste Mal an, wann der Timer ausgeführt wird.
LEFT zeigt an, wie viel Zeit bis zum nächsten Ausführen des Timers bleibt.
LAST zeigt das letzte Mal an, wann der Timer ausgeführt wurde.
PASSED zeigt an, wie viel Zeit seit dem letzten Ausführen des Timers vergangen ist.
UNIT zeigt den Namen des Timers an.
ACTIVATES zeigt den Namen des Dienstes an, den der Timer bei Ausführung aktiviert.
Siehe auch --all und --state=.
Hinzugefügt in Version 209.
is-active PATTERN...
Prüft, ob eine der angegebenen Einheiten aktiv ist (d. h. ausgeführt wird). Gibt den Exit-Code 0 zurück, wenn
mindestens eine aktiv ist, andernfalls einen anderen Wert. Es sei denn, --quiet ist angegeben, wird der aktuelle
Einheitsstatus auch auf die Standardausgabe ausgegeben.
is-failed [PATTERN...]
Prüft, ob eine der angegebenen Einheiten sich im Status "failed" befindet. Wenn keine Einheit angegeben ist,
wird geprüft, ob es fehlgeschlagene Einheiten oder Abhängigkeitszyklen gibt, was dem Status "degraded" entspricht,
der von is-system-running zurückgegeben wird. Gibt den Exit-Code 0 zurück, wenn mindestens eine fehlgeschlagen ist,
andernfalls einen anderen Wert. Es sei denn, --quiet ist angegeben, wird der aktuelle Einheits- oder Systemstatus
auch auf die Standardausgabe ausgegeben.
Hinzugefügt in Version 197.
status [PATTERN...|PID...]
Zeigt Laufzeitstatusinformationen über das gesamte System oder über eine oder mehrere Einheiten sowie die
aktuellsten Protokolldaten aus dem Journal an. Wenn keine Positionsargumente angegeben werden und kein Einheitsfilter
mit --type=, --state= oder --failed angegeben ist, wird der Status des gesamten Systems angezeigt. Wenn
--all verwendet wird, werden alle Einheiten angezeigt. Wenn Positionsargumente angegeben werden, wird jedes
Positionsargument entweder als Einheitsname, als Glob-Muster oder als PID behandelt, um die Einheit anzuzeigen,
die diese PID enthält. Wenn --type=, --state= oder --failed verwendet werden, werden die Einheiten zusätzlich
nach TYP und AKTIVER Status gefiltert.
Diese Funktion ist dazu gedacht, menschenlesbare Ausgaben zu generieren. Wenn Sie eine für Computer auswertbare Ausgabe benötigen, verwenden Sie stattdessen show. Standardmäßig zeigt diese Funktion nur 10 Zeilen der Ausgabe an und kürzt Zeilen, um sie in das Terminalfenster zu passen. Dies kann mit --lines und --full geändert werden, siehe oben. Darüber hinaus verwenden journalctl --unit=NAME oder journalctl --user-unit=NAME einen ähnlichen Filter für Nachrichten und sind möglicherweise bequemer.
Beachten Sie, dass dieser Vorgang nur den Laufzeitstatus anzeigt, d. h. Informationen über die aktuelle Aufrufinvokation der Einheit (wenn sie ausgeführt wird) oder die letzte Aufrufinvokation (wenn sie nicht mehr ausgeführt wird und nicht aus dem Speicher freigegeben wurde). Informationen über frühere Aufrufe, Aufrufe von vorherigen Systemstarts oder frühere Aufrufe, die bereits aus dem Speicher freigegeben wurden, können über journalctl --unit= abgerufen werden.
Systemd lädt Einheiten implizit, wenn dies erforderlich ist, so dass das Ausführen von Status dazu führt, dass eine Datei geladen wird. Der Befehl ist daher nicht nützlich, um festzustellen, ob etwas bereits geladen wurde oder nicht. Die Einheiten können auch kurz nach Abschluss des Vorgangs schnell entladen werden, wenn es keinen Grund gibt, sie im Speicher zu behalten.
Beispiel 1. Beispielausgabe von systemctl status
$ systemctl status bluetooth
● bluetooth.service – Bluetooth-Dienst
Geladen: geladen (/usr/lib/systemd/system/bluetooth.service; aktiviert; Voreinstellung: aktiviert)
Aktiv: aktiv (läuft) seit Mi 2017-01-04 13:54:04 EST; 1 Woche, 0 Tage
Dokumentation: man:bluetoothd(8)
Haupt-PID: 930 (bluetoothd)
Status: „Läuft“
Aufgaben: 1
Speicher: 648,0 KB
CPU: 435 ms
CGroup: /system.slice/bluetooth.service
└─930 /usr/lib/bluetooth/bluetoothd
12. Jan 10:46:45 example.com bluetoothd[8900]: Nicht genügend freie Handles zum Registrieren des Dienstes
12. Jan 10:46:45 example.com bluetoothd[8900]: Der aktuelle Zeiten-Dienst konnte nicht registriert werden
12. Jan 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Ein-/Ausgabefehler (5)
Der Punkt („●“) verwendet in unterstützten Terminals Farben, um den Status der Einheit auf einen Blick zusammenzufassen. Zusätzlich zu seiner Farbe variiert seine Form je nach Status: „inaktiv“ oder „Wartung“ ist ein weißer Kreis („○“), „aktiv“ ist ein grüner Punkt („●“), „Deaktivierung“ ist ein weißer Punkt, „fehlerhaft“ oder „Fehler“ ist ein rotes Kreuz („ד) und „Neuladen“ oder „Aktualisieren“ ist ein grüner Pfeil im Uhrzeigersinn („↻“).
Die Zeile „Geladen:“ in der Ausgabe zeigt „geladen“ an, wenn die Einheit in den Speicher geladen wurde. Weitere mögliche Werte für „Geladen:“ sind: „Fehler“, wenn beim Laden ein Problem aufgetreten ist, „nicht gefunden“, wenn keine Einheitsdatei für diese Einheit gefunden wurde, „schlechte Einstellung“, wenn eine wesentliche Einstellungsdatei nicht geparst werden konnte, und „maskiert“, wenn die Einheitsdatei maskiert wurde. Zusammen mit der Angabe des Pfads zur Einheitsdatei zeigt diese Zeile auch den Aktivierungsstatus an. Aktivierte Einheiten sind in das Abhängigkeitsnetzwerk zwischen den Einheiten integriert und werden daher beim Booten oder über eine andere Form der Aktivierung gestartet. Weitere Informationen zu den möglichen Aktivierungsstatus, einschließlich der Definition von „maskiert“, finden Sie in der Dokumentation für den Befehl is-enabled.
Die Zeile „Aktiv:“ zeigt den aktiven Status an. Der Wert ist normalerweise „aktiv“ oder „inaktiv“. Aktiv kann je nach Einheitstyp bedeuten, gestartet, gebunden, eingesteckt usw. Die Einheit kann sich auch im Prozess der Zustandsänderung befinden und einen Status von „Aktivierung“ oder „Deaktivierung“ melden. Ein spezieller Status „fehlerhaft“ wird eingegeben, wenn der Dienst in irgendeiner Weise fehlgeschlagen ist, z. B. durch einen Absturz, ein Beenden mit einem Fehlercode oder ein Überschreiten der Zeit. Wenn der Status „fehlerhaft“ eingegeben wird, wird die Ursache zur späteren Referenz protokolliert.
show [PATTERN...|JOB...]
Zeigt die Eigenschaften einer oder mehrerer Einheiten, Aufgaben oder des Managers selbst an. Wenn kein Argument angegeben wird, werden die Eigenschaften des Managers angezeigt. Wenn ein Einheitsname angegeben wird, werden die Eigenschaften der Einheit angezeigt, und wenn eine Job-ID angegeben wird, werden die Eigenschaften der Aufgabe angezeigt. Standardmäßig werden leere Eigenschaften unterdrückt. Verwenden Sie --all, um diese ebenfalls anzuzeigen. Um bestimmte Eigenschaften anzuzeigen, verwenden Sie --property=. Dieser Befehl ist für den Fall gedacht, dass eine maschinenlesbare Ausgabe erforderlich ist. Verwenden Sie status, wenn Sie eine formatierte, für Menschen lesbare Ausgabe suchen.
Viele der von systemctl angezeigten Eigenschaften beziehen sich direkt auf die Konfigurationseinstellungen des System- und Dienstmanagers sowie seiner Unit-Dateien. Beachten Sie, dass die von dem Befehl angezeigten Eigenschaften im Allgemeinen normalisierte, niedrigere Versionen der ursprünglichen Konfigurationseinstellungen sind und zusätzlich zum Konfigurationszustand den Laufzeitstatus anzeigen. Beispielsweise umfassen die für Service-Units angezeigten Eigenschaften die aktuelle Hauptprozess-ID des Dienstes als „MainPID“ (was ein Laufzeitstatus ist), und Zeiteinstellungen werden immer als Eigenschaften mit dem Suffix „…USec“ angezeigt, auch wenn die entsprechenden Konfigurationsoptionen mit dem Suffix „…Sec“ enden, da Mikrosekunden die vom System und Dienstmanager intern verwendete, normalisierte Zeiteinheit sind.
Weitere Informationen zu vielen dieser Eigenschaften finden Sie in der Dokumentation der D-Bus-Schnittstelle, die diese Eigenschaften bereitstellt, unter org.freedesktop.systemd1(5).
cat PATTERN...
Zeigt die zugrunde liegenden Dateien einer oder mehrerer Units an. Gibt die „fragment“- und „drop-ins“-Dateien (Quelldateien) von Units aus. Jede Datei wird von einem Kommentar begleitet, der den Dateinamen enthält. Beachten Sie, dass dies die Inhalte der zugrunde liegenden Dateien auf der Festplatte anzeigt, die möglicherweise nicht mit dem Verständnis dieser Units durch den Systemmanager übereinstimmen, wenn Unit-Dateien auf der Festplatte aktualisiert wurden und seitdem nicht der Befehl daemon-reload ausgeführt wurde.
Hinzugefügt in Version 209.
help PATTERN...|PID...
Zeigt die Handbuchseiten für eine oder mehrere Units an, falls verfügbar. Wenn eine PID angegeben wird, werden die Handbuchseiten für die Unit angezeigt, zu der der Prozess gehört.
Hinzugefügt in Version 185.
list-dependencies [UNIT...]
Zeigt die von den angegebenen Units benötigten und gewünschten Units an. Dies listet rekursiv Units auf, die die Abhängigkeiten Requires=, Requisite=, Wants=, ConsistsOf=, BindsTo= und Upholds= aufweisen. Wenn keine Units angegeben werden, wird standardmäßig default.target verwendet.
Die angezeigten Units werden zusätzlich durch die Optionen --type= und --state= gefiltert, falls diese angegeben sind. Beachten Sie, dass in diesem Fall keine Baumstruktur verwendet werden kann, daher ist --plain impliziert.
Standardmäßig werden nur Target-Units rekursiv erweitert. Wenn --all übergeben wird, werden alle anderen Units ebenfalls rekursiv erweitert.
Die Optionen --reverse, --after und --before können verwendet werden, um zu ändern, welche Arten von Abhängigkeiten angezeigt werden.
Beachten Sie, dass dieser Befehl nur Units auflistet, die derzeit im Speicher des Dienstmanagers geladen sind. Insbesondere eignet sich dieser Befehl nicht, um eine umfassende Liste aller umgekehrten Abhängigkeiten einer bestimmten Unit zu erhalten, da er nicht die von derzeit nicht geladenen Units deklarierten Abhängigkeiten auflistet.
Hinzugefügt in Version 198.
start PATTERN...
Startet (aktiviert) eine oder mehrere auf der Befehlszeile angegebene Units.
Beachten Sie, dass sich Unit-Glob-Muster auf die Namen von derzeit im Speicher befindlichen Units erweitern. Units, die nicht aktiv sind und sich nicht in einem fehlgeschlagenen Zustand befinden, befinden sich normalerweise nicht im Speicher und werden daher von keinem Muster gefunden. Darüber hinaus ist der Systemd sich bei instanziierten Units oft nicht des Instanznamens bewusst, bis die Instanz gestartet wurde. Daher ist die Verwendung von Glob-Mustern mit start nur begrenzt nützlich. Außerdem werden sekundäre Aliasnamen von Units nicht berücksichtigt.
Die Option --all kann verwendet werden, um auch inaktive Einheiten zu bearbeiten, auf die von anderen
geladenen Einheiten verwiesen wird. Beachten Sie, dass dies nicht dasselbe ist wie das Bearbeiten von "allen" möglichen Einheiten, da, wie
der vorherige Absatz beschreibt, eine solche Liste nicht eindeutig definiert ist. Dennoch kann systemctl start --all GLOB nützlich sein, wenn alle Einheiten, die dem Muster entsprechen, durch ein
bestimmtes Ziel
eingebunden werden, von dem bekannt ist, dass es geladen ist.
stop PATTERN...
Stoppt (deaktiviert) eine oder mehrere auf der Kommandozeile angegebene Einheiten.
Dieser Befehl schlägt fehl, wenn die Einheit nicht vorhanden ist oder wenn das Stoppen der Einheit verhindert wird
(siehe RefuseManualStop= in systemd.unit(5)). Er schlägt nicht fehl, wenn eines der zum Stoppen der Einheit konfigurierten Befehle (ExecStop=, usw.) fehlschlägt, da der Manager die Einheit
dennoch gewaltsam beendet.
Wenn eine gestoppte Einheit weiterhin durch andere Einheiten ausgelöst werden kann, wird eine Warnung mit den
Namen der auslösenden Einheiten angezeigt. Mit --no-warn kann die Warnung unterdrückt werden.
reload PATTERN...
Fordert alle auf der Kommandozeile aufgeführten Einheiten auf, ihre Konfiguration neu zu laden. Beachten Sie, dass dies
die service-spezifische Konfiguration neu lädt, nicht die Einheit-Konfigurationsdatei von systemd. Wenn Sie möchten, dass systemd die Konfigurationsdatei einer Einheit neu lädt, verwenden Sie den
Befehl daemon-reload. Mit anderen Worten: im
Beispiel von Apache wird hier Apache's httpd.conf im Webserver neu geladen, nicht die apache.service-Systemd-Einheitendatei.
Dieser Befehl sollte nicht mit dem Befehl daemon-reload verwechselt werden.
restart PATTERN...
Stoppt und startet dann eine oder mehrere auf der Kommandozeile angegebene Einheiten. Wenn die Einheiten noch nicht ausgeführt werden, werden sie gestartet.
Beachten Sie, dass das Neustarten einer Einheit mit diesem Befehl nicht unbedingt alle Ressourcen der Einheit freigibt, bevor sie erneut gestartet wird. Beispielsweise bleibt die service-spezifische
Dateideskriptor-Speichereinrichtung (siehe FileDescriptorStoreMax= in systemd.service(5)) intakt, solange die Einheit einen ausstehenden Job hat, und wird erst dann gelöscht, wenn die Einheit
vollständig gestoppt ist und keine Jobs mehr ausstehen. Wenn beabsichtigt ist, dass auch der Dateideskriptor-Speicher während eines Neustarts geleert wird, sollte ein expliziter systemctl stop-Befehl
gefolgt von systemctl start ausgeführt werden.
try-restart PATTERN...
Stoppt und startet dann eine oder mehrere auf der Kommandozeile angegebene Einheiten, wenn die Einheiten ausgeführt werden. Dies tut nichts, wenn die Einheiten nicht ausgeführt werden.
reload-or-restart PATTERN...
Lädt eine oder mehrere Einheiten neu, wenn sie dies unterstützen. Wenn nicht, wird stattdessen gestoppt und dann gestartet. Wenn die Einheiten noch nicht ausgeführt werden, werden sie gestartet.
Dies hat eine leicht abweichende Funktionalität, wenn es in Kombination mit --marked verwendet wird, siehe
unten.
try-reload-or-restart PATTERN...
Lädt eine oder mehrere Einheiten neu, wenn sie dies unterstützen. Wenn nicht, wird stattdessen gestoppt und dann gestartet. Dies tut nichts, wenn die Einheiten nicht ausgeführt werden.
Hinzugefügt in Version 229.
isolate UNIT
Startet die angegebene Einheit und ihre Abhängigkeiten und stoppt alle anderen, es sei denn, sie haben IgnoreOnIsolate=yes (siehe systemd.unit(5)). Wenn ein Einheitenname ohne Erweiterung angegeben wird, wird eine Erweiterung von ".target" angenommen.
Dieser Befehl ist gefährlich, da er sofort Prozesse stoppen wird, die nicht in der neuen Zielumgebung aktiviert sind, möglicherweise einschließlich der grafischen Umgebung oder des Terminals, das Sie gerade verwenden.
Beachten Sie, dass diese Operation nur für Einheiten zulässig ist, bei denen AllowIsolate= aktiviert ist. Siehe systemd.unit(5) für Details.
kill PATTERN...
Sendet ein UNIX-Prozesssignal an einen oder mehrere Prozesse der Einheit. Verwenden Sie --kill-whom=, um auszuwählen, an welchen Prozess das Signal gesendet werden soll. Verwenden Sie --signal=, um das zu sendende Signal auszuwählen. Kombinieren Sie dies mit --kill-value=, um ein POSIX Realtime Signal mit einem zugehörigen Wert in die Warteschlange zu stellen.
clean PATTERN...
Entfernt die Konfiguration, den Status, den Cache, die Protokolle, die Laufzeit- oder die Dateideskriptorspeicherdaten der angegebenen Einheiten. Verwenden Sie --what=, um auszuwählen, welche Art von Ressource entfernt werden soll. Für Service-Einheiten kann dies verwendet werden, um die Verzeichnisse zu entfernen, die mit ConfigurationDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory= und RuntimeDirectory= konfiguriert sind, siehe systemd.exec(5) für Details. Es kann auch verwendet werden, um den Dateideskriptorspeicher zu löschen, wie durch FileDescriptorStoreMax= aktiviert, siehe systemd.service(5) für Details. Für Timer-Einheiten kann dies verwendet werden, um die persistenten Zeitstempeldaten zu löschen, wenn Persistent= verwendet wird und --what=state ausgewählt ist, siehe systemd.timer(5). Dieser Befehl gilt nur für Einheiten, die eine dieser Einstellungen verwenden. Wenn --what= nicht angegeben ist, werden die Cache- und Laufzeitdaten sowie der Dateideskriptorspeicher entfernt (da diese drei Arten von Ressourcen im Allgemeinen redundant sind und bei der nächsten Ausführung der Einheit neu erstellt werden können). Mehrere Werte können durch Kommas getrennt werden. Beachten Sie, dass die angegebenen Einheiten gestoppt sein müssen, um diese Operation auszuführen.
Tabelle 2. Mögliche Werte für --what=
┌─────────────────┬────────────────────────────────────┐
│ Wert │ Einheits-Einstellung │
├─────────────────┼────────────────────────────────────┤
│ "runtime" │ RuntimeDirectory= │
├─────────────────┼────────────────────────────────────┤
│ "state" │ StateDirectory= │
├─────────────────┼────────────────────────────────────┤
│ "cache" │ CacheDirectory= │
├─────────────────┼────────────────────────────────────┤
│ "logs" │ LogsDirectory= │
├─────────────────┼────────────────────────────────────┤
│ "configuration" │ ConfigurationDirectory= │
├─────────────────┼────────────────────────────────────┤
│ "fdstore" │ FileDescriptorStorePreserve= │
├─────────────────┼────────────────────────────────────┤
│ "all" │ Alle oben genannten │
├─────────────────┼────────────────────────────────────┤
│ "help" │ Zeigt die unterstützten Werte an und beendet sich. │
└─────────────────┴────────────────────────────────────┘
Hinzugefügt in Version 243.
freeze PATTERN...
Friert eine oder mehrere über die Befehlszeile angegebene Einheiten mithilfe des cgroup-Freezers ein.
Das Einfrieren der Einheit führt dazu, dass alle Prozesse innerhalb der entsprechenden cgroup der Einheit angehalten werden. Das Anhalten bedeutet, dass die Prozesse der Einheit nicht auf der CPU ausgeführt werden, bis sie wieder aufgetaut sind. Beachten Sie, dass dieser Befehl nur auf Systemen mit einer einheitlichen cgroup-Hierarchie unterstützt wird. Eine Einheit wird automatisch aufgetaut, kurz bevor ein Job für diese Einheit ausgeführt wird, z. B. bevor die Einheit gestoppt wird.
Hinzugefügt in Version 246.
thaw PATTERN...
Taut eine oder mehrere über die Befehlszeile angegebene Einheiten auf (macht sie wieder aktiv).
Dies ist die umgekehrte Operation des Befehls „freeze“ und setzt die Ausführung von Prozessen in der cgroup der Einheit fort.
Hinzugefügt in Version 246.
set-property UNIT PROPERTY=VALUE...
Setzt die angegebenen Eigenschaften einer Einheit zur Laufzeit, sofern dies unterstützt wird. Dies ermöglicht das Ändern von Konfigurationsparametereigenschaften, z. B. von Einstellungen zur Ressourcensteuerung, zur Laufzeit. Nicht alle Eigenschaften können zur Laufzeit geändert werden, aber viele Einstellungen zur Ressourcensteuerung (hauptsächlich solche in systemd.resource-control(5)) können es. Die Änderungen werden sofort angewendet und für zukünftige Starts auf der Festplatte gespeichert, es sei denn, die Option --runtime wird verwendet, in diesem Fall gelten die Einstellungen nur bis zum nächsten Neustart. Die Syntax der Eigenschaftszuweisung folgt eng der Syntax von Zuweisungen in Unit-Dateien.
Beispiel: systemctl set-property foobar.service CPUWeight=200
Wenn die angegebene Einheit inaktiv scheint, werden die Änderungen nur auf der Festplatte gespeichert, wie oben beschrieben, und sind daher wirksam, wenn die Einheit gestartet wird.
Beachten Sie, dass dieser Befehl das Ändern mehrerer Eigenschaften gleichzeitig ermöglicht, was vorzuziehen ist, anstatt sie einzeln festzulegen.
Beispiel: systemctl set-property foobar.service CPUWeight=200 MemoryMax=2G IPAccounting=yes
Wie bei den Konfigurationseinstellungen in den Unit-Dateien bewirkt das Zuweisen einer leeren Einstellung in der Regel, dass eine Eigenschaft auf ihre Standardwerte zurückgesetzt wird.
Beispiel: systemctl set-property avahi-daemon.service IPAddressDeny=
Hinzugefügt in Version 206.
bind UNIT PFAD [PFAD]
Bindet eine Datei oder ein Verzeichnis vom Host in den Mount-Namensraum der angegebenen Einheit ein. Das erste Pfadargument ist die Quelldatei oder das Quellverzeichnis auf dem Host, das zweite Pfadargument ist das Zielverzeichnis im Mount-Namensraum der Einheit. Wenn letzteres weggelassen wird, ist der Zielpfad im Mount-Namensraum der Einheit identisch mit dem Quellpfad auf dem Host. In Kombination mit der Option --read-only wird ein schreibgeschütztes Bind-Mount erstellt. In Kombination mit der Option --mkdir wird der Zielpfad erstellt, bevor das Mount angewendet wird.
Beachten Sie, dass diese Option derzeit nur für Einheiten unterstützt wird, die innerhalb eines Mount-Namensraums ausgeführt werden (z. B. mit RootImage=, PrivateMounts= usw.). Dieser Befehl unterstützt das Bind-Mounten von Verzeichnissen, regulären Dateien, Geräte-Nodes, AF_UNIX-Socket-Nodes sowie FIFOs. Das Bind-Mount ist vorübergehend und wird sofort aufgehoben, sobald der aktuelle Einheitsprozess beendet wird. Beachten Sie, dass der hier erwähnte Namensraum, in dem das Bind-Mount hinzugefügt wird, der ist, in dem der Hauptdienstprozess ausgeführt wird. Andere Prozesse (die durch ExecReload=, ExecStartPre= usw. ausgeführt werden) laufen in separaten Namensräumen.
Wenn dies vom Kernel unterstützt wird, wird jedes vorherige Mount am ausgewählten Ziel durch das neue Mount ersetzt. Wenn dies nicht unterstützt wird, wird jedes vorherige Mount überlagert, bleibt aber angeheftet und nicht zugänglich.
Hinzugefügt in Version 248.
mount-image UNIT BILD [PFAD [PARTITIONSNAME:MOUNT-OPTIONEN]]
Bindet ein Image vom Host in den Mount-Namensraum der angegebenen Einheit ein. Das erste Pfadargument ist das Quell-Image auf dem Host, das zweite Pfadargument ist das Zielverzeichnis im Mount-Namensraum der Einheit (d. h. innerhalb von RootImage=/RootDirectory=). Das folgende Argument, falls vorhanden, wird als durch einen Doppelpunkt getrenntes Tupel aus Partitionsname und durch Kommas getrennter Liste von Mount-Optionen für diese Partition interpretiert. Das Format ist das gleiche wie bei der Einstellung MountImages= in der Service-Datei. In Kombination mit der Option --read-only wird ein schreibgeschütztes Mount erstellt. In Kombination mit der Option --mkdir wird der Zielpfad erstellt, bevor das Mount angewendet wird.
Beachten Sie, dass diese Option derzeit nur für Einheiten unterstützt wird, die innerhalb eines Mount-Namensraums ausgeführt werden (d. h. mit RootImage=, PrivateMounts= usw.). Beachten Sie, dass der hier erwähnte Namensraum, in dem das Image-Mount hinzugefügt wird, der ist, in dem der Hauptdienstprozess ausgeführt wird. Beachten Sie, dass der hier erwähnte Namensraum, in dem das Bind-Mount hinzugefügt wird, der ist, in dem der Hauptdienstprozess ausgeführt wird. Andere Prozesse (die durch ExecReload=, ExecStartPre= usw. ausgeführt werden) laufen in separaten Namensräumen.
Wenn dies vom Kernel unterstützt wird, wird jede vorherige Mount-Operation am ausgewählten Ziel durch die neue Mount-Operation ersetzt. Wenn dies nicht unterstützt wird, wird jede vorherige Mount-Operation überlagert, bleibt jedoch angepinnt und ist nicht zugänglich.
Beispiel:
systemctl mount-image foo.service /tmp/img.raw /var/lib/image root:ro,nosuid
systemctl mount-image --mkdir bar.service /tmp/img.raw /var/lib/baz/img
Eingeführt in Version 248.
service-log-level SERVICE [LEVEL]
Wenn das Argument LEVEL nicht angegeben ist, wird die aktuelle Protokollebene ausgegeben, wie sie von der Service SERVICE gemeldet wird.
Wenn das optionale Argument LEVEL angegeben ist, wird die aktuelle Protokollebene des Service auf LEVEL geändert. Die Protokollebene sollte eine typische Syslog-Protokollebene sein, d. h. ein Wert im Bereich 0...7 oder eine der Zeichenketten emerg, alert, crit, err, warning, notice, info, debug; siehe syslog(3) für Details.
Der Service muss die entsprechende BusName=destination-Eigenschaft haben und auch die generische org.freedesktop.LogControl1(5)-Schnittstelle implementieren. (systemctl verwendet das generische D-Bus-Protokoll, um auf die org.freedesktop.LogControl1.LogLevel-Schnittstelle für den D-Bus-Namensraum destination zuzugreifen.)
Eingeführt in Version 247.
service-log-target SERVICE [TARGET]
Wenn das Argument TARGET nicht angegeben ist, wird das aktuelle Protokollziel ausgegeben, wie es von der Service SERVICE gemeldet wird.
Wenn das optionale Argument TARGET angegeben ist, wird das aktuelle Protokollziel des Service auf TARGET geändert. Das Protokollziel sollte eine der folgenden Zeichenketten sein: console (für die Protokollausgabe auf den Standardfehlerstrom des Dienstes), kmsg (für die Protokollausgabe an den Kernel-Protokollpuffer), journal (für die Protokollausgabe an systemd-journald.service(8) unter Verwendung des nativen Journal-Protokolls), syslog (für die Protokollausgabe an die klassische Syslog-Socket /dev/log), null (für keine Protokollausgabe) oder auto (für eine automatisch ermittelte Auswahl, typischerweise äquivalent zu console, wenn der Dienst interaktiv aufgerufen wird, und journal oder syslog andernfalls).
Für die meisten Dienste ist nur eine kleine Teilmenge der Protokollziele sinnvoll. Insbesondere sollten die meisten "normalen" Dienste nur console, journal und null implementieren. Alles andere ist nur für Low-Level-Dienste geeignet, die in einem sehr frühen Boot-Stadium aktiv sind, bevor eine ordnungsgemäße Protokollierung eingerichtet ist.
Der Service muss die entsprechende BusName=destination-Eigenschaft haben und auch die generische org.freedesktop.LogControl1(5)-Schnittstelle implementieren. (systemctl verwendet das generische D-Bus-Protokoll, um auf die org.freedesktop.LogControl1.LogLevel-Schnittstelle für den D-Bus-Namensraum destination zuzugreifen.)
Eingeführt in Version 247.
reset-failed [PATTERN...]
Setzt den Status "failed" der angegebenen Einheiten zurück, oder wenn kein Einheitenname angegeben ist, setzt es den Status aller Einheiten zurück. Wenn eine Einheit auf irgendeine Weise fehlschlägt (d. h. ein Prozess wird mit einem Fehlercode ungleich Null beendet, abnormal beendet oder überschreitet ein Zeitlimit), wird sie automatisch in den Status "failed" versetzt, und ihr Exit-Code und Status werden zur Überprüfung durch den Administrator gespeichert, bis der Dienst gestoppt/neu gestartet oder mit diesem Befehl zurückgesetzt wird.
Zusätzlich zum Zurücksetzen des Status "failed" einer Einheit werden auch verschiedene andere einheitsspezifische Eigenschaften zurückgesetzt: Der Startratenbegrenzer aller Einheitentypen wird auf Null zurückgesetzt, ebenso wie der Neustartzähler von Serviceeinheiten. Wenn also die Startbegrenzung (wie durch StartLimitIntervalSec=/StartLimitBurst= konfiguriert) einer Einheit erreicht wird und die Einheit sich weigert, erneut gestartet zu werden, verwenden Sie diesen Befehl, um sie wieder startbar zu machen.
whoami [PID...]
Gibt die Einheiten zurück, zu denen die durch die angegebenen PIDs referenzierten Prozesse gehören (eine pro Zeile). Wenn keine PID angegeben wird, wird die Einheit zurückgegeben, in der der Befehl systemctl aufgerufen wird.
Hinzugefügt in Version 254.
Befehle für Unit-Dateien
list-unit-files [PATTERN...]
Listet die auf dem System installierten Unit-Dateien zusammen mit ihrem Aktivierungsstatus (wie von is-enabled gemeldet) auf. Wenn ein oder mehrere Muster angegeben werden, werden nur Unit-Dateien angezeigt, deren Name mit einem der Muster übereinstimmt (Muster, die Unit-Dateisystempfade abgleichen, werden nicht unterstützt).
Im Gegensatz zu list-units listet dieser Befehl Vorlagen-Units zusätzlich zu explizit instanzierten Units auf.
Hinzugefügt in Version 233.
enable UNIT..., enable PATH...
Aktiviert eine oder mehrere Units oder Unit-Instanzen. Dadurch wird eine Reihe von symbolischen Links erstellt, wie sie in den Abschnitten [Install] der angegebenen Unit-Dateien codiert sind. Nachdem die symbolischen Links erstellt wurden, wird die Systemmanager-Konfiguration neu geladen (auf eine Weise, die äquivalent zu daemon-reload ist), um sicherzustellen, dass die Änderungen sofort berücksichtigt werden. Beachten Sie, dass dies nicht den Effekt hat, dass auch die aktivierten Units gestartet werden. Wenn dies gewünscht ist, kombinieren Sie diesen Befehl mit der Option --now oder rufen Sie später start mit geeigneten Argumenten auf. Beachten Sie, dass im Falle der Unit-Instanz-Aktivierung (d. h. der Aktivierung von Units in der Form _) symbolische Links mit demselben Namen wie die Instanzen im Unit-Konfigurationsverzeichnis erstellt werden. Diese verweisen jedoch auf die einzelne Vorlagen-Unit-Datei, von der sie instanziiert werden.
Dieser Befehl erwartet entweder gültige Unit-Namen (in diesem Fall werden automatisch verschiedene Unit-Dateiverzeichnisse nach Unit-Dateien mit den entsprechenden Namen durchsucht) oder absolute Pfade zu Unit-Dateien (in diesem Fall werden diese Dateien direkt gelesen). Wenn eine angegebene Unit-Datei außerhalb der üblichen Unit-Dateiverzeichnisse gefunden wird, wird ein zusätzlicher symbolischer Link erstellt, der sie in den Unit-Konfigurationspfad verlinkt, um sicherzustellen, dass sie von Befehlen wie start gefunden wird. Das Dateisystem, in dem sich die verlinkten Unit-Dateien befinden, muss beim Start von systemd zugänglich sein (z. B. ist alles unter /home/ oder /var/ nicht erlaubt, es sei denn, diese Verzeichnisse befinden sich auf dem Root-Dateisystem).
Dieser Befehl gibt die ausgeführten Dateisystemoperationen aus. Diese Ausgabe kann durch Übergabe von --quiet unterdrückt werden.
Beachten Sie, dass dieser Vorgang nur die in den Abschnitten [Install] der Unit-Dateien vorgeschlagenen symbolischen Links erstellt. Obwohl dieser Befehl der empfohlene Weg ist, um das Unit-Konfigurationsverzeichnis zu bearbeiten, kann der Administrator zusätzliche Änderungen manuell vornehmen, indem er symbolische Links unter diesem Verzeichnis platziert oder entfernt. Dies ist besonders nützlich, um Konfigurationen zu erstellen, die von der vorgeschlagenen Standardinstallation abweichen. In diesem Fall muss der Administrator sicherstellen, dass er bei Bedarf manuell daemon-reload aufruft, um sicherzustellen, dass die Änderungen berücksichtigt werden.
Wenn diese Operation auf Einheiten ohne Installationsinformationen angewendet wird, wird eine Warnung angezeigt. --no-warn kann verwendet werden, um die Warnung zu unterdrücken.
Das Aktivieren von Einheiten sollte nicht mit dem Starten (Aktivieren) von Einheiten verwechselt werden, wie es mit dem Befehl start erfolgt. Das Aktivieren und Starten von Einheiten ist orthogonal: Einheiten können aktiviert werden, ohne gestartet zu werden, und gestartet werden, ohne aktiviert zu werden. Das Aktivieren fügt die Einheit einfach an verschiedenen Stellen hinzu (z. B. so, dass die Einheit automatisch beim Booten oder beim Anschließen einer bestimmten Hardware gestartet wird). Das Starten spawnt tatsächlich den Daemon-Prozess (im Fall von Service-Einheiten) oder bindet die Socket-Verbindung (im Fall von Socket-Einheiten) und so weiter.
Abhängig davon, ob --system, --user, --runtime oder --global angegeben ist, wird die Einheit für das System, für den aufrufenden Benutzer, nur für diesen Bootvorgang des Systems oder für alle zukünftigen Anmeldungen aller Benutzer aktiviert. Beachten Sie, dass im letzten Fall keine Systemd-Daemon-Konfiguration neu geladen wird.
Die Verwendung von enable bei maskierten Einheiten wird nicht unterstützt und führt zu einem Fehler.
disable UNIT...
Deaktiviert eine oder mehrere Einheiten. Dadurch werden alle symbolischen Links zu den Einheitsdateien, die den angegebenen Einheiten entsprechen, aus dem Verzeichnis der Einheitkonfiguration entfernt und somit alle Änderungen, die mit enable oder link vorgenommen wurden, rückgängig gemacht. Beachten Sie, dass alle symbolischen Links zu übereinstimmenden Einheitsdateien entfernt werden, einschließlich manuell erstellter symbolischer Links, und nicht nur diejenigen, die tatsächlich durch enable oder link erstellt wurden. Beachten Sie, dass disable zwar die Wirkung von enable rückgängig macht, die beiden Befehle jedoch ansonsten nicht symmetrisch sind, da disable möglicherweise mehr symbolische Links entfernt, als eine vorherige enable-Aufruf derselben Einheit erstellt hat.
Dieser Befehl erwartet nur gültige Einheitennamen, er akzeptiert keine Pfade zu Einheitsdateien.
Zusätzlich zu den als Argumente angegebenen Einheiten werden alle Einheiten deaktiviert, die in der Einstellung Also= im Abschnitt [Install] der jeweiligen Einheitsdateien aufgeführt sind.
Dieser Befehl lädt die Konfiguration des Systemmanagers implizit neu, nachdem die Operation abgeschlossen wurde. Beachten Sie, dass dieser Befehl die Einheiten, die deaktiviert werden, nicht implizit stoppt. Wenn dies gewünscht ist, kombinieren Sie diesen Befehl entweder mit der Option --now oder rufen Sie den Befehl stop mit den entsprechenden Argumenten später auf.
Dieser Befehl gibt Informationen über die ausgeführten Dateisystemoperationen (symbolische Link-Entfernungen) aus. Diese Ausgabe kann durch Übergabe von --quiet unterdrückt werden.
Wenn eine Einheit deaktiviert wird, ihre auslösenden Einheiten jedoch weiterhin aktiv sind, wird eine Warnung angezeigt, die die Namen der auslösenden Einheiten enthält. --no-warn kann verwendet werden, um die Warnung zu unterdrücken.
Wenn dieser Befehl mit --user verwendet wird, können die betroffenen Einheiten möglicherweise immer noch im globalen Bereich aktiviert sein und daher auch nach einer erfolgreichen Deaktivierung im Benutzerbereich automatisch gestartet werden. In diesem Fall wird eine Warnung dazu angezeigt, die mit --no-warn unterdrückt werden kann.
Dieser Befehl berücksichtigt --system, --user, --runtime, --global und --no-warn in ähnlicher Weise wie enable.
Hinzugefügt in Version 238.
reenable UNIT...
Aktiviert eine oder mehrere Einheiten, wie auf der Befehlszeile angegeben. Dies ist eine Kombination aus disable und enable und nützlich, um die symbolischen Verknüpfungen einer Einheitendatei auf die in ihrem Abschnitt [Install] konfigurierten Standardwerte zurückzusetzen. Dieser Befehl erwartet nur einen Einheitennamen und akzeptiert keine Pfade zu Einheitendateien.
Dieser Befehl lädt nach Abschluss der Operation implizit die Systemmanager-Konfiguration neu. Beachten Sie, dass dieser Befehl die deaktivierten Einheiten nicht automatisch neu startet. Wenn dies gewünscht ist, kombinieren Sie diesen Befehl entweder mit der Option --now oder rufen Sie den Befehl try-restart mit den entsprechenden Argumenten später auf.
Hinzugefügt in Version 238.
preset UNIT...
Setzt den Aktivierungs-/Deaktivierungsstatus einer oder mehrerer auf der Befehlszeile angegebenen Einheitendateien auf die in den Preset-Richtliniendateien konfigurierten Standardwerte zurück. Dies hat die gleiche Wirkung wie disable oder enable, je nachdem, wie die Einheit in den Preset-Dateien aufgeführt ist.
Verwenden Sie --preset-mode=, um zu steuern, ob Einheiten aktiviert und deaktiviert oder nur aktiviert oder nur deaktiviert werden sollen.
Wenn die Einheit keine Installationsinformationen enthält, wird sie von diesem Befehl stillschweigend ignoriert. UNIT muss der tatsächliche Einheitensname sein, alle Aliasnamen werden stillschweigend ignoriert.
Weitere Informationen zum Format der Preset-Richtlinie finden Sie in systemd.preset(5).
Hinzugefügt in Version 238.
preset-all
Setzt alle installierten Einheitendateien auf die in der Preset-Richtliniendatei konfigurierten Standardwerte zurück (siehe oben).
Verwenden Sie --preset-mode=, um zu steuern, ob Einheiten aktiviert und deaktiviert oder nur aktiviert oder nur deaktiviert werden sollen.
Hinzugefügt in Version 215.
is-enabled UNIT...
Überprüft, ob eine der angegebenen Einheitendateien aktiviert ist (wie bei enable). Gibt einen Exit-Code von 0 zurück, wenn mindestens eine aktiviert ist, andernfalls einen Wert ungleich Null. Gibt den aktuellen Aktivierungsstatus aus (siehe Tabelle). Um diese Ausgabe zu unterdrücken, verwenden Sie --quiet. Um Installationstargets anzuzeigen, verwenden Sie --full.
Tabelle 3. is-enabled-Ausgabe
┌───────────────────┬────────────────────────────┬───────────┐
│ Name │ Beschreibung │ Exit Code │
├───────────────────┼────────────────────────────┼───────────┤
│ "enabled" │ Aktiviert über .wants/, │ │
├───────────────────┤ .requires/ oder Alias= │ │
│ "enabled-runtime" │ Symbolische Verknüpfungen │ 0 │
│ │ (dauerhaft in │ │
│ │ /etc/systemd/system/ oder │ │
│ │ vorübergehend in │ │
│ │ /run/systemd/system/). │ │
├───────────────────┼────────────────────────────┼───────────┤
│ "linked" │ Über eine oder mehrere │ │
├───────────────────┤ symbolische Verknüpfungen │ │
│ "linked-runtime" │ zur Einheitendatei │ \> 0 │
│ │ (dauerhaft in │ │
│ │ /etc/systemd/system/ oder │ │
│ │ vorübergehend in │ │
│ │ /run/systemd/system/), │ │
│ │ auch wenn sich die │ │
│ │ Einheitendatei außerhalb │ │
│ │ des Suchpfads für │ │
│ │ Einheitendateien befindet. │ │
├───────────────────┼────────────────────────────┼───────────┤
│ "alias" │ Der Name ist ein Alias │ 0 │
│ │ (symbolische Verknüpfung zu │ │
│ │ einer anderen Einheitendatei).│ │
├───────────────────┼────────────────────────────┼───────────┤
│ "masked" │ Vollständig deaktiviert, so │ │
├───────────────────┤ dass jeder Startvorgang │ │
│ "masked-runtime" │ daraus fehlschlägt │ \> 0 │
│ │ (dauerhaft in │ │
│ │ /etc/systemd/system/ oder │ │
│ │ vorübergehend in │ │
│ │ /run/systemd/systemd/). │ │
├───────────────────┼────────────────────────────┼───────────┤
│ "static" │ Die Einheitendatei ist nicht │ 0 │
│ │ aktiviert und enthält keine │ │
│ │ Bestimmungen für die │ │
│ │ Aktivierung im Abschnitt │ │
│ │ `[Install]` der │ │
│ │ Einheitendatei. │ │
├───────────────────┼────────────────────────────┼───────────┤
│ "indirect" │ Die Einheitendatei selbst ist │ 0 │
│ │ nicht aktiviert, hat aber eine│ │
│ │ nicht leere `Also=`-Einstellung│ │
│ │ im Abschnitt `[Install]` der │ │
│ │ Einheitendatei, die andere │ │
│ │ Einheitendateien auflistet, │ │
│ │ die möglicherweise aktiviert │ │
│ │ sind, oder sie hat ein Alias │ │
│ │ unter einem anderen Namen │ │
│ │ über eine symbolische │ │
│ │ Verknüpfung, die nicht in │ │
│ │ `Also=` angegeben ist. Für │ │
│ │ Template-Einheitendateien ist │ │
│ │ eine Instanz, die sich von │ │
│ │ der in `DefaultInstance=` │ │
│ │ angegebenen unterscheidet, │ │
│ │ aktiviert. │ │
├───────────────────┼────────────────────────────┼───────────┤
│ "disabled" │ Die Einheitendatei ist nicht │ \> 0 │
│ │ aktiviert, enthält aber einen │ │
│ │ Abschnitt `[Install]` mit │ │
│ │ Installationsanweisungen. │ │
├───────────────────┼────────────────────────────┼───────────┤
│ "generated" │ Die Einheitendatei wurde │ 0 │
│ │ dynamisch über ein │ │
│ │ Generator-Tool generiert. │ │
│ │ Generierte Einheitendateien │ │
│ │ sind möglicherweise nicht │ │
│ │ aktiviert, sie werden │ │
│ │ implizit durch ihren │ │
│ │ Generator aktiviert. │ │
├───────────────────┼────────────────────────────┼───────────┤
│ "transient" │ Die Einheitendatei wurde │ 0 │
│ │ dynamisch mit der │ │
│ │ Runtime-API erstellt. │ │
│ │ Transiente Einheitendateien │ │
│ │ sind möglicherweise nicht │ │
│ │ aktiviert. │ │
├───────────────────┼────────────────────────────┼───────────┤
│ "bad" │ Die Einheitendatei ist ungültig│ \> 0 │
│ │ oder ein anderer Fehler ist │ │
│ │ aufgetreten. Beachten Sie, │ │
│ │ dass `is-enabled` diesen │ │
│ │ Zustand nicht tatsächlich │ │
│ │ zurückgibt, sondern stattdessen│ │
│ │ eine Fehlermeldung ausgibt. │ │
│ │ Die Auflistung der │ │
│ │ Einheitendateien, die von │ │
│ │ `list-unit-files` ausgegeben │ │
│ │ wird, kann dies jedoch │ │
│ │ anzeigen. │ │
├───────────────────┼────────────────────────────┼───────────┤
│ "not-found" │ Die Einheitendatei existiert │ 4 │
│ │ nicht. │ │
└───────────────────┴────────────────────────────┴───────────┘
Hinzugefügt in Version 238.
mask UNIT...
Maskiert eine oder mehrere Einheiten, wie auf der Befehlszeile angegeben. Dadurch werden diese Einheitsdateien mit /dev/null verknüpft, wodurch es unmöglich wird, sie zu starten. Dies ist eine stärkere Version von "disable", da es alle Arten von Aktivierungen der Einheit verbietet, einschließlich der Aktivierung und manuellen Aktivierung. Verwenden Sie diese Option mit Vorsicht. Mit der Option --runtime kann dies nur vorübergehend bis zum nächsten Neustart des Systems erfolgen. Die Option --now kann verwendet werden, um sicherzustellen, dass die Einheiten ebenfalls gestoppt werden. Dieser Befehl erwartet nur gültige Einheitennamen, er akzeptiert keine Pfade zu Einheitsdateien.
Beachten Sie, dass dies einen symbolischen Link unter dem Namen der Einheit in /etc/systemd/system/ (falls --runtime nicht angegeben ist) oder /run/systemd/system/ (falls --runtime angegeben ist) erstellt. Wenn bereits eine übereinstimmende Einheitsdatei in diesen Verzeichnissen vorhanden ist, schlägt dieser Vorgang fehl. Dies bedeutet, dass der Vorgang hauptsächlich zum Maskieren von Einheiten nützlich ist, die vom Anbieter mitgeliefert werden (da diese in /usr/lib/systemd/system/ gespeichert sind und nicht in den oben genannten beiden Verzeichnissen), funktioniert aber normalerweise nicht für lokal erstellte Einheiten (da diese normalerweise genau in den oben genannten beiden Verzeichnissen platziert werden). Ähnliche Einschränkungen gelten für den --user-Modus, in dem die Verzeichnisse jedoch unterhalb des Home-Verzeichnisses des Benutzers liegen.
Wenn eine Einheit maskiert wird, aber ihre auslösenden Einheiten noch aktiv sind, wird eine Warnung angezeigt, die die Namen der auslösenden Einheiten enthält. Mit --no-warn kann diese Warnung unterdrückt werden.
Hinzugefügt in Version 238.
unmask UNIT...
Hebt die Maskierung einer oder mehrerer Einheitsdateien auf, wie auf der Befehlszeile angegeben. Dadurch wird die Wirkung von "mask" rückgängig gemacht. Dieser Befehl erwartet nur gültige Einheitennamen, er akzeptiert keine Pfade zu Einheitsdateien.
Hinzugefügt in Version 238.
link PATH...
Verknüpft eine Einheitsdatei, die sich nicht im Pfad der Einheitsdatei befindet, mit dem Pfad der Einheitsdatei. Dieser Befehl erwartet einen absoluten Pfad zu einer Einheitsdatei. Die Wirkung dieses Befehls kann mit "disable" aufgehoben werden. Die Wirkung dieses Befehls besteht darin, dass eine Einheitsdatei für Befehle wie "start" verfügbar gemacht wird, auch wenn sie nicht direkt im Suchpfad der Einheit installiert ist. Das Dateisystem, in dem sich die verknüpften Einheitsdateien befinden, muss beim Start von systemd zugänglich sein (z. B. ist alles unterhalb von /home/ oder /var/ nicht zulässig, es sei denn, diese Verzeichnisse befinden sich auf dem Root-Dateisystem).
Hinzugefügt in Version 233.
revert UNIT...
Stellt eine oder mehrere Einheitendateien auf ihre vom Hersteller bereitgestellten Versionen zurück. Dieser Befehl entfernt alle Konfigurationsdateien, die die angegebenen Einheiten modifizieren, sowie alle benutzerkonfigurierten Einheitendateien, die eine übereinstimmende vom Hersteller bereitgestellte Einheitendatei überschreiben. Insbesondere wird für eine Einheit „foo.service“ das übereinstimmende Verzeichnis „foo.service.d/“ mit allen darin enthaltenen Dateien sowohl unterhalb der persistenten als auch der Laufzeitkonfigurationsverzeichnisse entfernt (d. h. unterhalb von /etc/systemd/system und /run/systemd/system). Wenn die Einheitendatei eine vom Hersteller bereitgestellte Version hat (d. h. eine Einheitendatei, die sich unterhalb von /usr/ befindet), werden alle übereinstimmenden persistenten oder Laufzeit-Einheitendateien, die diese überschreiben, ebenfalls entfernt. Beachten Sie, dass wenn eine Einheitendatei keine vom Hersteller bereitgestellte Version hat (d. h. nur unterhalb von /etc/systemd/system oder /run/systemd/system definiert ist, aber nicht in einer Einheitendatei, die sich unterhalb von /usr/ befindet), diese nicht entfernt wird. Wenn eine Einheit maskiert ist, wird sie auch nicht mehr maskiert.
Dieser Befehl kann verwendet werden, um alle Änderungen, die mit systemctl edit, systemctl set-property und systemctl mask vorgenommen wurden, rückgängig zu machen und die ursprüngliche Einheitendatei mit ihren Einstellungen wiederherzustellen.
Hinzugefügt in Version 230.
add-wants TARGET UNIT..., add-requires TARGET UNIT...
Fügt die Abhängigkeiten „Wants=" oder „Requires=" für eine oder mehrere Einheiten für das angegebene TARGET hinzu.
Dieser Befehl berücksichtigt --system, --user, --runtime und --global auf ähnliche Weise wie enable.
Hinzugefügt in Version 217.
edit UNIT...
Bearbeitet oder ersetzt ein Drop-in-Snippet oder die Haupt-Einheitendatei, um die Definition der angegebenen Einheit zu erweitern oder zu überschreiben.
Je nachdem, ob --system (Standard), --user oder --global angegeben ist, wird dieser Befehl auf die Systemeinheitendateien, die Einheitendateien für den aufrufenden Benutzer oder die Einheitendateien, die allen Benutzern gemeinsam sind, angewendet.
Der Editor (siehe Abschnitt „Umgebung“ unten) wird in temporären Dateien aufgerufen, die geschrieben werden, wenn der Editor erfolgreich beendet wird. Nach der Bearbeitung wird die Konfiguration neu geladen, was dem Befehl systemctl daemon-reload --system oder systemctl daemon-reload --user entspricht. Für edit --global wird die Neuladung nicht durchgeführt, und die Änderungen werden erst nachfolgenden Anmeldungen (oder nachdem eine Neuladung auf andere Weise angefordert wurde) wirksam.
Wenn --full angegeben ist, wird eine Ersetzung für die Haupt-Einheitendatei erstellt oder bearbeitet. Andernfalls wird eine Drop-in-Datei erstellt oder bearbeitet.
Wenn --drop-in= angegeben ist, wird der angegebene Drop-in-Dateiname anstelle der Standard-Override.conf verwendet.
Die Einheit muss vorhanden sein, d. h. ihre Haupt-Einheitendatei muss vorhanden sein. Wenn --force angegeben ist, wird diese Anforderung ignoriert, und eine neue Einheit kann erstellt werden (mit --full), oder ein Drop-in für eine nicht vorhandene Einheit kann erstellt werden.
Wenn --runtime angegeben ist, werden die Änderungen vorübergehend in /run/ vorgenommen und beim nächsten Neustart verworfen.
Wenn --stdin angegeben ist, werden die neuen Inhalte von der Standardeingabe gelesen. In diesem Modus werden die alten Inhalte der Datei verworfen.
Wenn die temporäre Datei beim Beenden leer ist, wird die Änderung der zugehörigen Einheit abgebrochen.
Beachten Sie, dass dieser Befehl nicht zum Remote-Bearbeiten von Einheiten verwendet werden kann und Sie Einheiten in /etc/ nicht temporär bearbeiten können, da diese Vorrang vor /run/ haben.
Hinzugefügt in Version 218.
get-default
Gibt das Standardziel für den Bootvorgang zurück. Dies gibt den Namen der Zieleinheit zurück, auf die default.target verlinkt ist.
Hinzugefügt in Version 205.
set-default TARGET
Setzt das Standardziel für den Bootvorgang. Dies setzt (erstellt einen symbolischen Link) für den Alias default.target auf die angegebene Zieleinheit.
Hinzugefügt in Version 205.
Befehle für Maschinen
list-machines [MUSTER...]
Listet den Host und alle ausgeführten lokalen Container mit ihrem Status auf. Wenn ein oder mehrere Muster angegeben werden, werden nur die Container angezeigt, die einem der Muster entsprechen.
Hinzugefügt in Version 212.
Befehle für Jobs
list-jobs [MUSTER...]
Listet Jobs auf, die gerade ausgeführt werden. Wenn ein oder mehrere Muster angegeben werden, werden nur Jobs für Einheiten angezeigt, die einem der Muster entsprechen.
In Kombination mit --after oder --before wird die Liste um Informationen erweitert, auf welche andere Jobs ein Job wartet und von welchen anderen Jobs auf ihn gewartet wird, siehe oben.
Hinzugefügt in Version 233.
cancel [JOB...]
Bricht einen oder mehrere Jobs ab, die über ihre numerischen Job-IDs auf der Befehlszeile angegeben sind. Wenn keine Job-ID angegeben ist, werden alle ausstehenden Jobs abgebrochen.
Hinzugefügt in Version 233.
Befehle für Umgebung
systemd unterstützt einen Umgebungsteil, der an die vom Manager gestarteten Prozesse übergeben wird. Die Namen der Variablen können ASCII-Buchstaben, Ziffern und das Unterstrichzeichen enthalten. Variablennamen dürfen nicht leer sein oder mit einer Ziffer beginnen. In Variablenwerten sind die meisten Zeichen zulässig, aber die gesamte Sequenz muss eine gültige UTF-8-Kodierung aufweisen. (Beachten Sie, dass Steuerzeichen wie Zeilenumbruch (NL), Tabulator (TAB) oder das Escape-Zeichen (ESC) gültige ASCII-Zeichen und somit gültige UTF-8-Zeichen sind). Die Gesamtlänge des Umgebungsteils ist auf den Wert _SC_ARG_MAX beschränkt, der von sysconf(3) definiert wird.
show-environment
Gibt den Umgebungsteil des systemd-Managers aus. Dies ist der Umgebungsteil, der an alle vom Manager gestarteten Prozesse übergeben wird. Der Umgebungsteil wird in einer einfachen Form ausgegeben, die zum Einfügen in die meisten Shells geeignet ist. Wenn keine Sonderzeichen oder Leerzeichen in den Variablenwerten vorhanden sind, wird keine Maskierung durchgeführt, und die Zuweisungen haben die Form "VARIABLE=value". Wenn Leerzeichen oder Zeichen vorhanden sind, die eine spezielle Bedeutung für die Shell haben, wird die Dollar-Single-Quote-Maskierung verwendet, und die Zuweisungen haben die Form "VARIABLE=$'value'". Diese Syntax wird von bash(1), zsh(1), ksh(1) und busybox(1)'s ash(1) unterstützt, aber nicht von dash(1) oder fish(1).
Hinweis: Dies zeigt den effektiven Block, d. h. die Kombination der Umgebungsvariablen, die über Konfigurationsdateien, Umgebungsvariablengeneratoren und über IPC (d. h. über das unten beschriebene
^ et-environment) konfiguriert wurden. Zum Zeitpunkt, an dem ein Unit-Prozess abzweigt, wird dieser kombinierte Umgebungsvariablenblock weiter mit Unit-spezifischen Umgebungsvariablen kombiniert, die in
diesem Befehl nicht sichtbar sind.
set-environment VARIABLE=VALUE...
Setzt eine oder mehrere Umgebungsvariablen des Service-Managers, wie in der Befehlszeile angegeben. Dieser Befehl schlägt fehl, wenn die Variablennamen und -werte nicht den oben aufgeführten Regeln entsprechen.
Hinweis: Dies wirkt sich auf einen Umgebungsvariablenblock aus, der von dem Umgebungsvariablenblock getrennt ist, der aus der Service-Manager-Konfiguration und den Umgebungsvariablengeneratoren konfiguriert
wurde. Wann immer ein Prozess aufgerufen wird, werden die beiden Blöcke kombiniert (zusammen mit allen dienstspezifischen Umgebungsvariablen) und ihm übergeben. Der Befehl show-environment zeigt die
Kombination der Blöcke an, siehe oben.
Eingeführt in Version 233.
unset-environment VARIABLE...
Entfernt eine oder mehrere Systemd-Manager-Umgebungsvariablen. Wenn nur ein Variablenname angegeben wird, wird er unabhängig von seinem Wert entfernt. Wenn eine Variable und ein Wert angegeben werden, wird die Variable nur dann entfernt, wenn sie den angegebenen Wert hat.
Hinweis: Dies wirkt sich auf einen Umgebungsvariablenblock aus, der von dem Umgebungsvariablenblock getrennt ist, der aus der Service-Manager-Konfiguration und den Umgebungsvariablengeneratoren konfiguriert
wurde. Wann immer ein Prozess aufgerufen wird, werden die beiden Blöcke kombiniert (zusammen mit allen dienstspezifischen Umgebungsvariablen) und ihm übergeben. Der Befehl show-environment zeigt die
Kombination der Blöcke an, siehe oben. Beachten Sie, dass dies bedeutet, dass dieser Befehl nicht verwendet werden kann, um Umgebungsvariablen zu entfernen, die in den Konfigurationsdateien des
Service-Managers oder über Generatoren definiert sind.
Eingeführt in Version 233.
import-environment VARIABLE...
Importiert alle oder eine oder mehrere Umgebungsvariablen, die auf dem Client im Systemd-Manager-Umgebungsvariablenblock festgelegt sind. Wenn eine Liste von Umgebungsvariablennamen übergeben wird, werden
die Client-seitigen Werte dann in den Manager-Umgebungsvariablenblock importiert. Wenn einige der Namen keine gültigen Umgebungsvariablennamen sind oder ungültige Werte gemäß den oben beschriebenen Regeln
haben, wird ein Fehler ausgelöst. Wenn keine Argumente übergeben werden, wird der gesamte Umgebungsvariablenblock, der vom systemctl-Prozess übernommen wurde, importiert. In diesem Modus werden alle
ungültigen Umgebungsvariablen, die übernommen wurden, stillschweigend ignoriert.
Das Importieren des vollständigen übernommenen Umgebungsvariablenblocks (Aufrufen dieses Befehls ohne Argumente) ist veraltet. Eine Shell setzt Dutzende von Variablen, die nur lokal sinnvoll sind und nur für Prozesse bestimmt sind, die Nachkommen der Shell sind. Solche Variablen im globalen Umgebungsvariablenblock sind für andere Prozesse verwirrend.
Eingeführt in Version 209.
Befehle für den Manager-Status
daemon-reload
Lädt die Systemd-Manager-Konfiguration neu. Dadurch werden alle Generatoren (siehe systemd.generator(7)) erneut ausgeführt, alle Unit-Dateien neu geladen und der gesamte Abhängigkeitsbaum neu erstellt.
Während der Daemon neu geladen wird, bleiben alle Sockets, auf die Systemd im Namen der Benutzerkonfiguration hört, zugänglich.
Dieser Befehl sollte nicht mit dem Befehl reload verwechselt werden.
daemon-reexec
Führt den systemd-Manager erneut aus. Dies serialisiert den Manager-Zustand, führt den Prozess erneut aus und deserialisiert dann den Zustand. Dieser Befehl ist nur für Debugging und Paketaktualisierungen nützlich. Manchmal kann er als eine Art schwergewichtiger daemon-reload hilfreich sein. Während der Manager neu ausgeführt wird, bleiben alle Sockets, auf die systemd im Namen der Benutzerkonfiguration hört, zugänglich.
log-level [LEVEL]
Wenn kein Argument angegeben wird, wird das aktuelle Protokollierungsniveau des Managers ausgegeben. Wenn ein optionales Argument LEVEL angegeben wird, ändert der Befehl das aktuelle Protokollierungsniveau des Managers auf LEVEL (akzeptiert die gleichen Werte wie --log-level=, beschrieben in systemd(1)).
Hinzugefügt in Version 244.
log-target [TARGET]
Wenn kein Argument angegeben wird, wird das aktuelle Protokollierungsziel des Managers ausgegeben. Wenn ein optionales Argument TARGET angegeben wird, ändert der Befehl das aktuelle Protokollierungsziel des Managers auf TARGET (akzeptiert die gleichen Werte wie --log-target=, beschrieben in systemd(1)).
Hinzugefügt in Version 244.
service-watchdogs [yes|no]
Wenn kein Argument angegeben wird, wird der aktuelle Status der Service-Runtime-Watchdogs des Managers ausgegeben. Wenn ein optionales boolesches Argument angegeben wird, werden die Service-Runtime-Watchdogs (WatchdogSec=) und die Notfallmaßnahmen (z. B. OnFailure= oder StartLimitAction=) global aktiviert oder deaktiviert; siehe systemd.service(5). Der Hardware-Watchdog wird von dieser Einstellung nicht beeinflusst.
Hinzugefügt in Version 244.
Systembefehle
is-system-running
Überprüft, ob das System betriebsbereit ist. Dies gibt Erfolg (Exit-Code 0) zurück, wenn das System vollständig betriebsbereit ist, d. h. nicht im Start-, Herunterfahr- oder Wartungsmodus und ohne fehlgeschlagene Dienste. Andernfalls wird ein Fehler zurückgegeben (Exit-Code ungleich Null). Darüber hinaus wird der aktuelle Status in einer kurzen Zeichenfolge auf der Standardausgabe ausgegeben, siehe die folgende Tabelle. Verwenden Sie --quiet, um diese Ausgabe zu unterdrücken.
Verwenden Sie --wait, um zu warten, bis der Startvorgang abgeschlossen ist, bevor der aktuelle Status ausgegeben und der entsprechende Fehlerstatus zurückgegeben wird. Wenn --wait verwendet wird, werden die Statuswerte "initializing" oder "starting" nicht gemeldet, stattdessen blockiert der Befehl, bis ein späterer Status (z. B. "running" oder "degraded") erreicht ist.
Tabelle 4. is-system-running-Ausgabe
┌──────────────┬────────────────────────────┬───────────┐
│ Name │ Beschreibung │ Exit Code │
├──────────────┼────────────────────────────┼───────────┤
│ initializing │ Früher Start, bevor │ \> 0 │
│ │ basic.target erreicht wird oder │ │
│ │ der Wartungszustand │ │
│ │ eintritt. │ │
├──────────────┼────────────────────────────┼───────────┤
│ starting │ Später Start, bevor die │ \> 0 │
│ │ Warteschlange zum ersten Mal │ │
│ │ inaktiv wird, oder eines der │ │
│ │ Rettungsziele erreicht wird. │ │
├──────────────┼────────────────────────────┼───────────┤
│ running │ Das System ist vollständig │ 0 │
│ │ betriebsbereit. │ │
├──────────────┼────────────────────────────┼───────────┤
│ degraded │ Das System ist betriebsbereit │ \> 0 │
│ │ aber eine oder mehrere Einheiten │ │
│ │ sind fehlgeschlagen. │ │
├──────────────┼────────────────────────────┼───────────┤
│ maintenance │ Das Rettungs- oder Notfallziel │ \> 0 │
│ │ ist aktiv. │ │
├──────────────┼────────────────────────────┼───────────┤
│ stopping │ Der Manager fährt herunter. │ \> 0 │
│ │ │ │
├──────────────┼────────────────────────────┼───────────┤
│ offline │ Der Manager ist nicht │ \> 0 │
│ │ aktiv. Insbesondere ist dies der │ │
│ │ Betriebszustand, wenn ein │ │
│ │ inkompatibles Programm als │ │
│ │ Systemmanager (PID 1) ausgeführt wird. │ │
├──────────────┼────────────────────────────┼───────────┤
│ unknown │ Der Betriebszustand │ \> 0 │
│ │ konnte nicht ermittelt werden, │ │
│ │ aufgrund mangelnder Ressourcen │ │
│ │ oder einer anderen Ursache. │ │
└──────────────┴────────────────────────────┴───────────┘
Hinzugefügt in Version 215.
default
Wechseln Sie in den Standardmodus. Dies entspricht systemctl isolate default.target. Diese Operation ist standardmäßig blockierend. Verwenden Sie --no-block, um asynchrones Verhalten anzufordern.
rescue
Wechseln Sie in den Rettungsmodus. Dies entspricht systemctl isolate rescue.target. Diese Operation ist standardmäßig blockierend. Verwenden Sie --no-block, um asynchrones Verhalten anzufordern.
emergency
Wechseln Sie in den Notfallmodus. Dies entspricht systemctl isolate emergency.target. Diese Operation ist standardmäßig blockierend. Verwenden Sie --no-block, um asynchrones Verhalten anzufordern.
halt
Fahren Sie das System herunter und stoppen Sie es. Dies entspricht größtenteils systemctl start halt.target --job-mode=replace-irreversibly --no-block, sendet aber auch eine Warnmeldung an alle Benutzer. Dieser Befehl ist asynchron; er wird zurückgegeben, nachdem die Halteoperation in die Warteschlange gestellt wurde, ohne darauf zu warten, dass sie abgeschlossen ist. Beachten Sie, dass diese Operation den Betriebssystemkernel nach dem Herunterfahren einfach stoppen und die Hardware eingeschaltet lässt. Verwenden Sie systemctl poweroff, um das System auszuschalten (siehe unten).
Wenn es mit --force kombiniert wird, wird das Herunterfahren aller ausgeführten Dienste übersprungen, jedoch werden alle Prozesse beendet und alle Dateisysteme werden sofort ausgehängt oder im Nur-Lese-Modus eingebunden, gefolgt vom Systemstopp. Wenn --force zweimal angegeben wird, wird die Operation sofort ausgeführt, ohne Prozesse zu beenden oder Dateisysteme auszuhängen. Dies kann zu Datenverlust führen. Beachten Sie, dass, wenn --force zweimal angegeben wird, die Halteoperation von systemctl selbst ausgeführt wird, und der Systemmanager nicht kontaktiert wird. Dies bedeutet, dass der Befehl auch dann erfolgreich sein sollte, wenn der Systemmanager abgestürzt ist.
Wenn es mit --when= kombiniert wird, wird das Herunterfahren nach dem angegebenen Zeitstempel geplant. Und --when=cancel bricht das Herunterfahren ab.
poweroff
Fahren Sie das System herunter und schalten Sie es aus. Dies entspricht größtenteils systemctl start poweroff.target --job-mode=replace-irreversibly --no-block, sendet aber auch eine Warnmeldung an alle Benutzer. Dieser Befehl ist asynchron; er wird zurückgegeben, nachdem die Ausschaltoperation in die Warteschlange gestellt wurde, ohne darauf zu warten, dass sie abgeschlossen ist.
Dieser Befehl berücksichtigt --force und --when= in ähnlicher Weise wie halt.
reboot
Fahren Sie das System herunter und starten Sie es neu.
Dieser Befehl entspricht größtenteils systemctl start reboot.target --job-mode=replace-irreversibly --no-block, sendet aber auch eine Warnmeldung an alle Benutzer. Dieser Befehl ist asynchron; er wird zurückgegeben, nachdem die Neustartoperation in die Warteschlange gestellt wurde, ohne darauf zu warten, dass sie abgeschlossen ist.
Wenn der Schalter --reboot-argument= angegeben wird, wird dieser als optionales Argument an den reboot(2)-Systemaufruf übergeben.
Die Optionen --boot-loader-entry=, --boot-loader-menu= und --firmware-setup können verwendet werden, um auszuwählen, was nach dem Neustart geschehen soll. Weitere Informationen finden Sie in den Beschreibungen dieser Optionen.
Dieser Befehl berücksichtigt --force und --when= in ähnlicher Weise wie halt.
Wenn ein neues Kernel über kexec --load geladen wurde, wird anstelle eines Neustarts ein kexec durchgeführt, es sei denn, SYSTEMCTL_SKIP_AUTO_KEXEC=1 ist gesetzt. Wenn ein neues Root-Dateisystem in /run/nextroot/ eingerichtet wurde, wird anstelle eines Neustarts ein Soft-Neustart durchgeführt, es sei denn, SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1 ist gesetzt.
Hinzugefügt in Version 246.
kexec
Fährt das System herunter und startet es über kexec neu. Dieser Befehl lädt einen kexec-Kernel, falls noch keiner geladen wurde, oder schlägt fehl. Ein Kernel kann auch in einem separaten Schritt vorab geladen werden, was besonders nützlich ist, wenn ein benutzerdefiniertes Initrd oder zusätzliche Kernel-Befehlszeilenoptionen gewünscht werden. Mit --force kann fortgesetzt werden, ohne einen kexec-Kernel zu verwenden, d. h. um einen normalen Neustart durchzuführen. Der letzte Neustartschritt entspricht systemctl start kexec.target --job-mode=replace-irreversibly --no-block.
Um einen Kernel zu laden, wird eine Enumeration gemäß der UAPI.1 Boot Loader Specification[1] durchgeführt, und der Standard-Boot-Eintrag wird geladen. Damit dieser Schritt erfolgreich ist, muss das System UEFI verwenden und die Boot-Loader-Einträge müssen entsprechend konfiguriert sein. bootctl list kann verwendet werden, um Boot-Einträge aufzulisten, siehe bootctl(1).
Dieser Befehl ist asynchron; er gibt zurück, nachdem die Neustartoperation in die Warteschlange gestellt wurde, ohne auf deren Abschluss zu warten.
Dieser Befehl berücksichtigt --force und --when= ähnlich wie halt.
Wenn ein neuer Kernel über kexec --load geladen wurde, wird bei der Ausführung von reboot ein kexec durchgeführt, es sei denn, SYSTEMCTL_SKIP_AUTO_KEXEC=1 ist gesetzt.
soft-reboot
Fährt den Benutzermodus herunter und startet ihn neu. Dies entspricht systemctl start soft-reboot.target --job-mode=replace-irreversibly --no-block. Dieser Befehl ist asynchron; er gibt zurück, nachdem die Neustartoperation in die Warteschlange gestellt wurde, ohne auf deren Abschluss zu warten.
Dieser Befehl berücksichtigt --force und --when= auf ähnliche Weise wie halt.
Diese Operation startet nur den Benutzermodus neu und lässt den Kernel laufen. Siehe systemd-softreboot.service(8) für Details.
Wenn ein neues Root-Dateisystem in /run/nextroot/ eingerichtet wurde, wird bei der Ausführung von reboot ein Soft-Neustart durchgeführt, es sei denn, SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1 ist gesetzt.
Hinzugefügt in Version 254.
exit [EXIT_CODE]
Fordert den Dienstmanager auf, zu beenden. Dies wird nur für Benutzerdienstmanager (d. h. in Verbindung mit der Option --user) oder in Containern unterstützt und entspricht ansonsten poweroff. Dieser Befehl ist asynchron; er gibt zurück, nachdem die Beendigungsoperation in die Warteschlange gestellt wurde, ohne auf deren Abschluss zu warten.
Der Dienstmanager wird mit dem angegebenen Exit-Code beendet, wenn EXIT_CODE übergeben wird.
Hinzugefügt in Version 227.
switch-root [ROOT [INIT]]
Wechselt zu einem anderen Root-Verzeichnis und führt einen neuen Systemmanager-Prozess darunter aus. Dies ist für die Verwendung im Initrd vorgesehen und führt einen Übergang vom Systemmanager-Prozess des Initrd (auch bekannt als "Init"-Prozess, PID 1) zum Hauptsystemmanager-Prozess über, der aus dem eigentlichen Host-Root-Dateisystem geladen wird. Dieser Aufruf benötigt zwei Argumente: das Verzeichnis, das zum neuen Root-Verzeichnis werden soll, und den Pfad zur neuen Systemmanager-Binärdatei, die darunter als PID 1 ausgeführt werden soll. Wenn beide Argumente weggelassen werden oder das erste ein leerer String ist, wird standardmäßig /sysroot/ verwendet. Wenn das zweite Argument weggelassen wird oder ein leerer String ist, wird automatisch eine Systemd-Binärdatei gesucht und als Systemmanager verwendet. Wenn der Pfad zum Systemmanager weggelassen, leer ist oder identisch mit dem Pfad zur Systemd-Binärdatei ist, wird der Zustand des Systemmanager-Prozesses des Initrd an den Hauptsystemmanager übergeben, was eine spätere Introspektion des Zustands der Dienste ermöglicht, die an der Initrd-Boot-Phase beteiligt sind.
Hinzugefügt in Version 209.
sleep
Versetzt das System in den Ruhezustand über Suspend, Hibernate, Hybrid-Sleep oder Suspend-then-Hibernate. Der zu verwendende Schlafmodus wird automatisch von systemd-logind.service(8) ausgewählt. Standardmäßig wird Suspend-then-Hibernate verwendet und bei Nichtunterstützung auf Suspend und dann Hibernate zurückgegriffen. Weitere Informationen finden Sie in der Einstellung SleepOperation= in logind.conf(5). Dieser Befehl ist asynchron und gibt zurück, nachdem die Schlafoperation erfolgreich in die Warteschlange gestellt wurde. Er wartet nicht auf den Abschluss des Schlaf-/Reaktivierungszyklus.
Hinzugefügt in Version 256.
suspend
Versetzt das System in den Suspend-Zustand. Dadurch wird die Aktivierung der speziellen Target-Unit suspend.target ausgelöst. Dieser Befehl ist asynchron und gibt zurück, nachdem die Suspend-Operation erfolgreich in die Warteschlange gestellt wurde. Er wartet nicht auf den Abschluss des Suspend-/Reaktivierungszyklus.
Wenn --force angegeben ist und systemd-logind einen Fehler für die Operation zurückgibt, wird der Fehler ignoriert und die Operation wird direkt durch das Starten der Target-Unit erneut versucht.
hibernate
Versetzt das System in den Hibernate-Zustand. Dadurch wird die Aktivierung der speziellen Target-Unit hibernate.target ausgelöst. Dieser Befehl ist asynchron und gibt zurück, nachdem die Hibernate-Operation erfolgreich in die Warteschlange gestellt wurde. Er wartet nicht auf den Abschluss des Hibernate-/Reaktivierungszyklus.
Dieser Befehl berücksichtigt --force auf die gleiche Weise wie suspend.
hybrid-sleep
Versetzt das System in einen Hybrid-Schlafzustand, indem es hiberniert und dann suspendiert. Dadurch wird die Aktivierung der speziellen Target-Unit hybrid-sleep.target ausgelöst. Dieser Befehl ist asynchron und gibt zurück, nachdem die Hybrid-Schlafoperation erfolgreich in die Warteschlange gestellt wurde. Er wartet nicht auf den Abschluss des Schlaf-/Reaktivierungszyklus.
Dieser Befehl berücksichtigt --force auf die gleiche Weise wie suspend.
Hinzugefügt in Version 196.
suspend-then-hibernate
Versetzt das System in den Suspend-Zustand und hiberniert es, wenn der Akku schwach ist oder wenn die in systemd-sleep.conf angegebene Verzögerung verstrichen ist. Dadurch wird die Aktivierung der speziellen Target-Unit suspend-then-hibernate.target ausgelöst. Dieser Befehl ist asynchron und gibt zurück, nachdem die Hybrid-Schlafoperation erfolgreich in die Warteschlange gestellt wurde. Er wartet nicht auf den Abschluss des Schlaf-/Reaktivierungs- oder Hibernate-/Reaktivierungszyklus.
Dieser Befehl berücksichtigt --force auf die gleiche Weise wie suspend.
Hinzugefügt in Version 240.
Parametersyntax
Die oben aufgeführten Unit-Befehle akzeptieren entweder einen einzelnen Unit-Namen (als UNIT bezeichnet) oder mehrere Unit-Spezifikationen (als PATTERN...). Im ersten Fall muss der Unit-Name mit oder ohne Suffix angegeben werden. Wenn das Suffix nicht angegeben ist (der Unit-Name ist "abgekürzt"), hängt systemctl standardmäßig ein geeignetes Suffix ".service" und im Falle von Befehlen, die nur auf bestimmte Unit-Typen wirken, ein typspezifisches Suffix an. Zum Beispiel:
# systemctl start sshd
und
# systemctl start sshd.service
sind äquivalent, ebenso wie
# systemctl isolate default
und
# systemctl isolate default.target
Beachten Sie, dass (absolute) Pfade zu Gerätedateien automatisch in Geräteeinheiten-Namen konvertiert werden und andere (absolute) Pfade in Mount-Einheiten-Namen.
# systemctl status /dev/sda
# systemctl status /home
sind äquivalent zu:
# systemctl status dev-sda.device
# systemctl status home.mount
Im zweiten Fall werden Shell-ähnliche Platzhalter (Globs) mit den Primärnamen aller derzeit im Speicher befindlichen Einheiten abgeglichen; literale Einheitsnamen, mit oder ohne Suffix, werden wie im ersten Fall behandelt. Dies bedeutet, dass sich literale Einheitsnamen immer auf genau eine Einheit beziehen, während Globs möglicherweise auf null Einheiten passen, was jedoch nicht als Fehler betrachtet wird.
Glob-Muster verwenden fnmatch(3), daher werden die normalen Shell-ähnlichen Globbing-Regeln verwendet, und "*", "?", "[]" können verwendet werden. Weitere Informationen finden Sie in glob(7). Die Muster werden mit den Primärnamen der
derzeit im Speicher befindlichen Einheiten abgeglichen, und Muster, die nichts abgleichen, werden stillschweigend übersprungen. Zum Beispiel:
# systemctl stop "sshd@*.service"
stoppt alle `[email protected]`-Instanzen. Beachten Sie, dass Alias-Namen von Einheiten und Einheiten, die sich nicht im Speicher befinden, für die Glob-Erweiterung nicht berücksichtigt werden.
Für Einheitsdatei-Befehle sollte UNIT der Name der Einheitsdatei (möglicherweise abgekürzt, siehe oben) oder der absolute Pfad zur Einheitsdatei sein:
# systemctl enable foo.service
oder
# systemctl link /path/to/foo.service
OPTIONEN
Die folgenden Optionen werden unterstützt:
-t, --type=
Das Argument ist eine durch Kommas getrennte Liste von Einheitentypen, z. B. service und socket. Wenn Einheiten mit list-units, list-dependencies, show oder status aufgelistet werden, werden nur Einheiten der angegebenen
Typen angezeigt. Standardmäßig werden Einheiten aller Typen angezeigt.
In einem Sonderfall wird, wenn eines der Argumente help ist, eine Liste der zulässigen Werte ausgegeben und das Programm beendet.
--state=
Das Argument ist eine durch Kommas getrennte Liste der LOAD, SUB oder ACTIVE-Zustände von Einheiten. Wenn Einheiten mit list-units, list-dependencies, show oder status aufgelistet werden, werden nur diejenigen in den angegebenen
Zuständen angezeigt. Verwenden Sie --state=failed oder --failed, um nur fehlgeschlagene Einheiten anzuzeigen.
In einem Sonderfall wird, wenn eines der Argumente help ist, eine Liste der zulässigen Werte ausgegeben und das Programm beendet.
Hinzugefügt in Version 206.
-p, --property=
Wenn Eigenschaften von Einheiten/Jobs/Managern mit dem Befehl show angezeigt werden, wird die Anzeige auf die in dem Argument angegebenen Eigenschaften beschränkt. Das Argument sollte eine durch Kommas getrennte Liste von Eigenschaftsnamen sein,
z. B. "MainPID". Wenn nichts angegeben ist, werden alle bekannten Eigenschaften angezeigt. Wenn mehr als einmal angegeben, werden alle Eigenschaften mit den angegebenen Namen angezeigt. Die Shell-Vervollständigung wird für
Eigenschaftsnamen implementiert.
Für das Manager-Objekt selbst zeigt systemctl show alle verfügbaren Eigenschaften an, von denen die meisten abgeleitet sind oder den in systemd-system.conf(5) beschriebenen Optionen entsprechen.
Die Eigenschaften für Einheiten variieren je nach Einheitentyp. Das Anzeigen einer beliebigen Einheit (auch einer nicht existierenden) ist eine Möglichkeit, die für diesen Typ relevanten Eigenschaften aufzulisten. Ebenso listet das Anzeigen eines beliebigen Jobs die für alle Jobs relevanten Eigenschaften auf. Die Eigenschaften von Einheiten sind in systemd.unit(5) dokumentiert, und die Seiten für einzelne Einheitentypen sind systemd.service(5), systemd.socket(5) usw.
-P
Entspricht --value --property=, d. h., es wird der Wert der Eigenschaft ohne den Eigenschaftsnamen oder das Gleichheitszeichen angezeigt. Beachten Sie, dass die einmalige Verwendung von -P auch alle mit -p/--property= aufgelisteten Eigenschaften beeinflusst.
Hinzugefügt in Version 246.
-a, --all
Beim Auflisten von Einheiten mit list-units werden auch inaktive Einheiten und Einheiten, die anderen Einheiten folgen, angezeigt. Beim Anzeigen von Einheit-/Job-/Manager-Eigenschaften werden alle Eigenschaften angezeigt, unabhängig davon, ob sie gesetzt sind oder nicht.
Um alle im Dateisystem installierten Einheiten aufzulisten, verwenden Sie stattdessen den Befehl list-unit-files.
Beim Auflisten von Einheiten mit list-dependencies werden rekursiv die Abhängigkeiten aller abhängigen Einheiten angezeigt (standardmäßig werden nur die Abhängigkeiten von Ziel-Einheiten angezeigt).
Bei Verwendung mit status werden die Journal-Nachrichten vollständig angezeigt, auch wenn sie nicht druckbare Zeichen oder sehr lange Inhalte enthalten. Standardmäßig werden Felder mit nicht druckbaren Zeichen als „blob data“ abgekürzt. (Beachten Sie, dass der Pager nicht druckbare Zeichen möglicherweise erneut maskiert.)
-r, --recursive
Beim Auflisten von Einheiten werden auch Einheiten von lokalen Containern angezeigt. Die Einheiten von lokalen Containern werden mit dem Containernamen versehen, getrennt durch ein einzelnes Doppelpunktzeichen (":").
Hinzugefügt in Version 212.
--reverse
Zeigt die umgekehrten Abhängigkeiten zwischen Einheiten mit list-dependencies an, d. h., es werden die Abhängigkeiten vom Typ WantedBy=, RequiredBy=, UpheldBy=, PartOf=, BoundBy= verfolgt, anstatt Wants= und ähnliches.
Hinzugefügt in Version 203.
--after
Mit list-dependencies werden die Einheiten angezeigt, die vor der angegebenen Einheit angeordnet sind. Mit anderen Worten, es werden rekursiv die Einheiten aufgelistet, die der Abhängigkeit After= folgen.
Beachten Sie, dass jede After=-Abhängigkeit automatisch in eine Before=-Abhängigkeit umgewandelt wird. Temporale Abhängigkeiten können explizit angegeben werden, werden aber auch implizit für Einheiten erstellt, die Ziele von WantedBy= sind (siehe systemd.target(5)), und als Ergebnis anderer Direktiven (z. B. RequiresMountsFor=). Sowohl explizit als auch implizit erzeugte Abhängigkeiten werden mit list-dependencies angezeigt.
Wenn sie an den Befehl list-jobs übergeben wird, werden für jeden ausgegebenen Job die anderen Jobs angezeigt, die auf ihn warten. Kann in Kombination mit --before verwendet werden, um sowohl die Jobs anzuzeigen, die auf jeden Job warten, als auch alle Jobs, auf die jeder Job wartet.
Hinzugefügt in Version 203.
--before
Mit list-dependencies werden die Einheiten angezeigt, die nach der angegebenen Einheit angeordnet sind. Mit anderen Worten, es werden rekursiv die Einheiten aufgelistet, die der Abhängigkeit Before= folgen.
Wenn es an den Befehl list-jobs übergeben wird, wird für jeden ausgegebenen Job angezeigt, auf welche anderen Jobs er wartet. Kann mit --after kombiniert werden, um sowohl die Jobs anzuzeigen, auf die jeder Job wartet, als auch alle Jobs, auf die jeder Job wartet.
Eingeführt in Version 212.
--with-dependencies
Wenn es mit status, cat, list-units und list-unit-files verwendet wird, geben diese Befehle alle angegebenen Einheiten und die Abhängigkeiten dieser Einheiten aus.
Die Optionen --reverse, --after und --before können verwendet werden, um zu ändern, welche Arten von Abhängigkeiten angezeigt werden.
Eingeführt in Version 245.
-l, --full
Verkürze keine Einheitsnamen, Prozessbaum-Einträge, Journal-Ausgabe oder Einheitsbeschreibungen in der Ausgabe von status, list-units, list-jobs und list-timers.
Zeige außerdem Installationsziele in der Ausgabe von is-enabled an.
--value
Wenn Eigenschaften mit show ausgegeben werden, gib nur den Wert aus und überspringe den Eigenschaftsnamen und das Gleichheitszeichen. Siehe auch die Option -P oben.
Eingeführt in Version 230.
--show-types
Wenn Sockets angezeigt werden, zeige den Typ des Sockets an.
Eingeführt in Version 202.
--job-mode=
Wenn ein neuer Job in die Warteschlange gestellt wird, steuert diese Option, wie mit bereits in der Warteschlange stehenden Jobs umgegangen werden soll. Sie nimmt einen der folgenden Werte an: "fail", "lenient", "replace", "replace-irreversibly", "isolate", "ignore-dependencies", "ignore-requirements", "flush", "triggering" oder "restart-dependencies". Standardmäßig "replace", außer wenn der Befehl isolate verwendet wird, der implizit den Job-Modus "isolate" impliziert.
Wenn "fail" angegeben ist und eine angeforderte Operation an schwachen Abhängigkeiten mit einem ausstehenden Job in Konflikt steht (insbesondere: wenn ein bereits ausstehender Startjob in einen Stoppjob umgewandelt wird oder umgekehrt), schlägt die Operation fehl.
Wenn "lenient" angegeben ist und eine angeforderte Operation mit einer aktiven/aktivierenden Einheit in Konflikt steht, schlägt die Operation fehl.
Wenn "replace" (der Standardwert) angegeben ist, wird jeder widersprüchliche ausstehende Job bei Bedarf ersetzt.
Wenn "replace-irreversibly" angegeben ist, wird wie bei "replace" vorgegangen, aber die neuen Jobs werden auch als irreversibel gekennzeichnet. Dies verhindert, dass zukünftige widersprüchliche Transaktionen diese Jobs ersetzen (oder sogar in die Warteschlange gestellt werden, während die irreversiblen Jobs noch ausstehen). Irreversible Jobs können jedoch mit dem Befehl cancel abgebrochen werden. Dieser Job-Modus sollte für jede Transaktion verwendet werden, die shutdown.target einbezieht.
`"isolate"` ist nur für Startoperationen gültig und führt dazu, dass alle anderen Einheiten gestoppt werden, wenn die angegebene Einheit gestartet wird. Dieser Modus wird immer verwendet, wenn der Befehl `isolate` verwendet wird.
`"flush"` führt dazu, dass alle in der Warteschlange stehenden Jobs abgebrochen werden, wenn der neue Job in die Warteschlange gestellt wird.
Wenn "ignore-dependencies" angegeben ist, werden alle Abhängigkeiten der Einheit für diesen neuen Job ignoriert und die Operation wird sofort ausgeführt. Wenn dies angegeben ist, werden keine erforderlichen Einheiten der angegebenen Einheit einbezogen, und die Abhängigkeiten der Reihenfolge werden nicht berücksichtigt. Dies ist hauptsächlich ein Debugging- und Rettungstool für den Administrator und sollte nicht von Anwendungen verwendet werden.
`"ignore-requirements"` ähnelt `"ignore-dependencies"`, führt aber nur dazu, dass die Anforderungsabhängigkeiten ignoriert werden, während die Abhängigkeiten der Reihenfolge weiterhin berücksichtigt werden.
„triggering“ darf nur mit systemctl stop verwendet werden. In diesem Modus werden die angegebene Einheit und alle aktiven Einheiten, die diese auslösen, gestoppt. Weitere Informationen zu auslösenden Einheiten finden Sie in der Beschreibung von Triggers= in systemd.unit(5).
„restart-dependencies“ darf nur mit systemctl start verwendet werden. In diesem Modus erhalten die Abhängigkeiten der angegebenen Einheit eine Neustartweitergabe, als ob ein Neustartauftrag für die Einheit in die Warteschlange gestellt worden wäre.
Hinzugefügt in Version 209.
-T, --show-transaction
Beim In-die-Warteschlange-Stellen eines Einheitenauftrags (z. B. als Folge eines systemctl start-Aufrufs oder ähnliches) werden kurze Informationen über alle in die Warteschlange gestellten Aufträge angezeigt, einschließlich des angeforderten Auftrags und aller aufgrund von Einheitenabhängigkeiten hinzugefügten Aufträge. Beachten Sie, dass die Ausgabe nur die Aufträge enthält, die sich unmittelbar an der angeforderten Transaktion beteiligen. Es ist möglich, dass das als Folge der in die Warteschlange gestellten Aufträge ausgeführte Dienststartprogramm weitere Aufträge anfordert, die in die Warteschlange gestellt werden. Dies bedeutet, dass die Ausführung der aufgeführten Aufträge letztendlich mehr Aufträge als die aufgeführten Aufträge umfassen kann.
Hinzugefügt in Version 242.
--fail
Kurzform für --job-mode=fail.
Wenn es mit dem Befehl kill verwendet wird, führt dies zu einem Fehler, wenn keine Einheiten beendet wurden.
Hinzugefügt in Version 227.
--check-inhibitors=
Wenn ein System-Shutdown oder ein Schlafzustand angefordert wird, steuert diese Option die Überprüfung von Inhibitor-Sperren. Es nimmt einen der Werte „auto“, „yes“ und „no“ an. Standardmäßig ist „auto“ eingestellt, was bedeutet, dass logind die Überprüfung durchführt und aktive Inhibitor-Sperren berücksichtigt, während systemctl nur eine clientseitige Überprüfung für interaktive Aufrufe (d. h. von einem TTY) durchführt, sodass eine benutzerfreundlichere und informativere Fehlermeldung an die Benutzer zurückgegeben werden kann. „no“ deaktiviert die Überprüfungen sowohl in systemctl als auch in systemd-logind(8).
Anwendungen können Inhibitor-Sperren einrichten, um zu verhindern, dass bestimmte wichtige Vorgänge (wie z. B. das Brennen einer CD) durch einen System-Shutdown oder einen Schlafzustand unterbrochen werden. Jeder Benutzer kann diese Sperren einrichten, und privilegierte Benutzer können diese Sperren außer Kraft setzen. Wenn Sperren vorhanden sind, schlagen Shutdown- und Schlafzustandsanforderungen normalerweise fehl (es sei denn, sie werden explizit mit „no“ außer Kraft gesetzt).
Die Option --force bietet eine weitere Möglichkeit, Inhibitoren außer Kraft zu setzen.
Hinzugefügt in Version 248.
-i
Kurzform für --check-inhibitors=no.
Hinzugefügt in Version 198.
--dry-run
Gibt nur aus, was geschehen würde. Derzeit wird dies von den Verben halt, poweroff, reboot, kexec, suspend, hibernate, hybrid-sleep, suspend-then-hibernate, default, rescue, emergency und exit unterstützt.
Hinzugefügt in Version 236.
-q, --quiet
Unterdrückt die Ausgabe der Ergebnisse verschiedener Befehle sowie die Hinweise zu abgeschnittenen Protokollzeilen. Dies unterdrückt nicht die Ausgabe von Befehlen, bei denen die ausgegebene Ausgabe das einzige Ergebnis ist (z. B. show). Fehler werden immer ausgegeben.
-v, --verbose
Zeigt die Protokollausgabe der Einheit während der Ausführung von Einheitsoperationen an.
Hinzugefügt in Version 258.
--no-warn
Verhindert die Generierung der Standardwarnungen in den folgenden Fällen:
wenn systemctl ohne gemountetes /proc-Dateisystem aufgerufen wird,
wenn `enable` oder `disable` für Einheiten ohne Installationsinformationen verwendet wird (d. h. sie haben keine oder eine leere Sektion `[Install]`),
wenn `disable` in Kombination mit `--user` für Einheiten verwendet wird, die im globalen Bereich aktiviert sind,
wenn eine gestoppte, deaktivierte oder maskierte Einheit noch aktive auslösende Einheiten hat,
wenn eine Unit-Datei geändert wurde und ein Neustart des Daemons erforderlich ist.
Hinzugefügt in Version 253.
--no-block
Nicht synchron auf das Ende der angeforderten Operation warten. Wenn dies nicht angegeben ist, wird der Job überprüft, in die Warteschlange gestellt und systemctl wartet, bis die Unit vollständig gestartet ist. Durch die Übergabe dieses Arguments wird nur überprüft und in die Warteschlange gestellt. Diese Option darf nicht mit --wait kombiniert werden.
--wait
Wenn zusammen mit start oder restart verwendet, synchron darauf warten, dass gestartete Einheiten erneut beendet werden. Diese Option darf nicht mit --no-block kombiniert werden. Beachten Sie, dass dies unendlich lange warten würde, wenn eine bestimmte Einheit nicht terminiert (entweder von selbst oder durch explizites Stoppen); insbesondere Dienste, die RemainAfterExit=yes verwenden.
Wenn zusammen mit `is-system-running` verwendet, warten, bis der Boot-Prozess abgeschlossen ist, bevor der Wert zurückgegeben wird.
Wenn zusammen mit `kill` verwendet, warten, bis die signalisierten Einheiten beendet sind. Beachten Sie, dass dies unendlich lange warten würde, wenn eine bestimmte Einheit nicht terminiert.
Hinzugefügt in Version 232.
--user
Mit dem Dienstmanager des aufrufenden Benutzers kommunizieren, anstatt mit dem Dienstmanager des Systems.
--system
Mit dem Dienstmanager des Systems kommunizieren. Dies ist die implizite Standardeinstellung.
--failed
Einheiten im fehlgeschlagenen Zustand auflisten. Dies entspricht --state=failed.
Hinzugefügt in Version 233.
--no-wall
Keine Wall-Nachricht vor halt, power-off und reboot senden.
--global
Wenn zusammen mit enable und disable verwendet, auf das globale Benutzerkonfigurationsverzeichnis wirken, wodurch eine Unit-Datei global für alle zukünftigen Anmeldungen aller Benutzer aktiviert oder deaktiviert wird.
--no-reload
Wenn zusammen mit enable, disable, preset, mask oder unmask verwendet, die Daemons-Konfiguration nach der Ausführung der Änderungen nicht implizit neu laden.
--kill-whom=
Wenn zusammen mit kill verwendet, auswählen, welche Prozesse das UNIX-Prozesssignal empfangen sollen. Muss eines von main, control, cgroup oder all sein, um auszuwählen, ob nur der Hauptprozess, der Kontrollprozess, alle Prozesse in der Kontrollgruppe der Einheit oder alle Prozesse der Einheit beendet werden sollen. Der Hauptprozess der Einheit ist derjenige, der die Lebensdauer definiert. Ein Kontrollprozess einer Einheit ist ein Prozess, der vom Manager aufgerufen wird, um Zustandsänderungen der Einheit herbeizuführen. Zum Beispiel sind alle Prozesse, die aufgrund der Einstellungen ExecStartPre=, ExecStop= oder ExecReload= von Service-Einheiten gestartet werden, Kontrollprozesse. Beachten Sie, dass es nur einen Kontrollprozess pro Einheit gleichzeitig gibt, da jeweils nur eine Zustandsänderung ausgeführt wird. Für Service-Einheiten des Typs Type=forking ist der vom Manager für ExecStart= gestartete Prozess ein Kontrollprozess, während der Prozess, der letztendlich davon abzweigt, dann als Hauptprozess der Einheit betrachtet wird (wenn dies festgestellt werden kann). Dies ist anders für Service-Einheiten anderer Typen, bei denen der vom Manager für ExecStart= erzeugte Prozess immer der Hauptprozess selbst ist. Eine Service-Einheit besteht aus null oder einem Hauptprozess, null oder einem Kontrollprozess sowie einer beliebigen Anzahl zusätzlicher Prozesse, die Teil der Kontrollgruppe der Einheit sind. Nicht alle Einheitstypen verwalten jedoch Prozesse dieser Typen. Zum Beispiel sind für Mount-Einheiten Kontrollprozesse definiert (die die Aufrufe von /usr/bin/mount und /usr/bin/umount sind), aber kein Hauptprozess ist definiert. Wenn dies weggelassen wird, ist der Standard all, es sei denn, --kill-subgroup= wird verwendet, in diesem Fall ist der Standard cgroup.
Hinzugefügt in Version 252.
--kill-value=INT
Wenn mit dem Befehl kill verwendet, wird ein Signal zusammen mit dem angegebenen ganzzahligen Wert
an den angegebenen Prozess(e) in die Warteschlange gestellt. Diese Operation ist nur für POSIX-Echtzeitsignale verfügbar (d. h. --signal=SIGRTMIN+... oder --signal=SIGRTMAX-...), und stellt sicher, dass die Signale über den Systemaufruf sigqueue(3) und nicht über kill({filename}../../kill)(3) generiert werden. Der angegebene Wert muss eine 32-Bit-vorzeichenbehaftete Ganzzahl sein und kann entweder dezimal, hexadezimal (wenn mit "0x" präfixiert), oktal (wenn mit "0o" präfixiert) oder binär (wenn mit "0b" präfixiert) angegeben werden.
Wenn diese Option verwendet wird, wird das Signal nur an den Haupt- oder Steuerungsprozess der Einheit in die Warteschlange gestellt, niemals an andere Prozesse, die zur Einheit gehören, d. h. --kill-whom=all wirkt sich nur auf die Haupt- und Steuerungsprozesse, aber nicht auf andere Prozesse aus.
Hinzugefügt in Version 254.
--kill-subgroup=PATH
Nimmt einen Kontrollgruppen-Subpfad entgegen, an den Signale gesendet werden sollen, für die Verwendung mit dem Befehl kill. Standardmäßig wird das ausgewählte Signal an alle Prozesse der Kontrollgruppen der Einheit (sowie an die Haupt-/Steuerungsprozesse (falls außerhalb)) gesendet – vorbehaltlich von --kill-whom=. Mit dieser Option kann stattdessen eine Untergruppe ausgewählt werden. Diese Funktionalität ist nur verfügbar, wenn cgroup oder cgroup-fail zusammen mit --kill-whom= verwendet werden, und tatsächlich ist Letzteres die Standardeinstellung, wenn --kill-subgroup= verwendet wird.
Der angegebene Pfad kann, muss aber nicht, mit einem Schrägstrich beginnen, und das Vorhandensein oder Fehlen hat keinen Einfluss, da der Pfad entweder so oder so relativ zum Hauptkontrollgruppenpfad der Einheit genommen wird.
Diese Funktionalität ist nur für Einheiten verfügbar, bei denen die Delegierung von Kontrollgruppen aktiviert ist (siehe Delegate= in systemd.resource-control(5)).
Hinzugefügt in Version 258.
-s, --signal=
Wenn mit kill verwendet, wird festgelegt, welches Signal an die ausgewählten Prozesse gesendet werden soll. Muss eines der bekannten Signalbezeichner sein, z. B. SIGTERM, SIGINT oder SIGSTOP. Wenn nicht angegeben, ist der Standardwert SIGTERM.
Der spezielle Wert help listet die bekannten Werte auf und beendet das Programm sofort, und der spezielle Wert list listet die bekannten Werte zusammen mit den numerischen Signalnummern auf und beendet das Programm sofort.
--what=
Wählt aus, welche Art von ressourcenbezogenen Daten pro Einheit entfernt werden soll, wenn der Befehl clean aufgerufen wird, siehe oben. Nimmt einen der Konfigurationswerte configuration, state, cache, logs, runtime, fdstore entgegen, um den Ressourcentyp auszuwählen. Diese Option kann mehrmals angegeben werden, in diesem Fall werden alle angegebenen Ressourcentypen entfernt. Akzeptiert auch den speziellen Wert all als Abkürzung für die Angabe aller sechs Ressourcentypen. Wenn diese Option nicht angegeben ist, ist der Standardwert die Kombination aus cache, runtime und fdstore, d. h. die drei Arten von Ressourcen, die im Allgemeinen als redundant betrachtet werden und bei der nächsten Ausführung neu erstellt werden können. Beachten Sie, dass die explizite Entfernung des Ressourcentyps fdstore nur dann nützlich ist, wenn die Option FileDescriptorStorePreserve= aktiviert ist, da der Datei-Descriptor-Speicher andernfalls automatisch bereinigt wird, wenn die Einheit gestoppt wird.
Hinzugefügt in Version 243.
-f, --force
Wenn zusammen mit enable verwendet, werden alle vorhandenen, widersprüchlichen symbolischen Verknüpfungen überschrieben.
Wenn zusammen mit edit verwendet, werden alle angegebenen Einheiten erstellt, die noch nicht existieren.
Wenn zusammen mit suspend, hibernate, hybrid-sleep oder suspend-then-hibernate verwendet, wird der von systemd-logind zurückgegebene Fehler ignoriert, und die Operation wird direkt durch das Starten der entsprechenden Einheiten ausgeführt.
Wenn zusammen mit halt, poweroff, reboot oder kexec verwendet, wird die ausgewählte Operation ausgeführt, ohne alle Einheiten herunterzufahren. Allerdings werden alle Prozesse gewaltsam beendet und alle Dateisysteme werden ausgehängt oder im Nur-Lese-Modus erneut eingebunden. Dies ist daher eine drastische, aber relativ sichere Option, um einen sofortigen Neustart anzufordern. Wenn --force zweimal für diese Operationen angegeben wird (mit Ausnahme von kexec), werden diese sofort ausgeführt, ohne Prozesse zu beenden oder Dateisysteme auszuhängen.
Warnung
Das zweimalige Verwenden von --force mit einer dieser Operationen kann zu Datenverlust führen. Beachten Sie, dass bei zweimaliger Angabe von --force die ausgewählte Operation von systemctl selbst ausgeführt wird, und nicht der System-Manager kontaktiert wird. Das bedeutet, dass der Befehl auch dann erfolgreich sein sollte, wenn der System-Manager abgestürzt ist.
--message=
Wenn zusammen mit halt, poweroff oder reboot verwendet, wird eine kurze Nachricht festgelegt, die den Grund für die Operation erklärt. Die Nachricht wird zusammen mit der Standard-Shutdown-Nachricht protokolliert.
Hinzugefügt in Version 225.
--now
Wenn zusammen mit enable, disable, mask oder reenable verwendet, werden die Einheiten nach erfolgreichem Ausführen der angegebenen Operationen mit den Unit-Dateien auch gestartet/gestoppt/neu gestartet.
Hinzugefügt in Version 220.
--root=
Wenn zusammen mit enable/disable/is-enabled (und verwandten Befehlen) verwendet, wird der angegebene Root-Pfad verwendet, wenn nach Unit-Dateien gesucht wird. Wenn diese Option vorhanden ist, arbeitet systemctl direkt auf dem Dateisystem, anstatt mit dem systemd-Daemon zu kommunizieren, um Änderungen vorzunehmen.
--image=image
Nimmt einen Pfad zu einer Festplatten-Image-Datei oder einem Blockgerät-Knoten entgegen. Wenn angegeben, werden alle Operationen auf das Dateisystem in dem angegebenen Festplatten-Image angewendet. Diese Option ist ähnlich wie --root=, wirkt sich aber auf Dateisysteme aus, die in Festplatten-Images oder Blockgeräten gespeichert sind. Das Festplatten-Image sollte entweder nur ein Dateisystem oder eine Reihe von Dateisystemen innerhalb einer GPT-Partitionstabelle enthalten, die der UAPI.2 Discoverable Partitions Specification[2] folgt. Weitere Informationen zu unterstützten Festplatten-Images finden Sie in systemd-nspawn(1) unter dem gleichen Namen.
Hinzugefügt in Version 252.
--image-policy=policy
Akzeptiert eine Zeichenkette für die Bildrichtlinie als Argument, gemäß systemd.image-policy(7). Die Richtlinie wird angewendet, wenn auf das über --image= angegebene Disk-Image zugegriffen wird, siehe oben. Wenn nicht angegeben, ist die Standardeinstellung die Richtlinie "*", d.h. alle erkannten Dateisysteme im Bild werden verwendet.
--runtime
Wenn zusammen mit enable, disable, edit (und verwandten Befehlen) verwendet, werden Änderungen nur vorübergehend vorgenommen, sodass sie beim nächsten Neustart verloren gehen. Dies hat den Effekt, dass Änderungen nicht in Unterverzeichnissen von /etc/ vorgenommen werden, sondern in /run/, mit identischen sofortigen Auswirkungen, da diese jedoch beim Neustart verloren gehen, gehen auch die Änderungen verloren.
Ebenso werden bei Verwendung mit set-property Änderungen nur vorübergehend vorgenommen, sodass sie beim
nächsten Neustart verloren gehen.
--preset-mode=
Akzeptiert einen der Werte "full" (Standard), "enable-only", "disable-only". Wenn zusammen mit den Befehlen preset oder preset-all verwendet, wird gesteuert, ob Einheiten gemäß den Preset-Regeln deaktiviert und aktiviert werden sollen oder nur aktiviert oder nur deaktiviert werden sollen.
Hinzugefügt in Version 215.
-n, --lines=
Wenn zusammen mit status verwendet, wird die Anzahl der anzuzeigenden Journal-Zeilen gesteuert, wobei von den aktuellsten gezählt wird. Akzeptiert eine positive ganze Zahl als Argument oder 0, um die Journal-Ausgabe zu deaktivieren. Standardwert ist:
-o, --output=
Wenn zusammen mit status verwendet, wird das Format der angezeigten Journal-Einträge gesteuert. Für die verfügbaren Optionen siehe journalctl(1). Standardwert ist "short".
--firmware-setup
Wenn zusammen mit den Befehlen reboot, poweroff oder halt verwendet, wird dem Firmware-System mitgeteilt, dass es beim nächsten Start in die Firmware-Einrichtungs-Schnittstelle booten soll. Beachten Sie, dass diese Funktionalität nicht auf allen Systemen verfügbar ist.
Hinzugefügt in Version 220.
--boot-loader-menu=timeout
Wenn zusammen mit den Befehlen reboot, poweroff oder halt verwendet, wird dem Bootloader des Systems mitgeteilt, dass beim nächsten Start das Bootloader-Menü angezeigt werden soll. Akzeptiert einen Zeitwert als Parameter – der den Timeout für das Menü angibt. Übergeben Sie Null, um den Menü-Timeout zu deaktivieren. Beachten Sie, dass nicht alle Bootloader diese Funktionalität unterstützen.
Hinzugefügt in Version 242.
--boot-loader-entry=ID
Wenn zusammen mit den Befehlen reboot, poweroff oder halt verwendet, wird dem Bootloader des Systems mitgeteilt, dass beim nächsten Start in einen bestimmten Bootloader-Eintrag gebootet werden soll. Akzeptiert eine Bootloader-Eintrags-ID als Argument oder "help", um die verfügbaren Einträge aufzulisten. Beachten Sie, dass nicht alle Bootloader diese Funktionalität unterstützen.
Hinzugefügt in Version 242.
--reboot-argument=
Diese Option wird mit reboot verwendet. Der Wert ist architektur- und firmwarespezifisch. Beispielsweise könnte "recovery" verwendet werden, um einen Systemwiederherstellungsmodus auszulösen, und "fota" könnte verwendet werden, um ein „Firmware-Over-the-Air“-Update auszulösen.
Hinzugefügt in Version 246.
--plain
Wenn zusammen mit list-dependencies, list-units oder list-machines verwendet, wird die Ausgabe als Liste statt als Baum ausgegeben, und die Aufzählungszeichen werden weggelassen.
Hinzugefügt in Version 203.
--timestamp=
Ändert das Format der ausgegebenen Zeitstempel. Die folgenden Werte können verwendet werden:
pretty (Standardeinstellung)
„Tag JJJJ-MM-TT HH:MM:SS ZEITZONE“
Hinzugefügt in Version 248.
unix
„@Sekunden-seit-Epoche“
Hinzugefügt in Version 251.
us, μs
„Tag JJJJ-MM-TT HH:MM:SS.UUUUUU ZEITZONE“
Hinzugefügt in Version 248.
utc
„Tag JJJJ-MM-TT HH:MM:SS UTC“
Hinzugefügt in Version 248.
us+utc, μs+utc
„Tag JJJJ-MM-TT HH:MM:SS.UUUUUU UTC“
Hinzugefügt in Version 248.
Hinzugefügt in Version 247.
--mkdir
Bei Verwendung mit bind wird die Zieldatei oder das Zielverzeichnis erstellt, bevor die
Bind-Mount-Operation angewendet wird. Beachten Sie, dass diese Option zwar den Eindruck
erweckt, dass sie nur für Verzeichnisse geeignet ist, sie erstellt jedoch auch den
Zieldateiknoten, um ihn zu mounten, wenn das zu mountende Objekt kein Verzeichnis, sondern
eine reguläre Datei, ein Geräteknoten, ein Socket oder eine FIFO ist.
Hinzugefügt in Version 248.
--marked
Nur zusammen mit reload-or-restart erlaubt. Es werden Neustart-Jobs für alle Einheiten in die
Warteschlange gestellt, die das „needs-restart“-Kennzeichen haben, und Reload-Jobs für Einheiten,
die das „needs-reload“-Kennzeichen haben. Wenn eine Einheit, die für Reload gekennzeichnet ist,
Reload nicht unterstützt, wird ein Neustart in die Warteschlange gestellt. Diese Eigenschaften
können mit set-property Markers=... festgelegt werden.
Es sei denn, --no-block wird verwendet, wartet systemctl, bis die in die Warteschlange
gestellten Jobs abgeschlossen sind.
Hinzugefügt in Version 248.
--read-only
Bei Verwendung mit bind wird ein schreibgeschütztes Bind-Mount erstellt.
Hinzugefügt in Version 248.
--drop-in=NAME
Bei Verwendung mit edit wird NAME als Name der Drop-in-Datei anstelle von override.conf
verwendet.
Hinzugefügt in Version 253.
--when=
Bei Verwendung mit halt, poweroff, reboot oder kexec wird die Aktion so geplant, dass sie zu
dem angegebenen Zeitpunkt ausgeführt wird, der der in systemd.time(7) im Abschnitt
„PARSING TIMESTAMPS“ dokumentierten Syntax entsprechen sollte. Insbesondere wird bei
Angabe von „show“ die derzeit geplante Aktion angezeigt, die durch Übergabe einer leeren
Zeichenkette oder „cancel“ abgebrochen werden kann. „auto“ plant die Aktion basierend auf
dem Wartungsfenster oder einer Minute in der Zukunft.
Hinzugefügt in Version 254.
--stdin
Bei Verwendung mit edit wird der Inhalt der Datei von der Standardeingabe gelesen und der
Editor wird nicht gestartet. In diesem Modus werden die alten Inhalte der Datei vollständig
ersetzt. Dies ist nützlich, um Einheitsdateien über Skripte zu „bearbeiten“.
$ systemctl edit --drop-in=limits.conf --stdin some-service.service <<EOF
[Unit]
AllowedCPUs=7,11
EOF
Mehrere Drop-ins können in diesem Modus „bearbeitet“ werden; der gleiche Inhalt wird in
alle von ihnen geschrieben.
Hinzugefügt in Version 256.
-H, --host=
Führen Sie die Operation remote aus. Geben Sie einen Hostnamen oder einen Benutzernamen und
einen Hostnamen, getrennt durch ein „@“, an, um eine Verbindung herzustellen. Der Hostname kann
optional mit einem Doppelpunkt (:) gefolgt von einem Port, an dem ssh lauscht, und dann einem
Containernamen, getrennt durch einen Schrägstrich (/), versehen werden, um eine direkte
Verbindung zu einem bestimmten Container auf dem angegebenen Host herzustellen. Dies verwendet
SSH, um mit der Remote-Machine-Manager-Instanz zu kommunizieren. Container können mit
machinectl -H HOST aufgelistet werden. Verwenden Sie IPv6-Adressen in eckigen Klammern.
-M, --machine=
Führen Sie die Operation auf einem lokalen Container aus. Geben Sie einen Containernamen an, um
eine Verbindung herzustellen, und fügen Sie optional ein Präfix mit einem Benutzernamen und einem
„@“-Zeichen hinzu. Wenn die spezielle Zeichenfolge „.host“ anstelle des Containernamens
verwendet wird, wird eine Verbindung zum lokalen System hergestellt (was nützlich ist, um eine
Verbindung zum Benutzerbus eines bestimmten Benutzers herzustellen: „--user [email protected]“).
Wenn die Syntax „@“ nicht verwendet wird, wird die Verbindung als Root-Benutzer hergestellt. Wenn
die Syntax „@“ verwendet wird, kann entweder die linke oder die rechte Seite weggelassen werden
(aber nicht beides), in diesem Fall werden der lokale Benutzername und „.host“ impliziert.
-C, --capsule=
Führt eine Operation auf einer Kapsel aus. Geben Sie den Namen der Kapsel an, zu der eine Verbindung hergestellt werden soll. Weitere Informationen zu Kapseln finden Sie unter [email protected](5).
Eingeführt in Version 256.
--no-ask-password
Fordert den Benutzer nicht zur Authentifizierung für privilegierte Operationen auf.
--no-pager
Leitet die Ausgabe nicht an einen Pager weiter.
--legend=BOOL
Aktiviert oder deaktiviert das Drucken der Legende, d. h. der Spaltenüberschriften und des Fußzeilenhinweises. Die Legende wird standardmäßig gedruckt, es sei denn, sie wird mit --quiet oder einer ähnlichen Option deaktiviert.
-h, --help
Gibt einen kurzen Hilfetext aus und beendet das Programm.
--version
Gibt eine kurze Versionszeichenfolge aus und beendet das Programm.
RÜCKGABEWERT
Bei Erfolg wird 0 zurückgegeben, andernfalls ein Fehlercode ungleich Null.
systemctl verwendet die in LSB 3.0.0[3] definierten Rückgabecodes.
Tabelle 5. LSB-Rückgabecodes
┌───────┬────────────────────────────┬──────────────────────────┐
│ Wert │ Beschreibung in LSB │ Verwendung in systemd │
├───────┼────────────────────────────┼──────────────────────────┤
│ 0 │ „Programm läuft oder │ Einheit ist aktiv │
│ │ Dienst ist OK“ │ │
├───────┼────────────────────────────┼──────────────────────────┤
│ 1 │ „Programm ist tot und │ Einheit ist nicht fehlgeschlagen (wird von │
│ │ /var/run-PID-Datei existiert“ │ is-failed verwendet) │
├───────┼────────────────────────────┼──────────────────────────┤
│ 2 │ „Programm ist tot und │ nicht verwendet │
│ │ /var/lock-Sperrdatei │ │
│ │ existiert“ │ │
├───────┼────────────────────────────┼──────────────────────────┤
│ 3 │ „Programm läuft nicht“ │ Einheit ist nicht aktiv │
├───────┼────────────────────────────┼──────────────────────────┤
│ 4 │ „Programm- oder Dienststatus │ Es existiert keine solche Einheit │
│ │ ist unbekannt“ │ │
└───────┴────────────────────────────┴──────────────────────────┘
Die Zuordnung der LSB-Dienstzustände zu den Systemd-Einheitszuständen ist nicht perfekt. Daher ist es besser, sich nicht auf diese Rückgabewerte zu verlassen, sondern stattdessen nach bestimmten Einheitszuständen und Unterzuständen zu suchen.
UMGEBUNG
$SYSTEMD_EDITOR
Der Editor, der zum Bearbeiten von Einheiten verwendet werden soll; überschreibt $EDITOR und $VISUAL. Wenn weder $SYSTEMD_EDITOR noch $EDITOR noch $VISUAL vorhanden sind oder wenn diese auf eine leere Zeichenfolge gesetzt sind oder wenn ihre Ausführung fehlschlägt, versucht systemctl, die folgenden bekannten Editoren in dieser Reihenfolge auszuführen: editor(1), [nano]({filename}../../nano)(1), [vim]({filename}../../vim)(1), vi(1).
Hinzugefügt in Version 218.
$SYSTEMD_LOG_LEVEL
Das maximale Protokollierungsniveau der ausgegebenen Nachrichten (Nachrichten mit einem höheren Protokollierungsniveau, d. h. weniger wichtigen Nachrichten, werden unterdrückt). Nimmt eine durch Komma getrennte Liste von Werten an. Ein Wert kann entweder einer der folgenden sein (in absteigender Reihenfolge der Wichtigkeit): emerg, alert, crit, err, warning, notice, info, debug oder eine ganze Zahl im Bereich 0...7. Weitere Informationen finden Sie in syslog(3). Jeder Wert kann optional mit einem der folgenden Präfixe versehen werden: console, syslog, kmsg oder journal, gefolgt von einem Doppelpunkt, um das maximale Protokollierungsniveau für das jeweilige Protokollierungsziel festzulegen (z. B. legt SYSTEMD_LOG_LEVEL=debug,console:info fest, dass Nachrichten mit dem Debug-Level protokolliert werden, mit Ausnahme der Protokollierung in der Konsole, die mit dem Info-Level erfolgen soll). Beachten Sie, dass das globale maximale Protokollierungsniveau Vorrang vor allen zielspezifischen maximalen Protokollierungspegeln hat.
$SYSTEMD_LOG_COLOR
Ein boolescher Wert. Wenn dies der Fall ist, werden Nachrichten, die in das TTY geschrieben werden, gemäß ihrer Priorität farblich hervorgehoben.
Diese Einstellung ist nur dann nützlich, wenn Nachrichten direkt in das Terminal geschrieben werden, da [journalctl]({filename}../../journalctl)(1) und andere Tools, die Protokolle anzeigen, Nachrichten basierend auf dem Protokollierungslevel selbst farblich hervorheben.
$SYSTEMD_LOG_TIME
Ein boolescher Wert. Wenn dies der Fall ist, werden Konsolenprotokollnachrichten mit einem Zeitstempel versehen.
Diese Einstellung ist nur dann nützlich, wenn Nachrichten direkt in ein Terminal oder eine Datei geschrieben werden, da [journalctl]({filename}../../journalctl)(1) und andere Tools, die Protokolle anzeigen, Zeitstempel basierend auf den Metadaten des Eintrags anhängen.
$SYSTEMD_LOG_LOCATION
Ein boolescher Wert. Wenn dies der Fall ist, werden Nachrichten mit dem Dateinamen und der Zeilennummer in dem Quellcode versehen, aus dem die Nachricht stammt.
Beachten Sie, dass der Speicherort des Protokolls häufig als Metadaten an Journaleinträge angehängt wird. Das Einfügen in den Nachrichtentext kann jedoch dennoch beim Debuggen von Programmen nützlich sein.
$SYSTEMD_LOG_TARGET
Das Ziel für Protokollnachrichten. Eines von: console (Protokollierung in das angeschlossene TTY), console-prefixed (Protokollierung in das angeschlossene TTY, aber mit Präfixen, die das Protokollierungslevel und die „Facility“ kodieren, siehe syslog(3), kmsg (Protokollierung im Kernel-Ringpuffer), journal (Protokollierung im Journal), journal-or-kmsg (Protokollierung im Journal, falls verfügbar, und andernfalls in kmsg), auto (automatisches Bestimmen des geeigneten Protokollierungsziels, Standard), null (Deaktivieren der Protokollausgabe).
$SYSTEMD_PAGER, $PAGER
Paginierungsprogramm, das verwendet wird, wenn --no-pager nicht angegeben ist. $SYSTEMD_PAGER wird verwendet, falls es gesetzt ist; andernfalls wird $PAGER verwendet. Wenn weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe bekannter Paginierungsprogramme nacheinander ausprobiert, darunter less(1) und more(1), bis eines gefunden wird. Wenn kein Paginierungsprogramm gefunden wird, wird kein Paginierungsprogramm aufgerufen. Das Setzen dieser Umgebungsvariablen auf eine leere Zeichenkette oder den Wert "cat" entspricht der Verwendung von --no-pager.
Hinweis: Wenn $SYSTEMD_PAGERSECURE nicht gesetzt ist, können $SYSTEMD_PAGER und $PAGER nur verwendet werden, um die Paginierung zu deaktivieren (mit "cat" oder ""), andernfalls werden sie ignoriert.
$SYSTEMD_LESS
Überschreibt die an less übergebenen Optionen (standardmäßig "FRSXMK").
Benutzer möchten möglicherweise zwei Optionen insbesondere ändern:
K
Diese Option weist das Paginierungsprogramm an, beim Drücken von Strg+C sofort zu beenden. Um less zu ermöglichen, Strg+C selbst zu verarbeiten, um zur Paginierungsbefehlseingabe zurückzukehren, diese Option aufheben.
Wenn der Wert von $SYSTEMD_LESS "K" nicht enthält und das aufgerufene Paginierungsprogramm less ist, wird Strg+C vom ausführbaren Programm ignoriert und muss vom Paginierungsprogramm verarbeitet werden.
X
Diese Option weist das Paginierungsprogramm an, keine Terminal-Initialisierungs- und -Deinitialisierungszeichenketten an das Terminal zu senden. Standardmäßig ist diese Option gesetzt, damit die Befehlsausgabe auch nach dem Beenden des Paginierungsprogramms im Terminal sichtbar bleibt. Dies verhindert jedoch einige Funktionen des Paginierungsprogramms, insbesondere kann die paginierte Ausgabe nicht mit der Maus gescrollt werden.
Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESS keine Auswirkungen auf die Aufrufe von less durch Systemd-Tools hat.
Siehe less(1) für weitere Informationen.
$SYSTEMD_LESSCHARSET
Überschreibt die an less übergebene Zeichenkodierung (standardmäßig "utf-8", wenn das aufrufende Terminal als UTF-8-kompatibel erkannt wird).
Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESSCHARSET keine Auswirkungen auf die Aufrufe von less durch Systemd-Tools hat.
$SYSTEMD_PAGERSECURE
Gängige Paginierungsprogramme wie less(1) unterstützen neben der "Paginierung", d. h. dem Scrollen durch die Ausgabe, auch das Öffnen oder Schreiben anderer Dateien und das Ausführen beliebiger Shell-Befehle. Wenn Befehle mit erhöhten Rechten aufgerufen werden, z. B. unter sudo(8) oder pkexec(1), wird das Paginierungsprogramm zu einer Sicherheitsgrenze. Es muss darauf geachtet werden, dass nur Programme mit streng begrenzter Funktionalität als Paginierungsprogramme verwendet werden, und dass unbeabsichtigte interaktive Funktionen wie das Öffnen oder Erstellen neuer Dateien oder das Starten von Unterprozessen nicht zulässig sind. Der "sichere Modus" für das Paginierungsprogramm kann wie unten beschrieben aktiviert werden, wenn das Paginierungsprogramm dies unterstützt (die meisten Paginierungsprogramme sind nicht so geschrieben, dass dies berücksichtigt wird). Es wird empfohlen, entweder explizit den "sicheren Modus" zu aktivieren oder die Paginierung mit --no-pager oder PAGER=cat vollständig zu deaktivieren, wenn nicht vertrauenswürdige Benutzer Befehle mit erhöhten Rechten ausführen dürfen.
Diese Option nimmt ein boolesches Argument entgegen. Wenn sie auf „true“ gesetzt ist, wird der „sichere Modus“ des Pagers aktiviert.
Im „sicheren Modus“ wird bei der Aufruf des Pagers LESSSECURE=1 gesetzt, wodurch der Pager angewiesen wird, Befehle zu deaktivieren, die neue Dateien öffnen oder erstellen oder neue Unterprozesse starten.
Derzeit ist nur less(1) bekannt, der diese Variable versteht und den „sicheren Modus“ implementiert.
Wenn sie auf „false“ gesetzt ist, werden keine Einschränkungen für den Pager vorgenommen. Das Setzen von SYSTEMD_PAGERSECURE=0 oder das Nicht-Entfernen aus der geerbten Umgebung kann es dem Benutzer ermöglichen, beliebige Befehle auszuführen.
Wenn $SYSTEMD_PAGERSECURE nicht gesetzt ist, versuchen die Systemd-Tools, automatisch zu bestimmen, ob der „sichere Modus“ aktiviert werden soll und ob der Pager ihn unterstützt. Der „sichere Modus“ wird aktiviert, wenn die effektive UID nicht mit der des Besitzers der Anmeldesitzung übereinstimmt, siehe geteuid(2) und sd_pid_get_owner_uid(3), oder wenn unter sudo(8) oder ähnlichen Tools ($SUDO_UID gesetzt ist [4]) ausgeführt wird. In diesen Fällen wird SYSTEMD_PAGERSECURE=1 gesetzt und Pager, die den „sicheren Modus“ nicht implementieren, werden überhaupt nicht verwendet. Beachten Sie, dass diese automatische Erkennung nur die gängigsten Mechanismen zur Privilegienerweiterung abdeckt und als Komfortfunktion gedacht ist. Es wird empfohlen, $SYSTEMD_PAGERSECURE explizit zu setzen oder den Pager zu deaktivieren.
Beachten Sie, dass, wenn die Variablen $SYSTEMD_PAGER oder $PAGER verwendet werden sollen, außer um den Pager zu deaktivieren, auch $SYSTEMD_PAGERSECURE gesetzt werden muss.
^ SYSTEMD_COLORS
Nimmt ein boolesches Argument entgegen. Wenn „true“, verwenden Systemd und zugehörige Dienstprogramme Farben in ihrer Ausgabe; andernfalls ist die Ausgabe monochrom. Darüber hinaus kann die Variable einen der folgenden speziellen Werte annehmen: „16“, „256“, um die Verwendung von Farben auf die Basis-16- bzw. 256-ANSI-Farben zu beschränken. Dies kann angegeben werden, um die automatische Entscheidung basierend auf $TERM und der Verbindung zum Terminal zu überschreiben.
^ SYSTEMD_URLIFY
Der Wert muss boolesch sein. Steuert, ob in der Ausgabe für Terminalemulatoren, die dies unterstützen, anklickbare Links generiert werden sollen. Dies kann angegeben werden, um die Entscheidung, die Systemd basierend auf $TERM und anderen Bedingungen trifft, zu überschreiben.
SIEHE AUCH
systemd(1), journalctl(1), loginctl(1), machinectl(1), systemd.unit(5), systemd.resourcecontrol(5), systemd.special(7), wall(1), systemd.preset(5), systemd.generator(7), glob(7)
HINWEISE
UAPI.1 Boot Loader Specification
https://uapi-group.org/specifications/specs/boot_loader_specification
UAPI.2 Discoverable Partitions Specification
https://uapi-group.org/specifications/specs/discoverable_partitions_specification
LSB 3.0.0
http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html
Es wird empfohlen, dass andere Tools $SUDO_UID bei Bedarf setzen und überprüfen und es als gemeinsame Schnittstelle behandeln.