table of contents
- bookworm 4.18.1-1
- bookworm-backports 4.24.0-2~bpo12+1
- testing 4.24.0-2
- unstable 4.25.0-1
| SYSTEMCTL(1) | systemctl | SYSTEMCTL(1) |
BEZEICHNUNG¶
systemctl - Steuerung des Systemd-Systems und des Diensteverwalters
ÜBERSICHT¶
systemctl [OPTIONEN…] BEFEHL [UNIT…]
BESCHREIBUNG¶
systemctl kann zum Prüfen und Steuern des Zustandes des »Systemd«-Systems und -Diensteverwalters verwandt werden. Bitte lesen Sie systemd(1) für eine Einführung in die grundlegenden Konzepte und Funktionalitäten, die dieses Werkezeug verwaltet.
BEFEHLE¶
Die folgenden Befehle werden verstanden:
Unit-Befehle (Untersuchung und Veränderung)¶
list-units [MUSTER…]
Beachten Sie, dass dieser Befehl keine Unit-Vorlagen zeigt, sondern nur Instanzen von Unit-Vorlagen. Unit-Vorlagen, die nicht instanziiert sind, können nicht ausgeführt werden und werden daher niemals in der Ausgabe dieses Befehls auftauchen. Konkret bedeutet dies, dass foo@.service niemals in dieser Liste angezeigt wird – außer instanziiert, d.h. als foo@bar.service. Verwenden Sie list-unit-files (siehe unten), um installierte Unit-Vorlagendateien aufzulisten.
Produziert eine Ausgabe ähnlich zu
UNIT LOAD ACTIVE SUB DESCRIPTION
sys-module-fuse.device loaded active plugged /sys/module/fuse
-.mount loaded active mounted Root Mount
boot-efi.mount loaded active mounted /boot/efi
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running Login Service ● user@1000.service loaded failed failed User Manager for UID 1000
…
systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 123 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'.
Die Kopfzeilen und die letzte Unit des angegebenen Typs werden unterstrichen, falls das Terminal dies unterstützt. Ein farbiger Punkt wird neben den Diensten, die maskiert, nicht gefunden oder sonstwie fehlgeschlagen sind, angezeigt.
Die Spalte LOAD zeigt den Ladezustand, einen aus loaded, not-found, bad-setting, error, masked. Die Spalte ACTIVE zeigt den allgemeinen Unit-Zustand, einen aus active, reloading, inactive, failed, activating, deactivating. Die Spalte SUB zeigt den Unit-Typ-spezifischen detaillierten Zustand der Unit, mögliche Werte hängen vom Unit-Typ ab. Die Liste der möglichen LOAD-, ACTIVE- und SUB-Zustände ist nicht konstant und neue Systemd-Veröffentlichungen können sowohl Werte hinzufügen als auch welche entfernen.
systemctl --state=help
Der Befehl kann zur Anzeige der aktuell möglichen Menge von Werten verwandt werden.
Dies ist der Standardbefehl.
list-automounts [MUSTER…]
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 automounts listed.
Siehe auch --show-types, --all und --state=.
list-paths [MUSTER…]
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 paths listed.
Siehe auch --show-types, --all und --state=.
list-sockets [MUSTER…]
LISTEN UNIT ACTIVATES /dev/initctl systemd-initctl.socket systemd-initctl.service ... [::]:22 sshd.socket sshd.service kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service 5 sockets listed.
Beachten Sie: Da die Adressen Leerzeichen enthalten können, ist diese Ausgabe nicht für die programmatische Verarbeitung geeignet.
Siehe auch --show-types, --all und --state=.
list-timers [MUSTER…]
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 die nächste Zeit, zu der der Timer läuft.
LEFT zeigt die Zeitdauer, bis der Timer das nächste Mal läuft.
LAST zeigt die Zeit, zu der der Timer das letzte Mal lief.
PASSED zeigt, welche Zeit vergangen ist, seitdem der Timer letztmalig lief.
UNIT zeigt den Namen des Timers
ACTIVATES zeigt den Namen des Dienstes, den der Timer beim Laufen aktiviert.
Siehe auch --all und --state=.
is-active MUSTER…
is-failed MUSTER…
status [MUSTER…|PID…]]
Diese Funktion ist zur Erstellung menschenlesbarer Ausgabe gedacht. Falls Sie nach Computer-auswertbarer Ausgabe suchen, verwenden Sie stattdessen show. Standardmäßig zeigt diese Funktion nur die letzten 10 Ausgabezeilen und verkürzte Zeilen, um in das Terminal-Fenster zu passen. Dies kann mit --lines und --full geändert werden, siehe oben. Zusätzlich verwenden journalctl --unit=NAME oder journalctl --user-unit=NAME einen ähnlichen Filter für Nachrichten und könnten praktischer sein.
Beachten Sie, dass diese Aktion nur den Laufzeit-Status anzeigt, d.h. Informationen über den aktuellen Aufruf der Unit (falls sie läuft) oder den letzten Aufruf (falls sie nicht mehr läuft und noch nicht vom Speicher freigegeben wurde). Informationen über frühere Aufrufe, Aufrufe von vorhergehenden Systemstarts oder frühere Aufrufe, bei denen bereits der Speicher freigegeben wurde, könnten mittels journalctl --unit= abgerufen werden.
Systemd lädt Units implizit nach Notwendigkeit, daher wird die reine Ausführung von status versuchen, eine Datei zu laden. Der Befehl ist daher nicht nützlich, um zu bestimmen, ob etwas bereits geladen war oder nicht. Die Units könnten sich auch schnell entladen, nachdem die Aktion abgeschlossen ist, falls es keinen Grund gibt, sie danach im Speicher zu halten.
Beispiel 1. Beispielausgabe von systemctl status
$ systemctl status bluetooth ● bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
Active: active (running) since Wed 2017-01-04 13:54:04 EST; 1 weeks 0 days ago
Docs: man:bluetoothd(8)
Main PID: 930 (bluetoothd)
Status: "Running"
Tasks: 1
Memory: 648.0K
CPU: 435ms
CGroup: /system.slice/bluetooth.service
└─930 /usr/lib/bluetooth/bluetoothd Jan 12 10:46:45 example.com bluetoothd[8900]: Not enough free handles to register service Jan 12 10:46:45 example.com bluetoothd[8900]: Current Time Service could not be registered Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output error (5)
Der Punkt (»●«) verwendet auf unterstützten Terminals Farbe, um den Unit-Zustand auf einen Blick zusammenzufassen. Zusammen mit seiner Farbe ändert sich die Form entsprechend seines Zustandes: »inaktiv« oder »Wartung« ist ein weißer Kreis (»○«), »aktiv« ist ein grüner Punkt (»●«), »Deaktivierend« ist ein weißer Punkt, »Fehlgeschlagen« oder »Fehler« ist ein rotes Kreuz (»×«) und »Neuladend« ist ein grüner Kreispfeil im Uhrzeigersinn (»↻«).
Die Zeile »Loaded:« in der Ausgabe wird »loaded« anzeigen, falls die Unit in den Speicher geladen wurde. Andere mögliche Werte für »Loaded:« sind u.A.: »error«, falls es ein Problem beim Laden gab, »not-found«, falls für diese Unit keine Unit-Datei gefunden wurde, »bad-setting«, falls eine essenzielle Unit-Datei-Einstellung nicht ausgewertet werden konnte und »masked«, falls die Unit-Datei maskiert wurde. Zusammen mit dem Pfad zu der Unit-Datei wird diese Zeile auch den Freigabezustand anzeigen. Freigegebene Units werden in das Abhängigkeitsnetzwerk zwischen Units aufgenommen und daher beim Systemstart oder über andere Art der Aktivierung gestartet. Lesen Sie die vollständige Tabelle der möglichen Freigabezustände — einschließlich der Definition von »masked« in der Dokumentation für den Befehl »is-enabled«.
Die Zeile »Active:« zeigt den aktiven Zustand. Der Wert ist normalerweise »active« oder »inactive«. Aktiv kann gestartet, gebunden, eingesteckt usw., abhängig vom Unit-Typ, sein. Die Unit könnte auch gerade dabei sein, ihre Zustände zu ändern und einen Zustand »activating« oder »deactivating« melden. Ein besonderer Zustand »failed« wird erreicht, wenn der Zustand auf irgendeine Art, z.B. durch einen Absturz, der Beendigung mit einem Fehler-Code oder einer Zeitüberschreitung, fehlgeschlagen ist. Falls ein Fehlerzustand erreicht wurde, wird der Grund protokolliert.
show [MUSTER…|AUFTRAG…]
Viele durch systemctl show gezeigte Eigenschaften können direkt auf Konfigurationseigenschaften des System- und Diensteverwalters und seiner Unit-Dateien abgebildet werden. Beachten Sie, dass die durch den Befehl angezeigten Eigenschaften im Allgemeinen systemnahe, normalisierte Versionen der ursprünglichen Konfigurationseinstellungen sind und zusätzlich zur Konfiguration Laufzeitzustand offenlegen. Eigenschaften für Dienste-Units enthalten beispielsweise die Kennzeichnung des aktuellen Hauptprozesses des Dienstes als »MainPID« (was Laufzeitzustand ist) und die Zeiteinstellungen werden immer als Eigenschaften, die in »…Sec« enden, offengelegt, da Mikrosekunden die vom System- und Diensteverwalter intern verwandte normierte Zeiteinheit sind.
Für Details zu vielen dieser Eigenschaften lesen Sie die Dokumentation der diesen Eigenschaften zugrundeliegenden D-Bus-Schnittstellen, siehe org.freedesktop.systemd1(5).
cat MUSTER…
help MUSTER…|PID…
list-dependencies [UNIT…]
Die angezeigten Units werden zusätzlich durch --type= und --state= gefiltert, falls diese Optionen angegeben wurden. Beachten Sie, dass in diesem Fall keine Baumstruktur verwandt werden kann, daher wird --plain impliziert.
Standardmäßig werden nur Ziel-Units rekursiv expandiert. Wenn --all übergeben wird, werden auch alle anderen Units rekursiv expandiert.
Die Optionen --reverse, --after, --before können zur Änderung, welche Abhängigkeitsarten gezeigt werden, verwandt werden.
Beachten Sie, dass dieser Befehl nur die derzeit durch den Diensteverwalter im Speicher geladenen Units aufführt. Insbesondere ist dieser Befehl nicht dazu geeignet, eine vollständige Liste aller inversen Abhängigkeiten einer bestimmten Unit zu erhalten, da es nicht die von Units erklärten Abhängigkeiten aufführt, die derzeit nicht geladen sind.
start MUSTER…
Beachten Sie, dass Unit-Glob-Muster auf die Namen der Units, die momentan im Arbeitsspeicher sind, expandieren. Units, die nicht aktiv und nicht in einem fehlgeschlagenen Zustand sind, sind normalerweise nicht im Speicher und es wird kein Muster auf sie passen. Bei instanziierten Units ist Systemd zusätzlich oft in Unkenntnis über den Instanzennamen, bis die Instanz gestartet wurde. Daher hat die Verwendung von Glob-Mustern mit start nur begrenzten Nutzen. Auch werden sekundäre Alias-Namen von Units nicht berücksichtigt.
Die Option --all kann auch zum Einsatz auf inaktive Units, die von anderen geladenen Units referenziert werden, verwandt werden. Beachten Sie, dass dies nicht identisch zum Einsatz auf »alle« möglichen Units ist, da diese Liste nicht korrekt definiert ist, wie im vorherigen Absatz beschrieben. Dennoch mag systemctl start --all GLOB nützlich sein, falls alle Units, die auf das Muster passen, durch ein Ziel hereingezogen werden, welches bekanntermaßen geladen wird.
stop MUSTER…
Dieser Befehl wird fehlschlagen, falls die Unit nicht existiert oder falls das Stoppen der Unit verboten ist (siehe RefuseManualStop= in systemd.unit(5)). Er wird nicht fehlschlagen, falls einer der für das Stoppen der Unit konfigurierten Befehle ((ExecStop= usw.) fehlschlägt, da der Verwalter dennoch die Unit zwangsweise beenden wird.
Falls eine Unit, die gestoppt wird, von anderen Units ausgelöst wird, wird eine Warnung angezeigt, die die Namen der auslösenden Units enthält. Diese Warnung kann mit --no-warn unterdrückt werden.
reload MUSTER…
Dieser Befehl sollte nicht mit dem Befehl daemon-reload verwechselt werden.
restart MUSTER…
Beachten Sie, dass das Neustarten einer Unit mit diesem Befehl nicht notwendigerweise alle Ressourcen der Unit herrausschreibt, bevor sie neu gestartet wird. Beispielsweise wird die Dienste-bezogene Dateideskriptorspeichereinrichtung (siehe FileDescriptorStoreMax= in systemd.service(5)) intakt bleiben, solange ein Auftrag in der Unit wartet und wird nur bereinigt, wenn die Unit komplett gestoppt wird und keine Aufträge mehr warten. Falls gewünscht ist, dass der Dateideskriptorspeicher auch rausgeschrieben wird, dann sollte während der Neustartaktion ein expliziter Befehl systemctl stop gefolgt von systemctl start eingegeben werden.
try-restart MUSTER…
reload-or-restart MUSTER…
try-reload-or-restart MUSTER…
isolate UNIT
Dieser Befehl ist gefährlich, da er sofort Prozesse stoppen wird, die in dem neuen Ziel nicht freigegeben sind, möglicherweise einschließlich der graphischen Umgebung oder des Terminals, das Sie gerade benutzen.
Beachten Sie, dass diese Aktion nur auf Units erlaubt ist, bei denen AllowIsolate= aktiviert ist. Siehe systemd.unit(5) für Details.
kill MUSTER…
clean MUSTER…
freeze MUSTER…
Einfrieren einer Unit führt dazu, dass alle Prozesse in der der Unit entsprechenden Cgroup suspendiert werden. Suspendiert sein bedeutet, dass die Prozesse der Unit nicht zur Ausführung auf einer CPU eingeplant werden, bis die Unit aufgetaut wird. Beachten Sie, dass dieser Befehl nur auf Systemen unterstützt wird, die die vereinigte Cgroup-Hierarchie verwenden. Die Unit wird automatisch aufgetaut, genau bevor ein Auftrag gegen die Unit ausgeführt wird, z.B. bevor die Unit gestoppt wird.
thaw MUSTER…
Dies ist die inverse Aktion zum Befehl freeze und nimmt die Ausführung von Prozessen in der Cgroup der Unit wieder auf.
set-property UNIT EIGENSCHAFT=WERT…
Beispiel: systemctl set-property foobar.service CPUWeight=200
Falls die angegebene Unit-Datei inaktiv zu sein scheint, werden die Änderungen nur wie früher beschrieben auf Platte gespeichert, daher werden sie erst beim Starten der Unit zur Geltung kommen.
Beachten Sie, dass dieser Befehl das Ändern mehrerer Eigenschaften auf einmal erlaubt, was gegenüber der individuellen Einstellung bevorzugt werden sollte.
Beispiel: systemctl set-property foobar.service CPUWeight=200 MemoryMax=2G IPAccounting=yes
Wie bei Unit-Konfigurationseinstellungen führt die Zuweisung der leeren Einstellung normalerweise zum Zurücksetzen einer Eigenschaft auf ihre Vorgaben.
Beispiel: systemctl set-property avahi-daemon.service IPAddressDeny=
bind UNIT PFAD [PFAD]
Beachten Sie, dass diese Option zur Zeit nur für Units unterstützt wird, die innerhalb eines Einhängenamensraums ausgeführt werden (z.B.: mit RootImage=, PrivateMounts= usw.). Dieser Befehl unterstützt die Bind-Einhängung von Verzeichnissen, regulären Dateien, Geräteknoten, AF_UNIX-Socket-Knoten sowie FIFOs. Die Bind-Einhängung ist flüchtig und wird sofort zurückgenommen, sobald sich die Prozesse der aktuellen Unit beenden. Beachten Sie, dass der hier erwähnte Namensraum, zu dem die Bind-Einhängung hinzugefügt wird, derjenige ist, in dem der Hauptdiensteprozess ausgeführt wird. Andere Prozesse (die von ExecReload=, ExecStartPre= usw. ausgeführt werden) laufen in einem dedizierten Namensraum.
mount-image UNIT ABBILD [PFAD [PARTITIONSNAME:EINHÄNGEOPTIONEN]]
Beachten Sie, dass diese Option zur Zeit nur für Units unterstützt wird, die innerhalb eines Einhängenamensraums ausgeführt werden (d.h. mit RootImage=, PrivateMounts= usw.). Beachten Sie, dass der hier erwähnte Namensraum, zu dem die Abbild-Einhängung hinzugefügt wird, derjenige ist, in dem der Hauptdiensteprozess ausgeführt wird. Beachten Sie, dass der hier erwähnte Namensraum, zu dem die Bind-Einhängung hinzugefügt wird, der ist, in dem der Hauptdiensteprozess läuft. Andere Prozesse (die von ExecReload=, ExecStartPre=, usw. ausgeführt werden), laufen in einem dedizierten Namensraum.
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
service-log-level DIENST [STUFE]
Falls das optionale Argument STUFE bereitgestellt wird, dann wird die aktuelle Protokollierstufe des Dienstes auf STUFE geändert. Die Protokollierstufe sollte eine typische Syslog-Protokollierstufe 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 Dienst muss über die geeignete Eigenschaft BusName=Ziel verfügen und auch die generische Schnittstelle org.freedesktop.LogControl1(5) implementieren. (Systemctl wird das generische D-Bus-Protokoll zum Zugriff auf die Schnittstelle org.freedesktop.LogControl1.LogLevel für den D-Bus-Namen Ziel verwenden.)
service-log-target DIENST [ZIEL]
Falls das optionale Argument ZIEL bereitgestellt wird, dann wird das aktuelle Protokollierziel des Dienstes auf ZIEL geändert. Das Protokollierziel sollte eine der Zeichenketten console (für das Protokollieren in den Standardfehlerausgabestroms des Dienstes), kmsg (für das Protokollieren in den Kernelprotokollpufer), journal (für das Protokollieren nach systemd-journald.service(8) mittels des nativen Journal-Protokolls), syslog (für das Protokollieren in das klassische Syslog-Socket /dev/log), null (für keine Protokollierung) oder auto (für eine automatisch bestimmte Auswahl, typischerweise äquivalent zu console, falls der Dienst interaktiv aufgerufen wurde und andernfalls journal oder syslog) sein.
Für die meisten Dienste ergeben nur eine kleine Teilmenge der Protokollierziele Sinn. Insbesondere sollten »normale« Dienste nur console, journal und null implementieren. Alles andere ist nur für systemnahe Dienste angemessen, die in der sehr frühen Systemstartphase aktiv sind, bevor korrekte Protokollierung etabliert ist.
Der Dienst muss über die geeignete Eigenschaft BusName=Ziel verfügen und auch die generische Schnittstelle org.freedesktop.LogControl1(5) implementieren. (Systemctl wird das generische D-Bus-Protokoll zum Zugriff auf die Schnittstelle org.freedesktop.LogControl1.LogLevel für den D-Bus-Namen Ziel verwenden.)
reset-failed [MUSTER…]
Zusätzlich zum Zurücksetzen des Status »failed« einer Unit setzt dies auch verschiedene andere Unit-bezogene Eigenschaften zurück: der Startratenbegrenzungszähler aller Unit-Typen wird auf Null zurückgesetzt, wie auch der Neustartzähler von Dienste-Units. Falls daher die Startbegrenzung (wie mit StartLimitIntervalSec=/StartLimitBurst= konfiguriert) einer Unit erreicht wird und die Unit es ablehnt, erneut gestartet zu werden, verwenden Sie diesen Befehl, um sie wieder startbar zu bekommen.
whoami [PID…]
Unit-Dateibefehle¶
list-unit-files [MUSTER…]
Anders als list-units wird dieser Befehl zusätzlich zu den explizit instanziierten Units Vorlagenunits auflisten.
enable UNIT…, enable PFAD…
Dieser Befehl erwartet entweder gültige Unit-Namen (in diesem Fall werden verschiedene Unit-Datei-Verzeichnisse automatisch nach Unit-Dateien mit geeigneten Namen durchsucht) oder absolute Pfade zu Unit-Dateien (in diesem Fall werden die Dateien direkt eingelesen). Falls eine angegebene Unit-Datei sich außerhalb der gewöhnlichen Unit-Dateiverzeichnisse befindet, wird ein zusätzlicher Symlink erstellt, der sie in den Unit-Konfigurationspfad verlinkt, und daher sicherstellt, dass sie durch Befehle wie start gefunden wird. Das Dateisystem, in dem sich die verlinkten Unit-Dateien befinden, muss verfügbar sein, wenn Systemd gestartet wird (z.B. ist alles unterhalb von /home/ oder /var/ nicht erlaubt, außer diese Verzeichnisse befinden sich auf dem Wurzeldateisystem).
Dieser Befehl wird die ausgeführten Dateisystemaktionen ausgeben. Diese Ausgabe kann durch Übergabe von --quiet unterdrückt werden.
Beachten Sie, dass diese Aktion nur die in dem Abschnitt »[Install]« der Unit-Dateien vorgeschlagenen Symlinks erstellt. Obwohl dieser Befehl die empfohlene Art ist, das Unit-Konfigurationsverzeichnis zu bearbeiten, steht es dem Administrator frei, manuell zusätzliche Änderungen vorzunehmen, indem er in diesem Verzeichnis Symlinks anlegt oder entfernt. Dies ist besonders nützlich, um Konfigurationen zu erstellen, die von den vorgeschlagenen Standardinstallationen abweichen. In diesem Falle muss der Administrator sicherstellen, daemon-reload wo notwendig aufzurufen, um sicherzustellen, dass die Änderungen berücksichtigt werden.
Wird diese Aktion auf Units ohne Installationsinformationen angewandt, wird daüber eine Warnung angezeigt. Diese Warnung kann mit --no-warn unterdrückt werden.
Freigeben von Units sollte nicht mit dem Starten (Aktivieren) verwechselt werden, wie dies durch den Befehl start erfolgt. Freigeben und starten von Units ist orthogonal: Units können freigegeben sein, ohne gestartet zu sein und gestartet, ohne freigegeben zu sein. Die Freigabe hängt die Unit an verschiedenen vorgeschlagenen Stellen ein (beispielsweise so, dass die Unit automatisch beim Systemstart gestartet wird oder wenn ein bestimmte Art von Hardware eingesteckt wird). Starten führt den Daemon-Prozess tatsächlich aus (im Falle von Dienste-Units) oder bindet das Socket (im Falle von Socket-Units) und so weiter.
Abhängig davon ob --system, --user, --runtime oder --global angegeben wurde, gibt dies die Unit für das System, nur den aufrufenden Benutzer, nur für diesen Systemstart oder für alle zukünftigen Anmeldungen aller Benutzer frei. Beachten Sie, dass in letzterem Fall keine Systemd-Daemonkonfiguration neu geladen wird.
Die Verwendung von enable auf maskierten Units wird nicht unterstützt und führt zu einem Fehler.
disable UNIT…
Dieser Befehl erwartet nur gültige Unit-Namen, er akzeptiert keine Pfade zu Unit-Dateien.
Zusätzlich zu den als Argument angegebenen Unit-Dateien werden alle Units ausgeschaltet, die in der in Abschnitt »[Install]« aufgeführten Einstellung Also= in jeder der Unit-Dateien, auf die agiert wird, enthalten sind.
Dieser Befehl lädt implizit die Systemverwalterkonfiguration nach Abschluss der Aktion neu. Beachten Sie, dass dieser Befehl die ausgeschalteten Units nicht implizit stoppt. Falls dies gewünscht ist, kombinieren Sie diesen Befehl entweder mit dem Schalter --now oder rufen Sie den Befehl stop mit geeigneten Argumenten später auf.
Dieser Befehl wird Informationen über die ausgeführten Dateisystemaktionen (Entfernung der Symlinks) ausgeben. Durch Übergabe von --quiet kann diese Ausgabe unterdrückt werden.
Falls eine Unit deaktiviert wird, aber ihre auslösenden Units immer noch aktiv sind, wird eine Warnung angezeigt, die die Namen der auslösenden Units enthält. Diese Warnung kann mit --no-warn unterdrückt werden.
Wird dieser Befehl zusammen mit --user verwandt, könnten die Units, auf denen agiert wird, in einem globalen Bereich dennoch aktiviert und daher automatisch gestartet werden, selbst wenn sie im Benutzerbereich automatisch deaktiviert wurden. In diesem Fall wird eine Warnung dazu ausgegeben, die mittels --no-warn unterdrückt werden kann.
Dieser Befehl berücksichtigt --system, --user, --runtime, --global und --no-warn auf eine ähnliche Art wie enable.
reenable UNIT…
preset UNIT…
Verwenden Sie --preset-mode=, um zu steuern, ob Units freigegeben und ausgeschaltet oder nur freigegeben oder nur ausgeschaltet sein sollen.
Falls die Unit keine Installationsinformationen überträgt, wird sie durch diesen Befehl ohne Rückmeldung ignoriert. UNIT muss ein echter Unit-Name sein, jeder Aliasname wird ohne Rückmeldung ignoriert.
Weitere Informationen über das Format der Voreinstellungsrichtlinien finden Sie unter systemd.preset(5).
preset-all
Verwenden Sie --preset-mode=, um zu steuern, ob Units freigegeben und ausgeschaltet oder nur freigegeben oder nur ausgeschaltet sein sollen.
is-enabled UNIT…
Tabelle 1. Ausgabe von is-enabled
| Name | Beschreibung | Exit-Code |
| "enabled" | Über .wants/, .requires/ oder Alias=-Symlinks freigegeben (dauerhaft in /etc/systemd/system/ oder flüchtig in /run/systemd/system/). | 0 |
| "enabled-runtime" | ||
| "linked" | Über einen oder mehrere Symlinks auf die Unit-Datei verfügbar gemacht (dauerhaft in /etc/systemd/system/ oder flüchtig in /run/systemd/system/), obwohl die Unit-Datei selbst außerhalb des Unit-Dateisuchpfades liegen kann. | > 0 |
| "linked-runtime" | ||
| "alias" | Der Name ist ein Alias (Symlink auf eine andere Unit-Datei). | 0 |
| "masked" | Komplett ausgeschaltet, so dass jede Startaktion darauf fehlschlägt (dauerhaft in /etc/systemd/system/ oder flüchtig in /run/systemd/systemd/). | > 0 |
| "masked-runtime" | ||
| "static" | Die Unit-Datei ist nicht freigegeben und hat keine Vorkehrungen für die Freigabe in dem Unit-Dateiabschnitt »[Install]«. | 0 |
| "indirect" | Die Unit-Datei selbst ist nicht freigegeben, hat aber etwas in der Einstellung Also= im Abschnitt »[Install]« der Unit-Datei, wo andere Unit-Dateien aufgeführt sind, die freigegeben werden können, oder sie hat einen Alias unter einem anderen Namen durch einen Symlink, der nicht auch in Also= angegeben ist. Für Vorlagen-Unit-Dateien ist eine Instanz, die sich von der in DefaultInstance= angegebenen unterscheidet, freigegeben. | 0 |
| "disabled" | Die Unit-Datei ist nicht freigegeben, enthält aber einen Abschnitt »[Install]« mit Installationsanweisungen. | > 0 |
| "generated" | Die Unit wurde dynamisch mit einem Generatorwerkzeug erstellt. Siehe systemd.generator(7). Erstellte Unit-Dateien können nicht freigegeben werden, sie werden implizit durch ihren Generator freigegeben. | 0 |
| "transient" | Die Unit-Datei wurde dynamisch mit der Laufzeit-API erstellt. Flüchtige Units können nicht freigegeben werden. | 0 |
| "bad" | Die Unit-Datei ist ungültig oder ein anderer Fehler ist aufgetreten. Beachten Sie, dass is-enabled diesen Zustand nicht tatsächlich zurückliefern wird, sondern stattdessen eine Fehlermeldung ausgeben wird. Die durch list-unit-files dargestellte Unit-Datei-Auflistung könnte sie allerdings enthalten. | > 0 |
| "not-found" | Die Unit-Datei existiert nicht. | 4 |
mask UNIT…
Beachten Sie, dass dies einen Symlink unter dem Namen der Unit in /etc/systemd/system/ (falls --runtime nicht angegeben ist) oder /run/systemd/system/ (falls --runtime angegeben ist) erstellt wird. Falls eine passende Unit-Datei unter diesen Verzeichnissen bereits existiert, wird diese Aktion daher fehlschlagen. Das bedeutet, dass diese Aktion primär zu askieren von Units nützlich ist, die vom Lieferanten ausgeliefert werden (da diese in /lib/systemd/system/ und nicht in den vorher erwähnten Verzeichnissen ausgeliefert werden), funktioniert aber typischerweise nicht für lokal erstellte Units (da diese typischerweise in den zwei vorher erwähnten Verzeichnissen abgelegt werden). Ähnliche Beschrkungen gelten für den Modus --user. In diesem Fall befinden sich die Verzeichnisse allerdings unterhalb des Home-Verzeichnis des Benutzers.
Falls eine Unit maskiert wird, aber ihre auslösenden Units noch aktiv sind, wird eine Warnung angezeigt, die die Namen der auslösenden Units enthält. Diese Warnung kann mit --no-warn unterdrückt werden.
unmask UNIT…
link PFAD…
revert UNIT…
Dieser Befehl kann effektiv dazu verwandt werden, alle mit systemctl edit, systemctl set-property und systemctl mask vorgenommenen Änderungen zurückzusetzen und alle ursprünglichen Unit-Dateien mit ihren Einstellungen wieder zur Wirkung zu bringen.
add-wants ZIEL UNIT…, add-requires ZIELUNIT…
Dieser Befehl berücksichtigt --system, --user, --runtime und --global auf eine ähnliche Art wie enable.
edit UNIT…
Abhängig davon, ob --system (die Vorgabe), --user, oder --global angegeben ist, erstellt dieser Befehl für jede Unit eine Ergänzungsdatei, entweder für das System, für den aufrufenden Benutzer oder für alle zukünftigen Anmeldungen aller Benutzer. Dann wird der Editor (siehe den Abschnitt »Umgebung« unten) mit temporären Dateien aufgerufen, die an den wirklichen Ort geschrieben werden, falls der Editor erfolgreich beendet wird.
Falls --drop-in= angegeben ist, wird der übergebene Ergänzungsdateiname statt des standardmäßigen override.conf verwandt.
Falls --full angegeben ist, wird diese die ursprüngliche Unit kopieren, statt Ergänzungsdateien zu erstellen.
Falls --force angegeben ist und eine der Units nicht existiert, werden neue Unit-Dateien für die Bearbeitung geöffnet.
Falls --runtime angegeben ist, wird die Änderung temporär in /run/ vorgenommen und geht beim nächsten Neustart verloren.
Falls die temporäre Datei beim Beenden leer ist, wird die Änderung der zugehörigen Unit abgebrochen.
Nachdem die Units bearbeitet wurden, wird die Systemd-Konfiguration neu geladen (auf eine Art, die äquivalent zu daemon-reload ist).
Beachten Sie, dass dieser Befehl nicht zur Bearbeitung ferner Units verwandt werden kann und dass Sie keine Units, die in /etc/ liegen, temporär bearbeiten können, da diese vor /run/ Vorrang haben.
get-default
set-default ZIEL
Maschinenbefehle¶
list-machines [MUSTER…]
Auftragsbefehle¶
list-jobs [MUSTER…]
Wird dies mit --after oder --before kombiniert, wird die Liste mit Informationen darüber angereichert, auf welchen anderen Auftrag jeder Auftrag wartet und welche anderen Aufträge auf ihn warten, siehe oben.
cancel [AUFTRAG…]
Umgebungsbefehle¶
systemd unterstützt einen Umgebungsblock, der an vom Systemverwalter erzeugte 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 starten. In den Variablenwerten sind die meisten Zeichen erlaubt, aber die gesamte Sequenz muss gültiges UTF-8 sein. (Beachten Sie, dass Steuerzeichen wie der Zeilenumbruch (NL), der Tabulator (TAB) oder das Maskierzeichen (ESC) gültiges ASCII und damit gültiges UTF-8 sind). Die Gesamtlänge des Umgebungsblocks ist auf den Wert _SC_ARG_MAX, der in sysconf(3) definiert ist, begrenzt.
show-environment
Beachten Sie, dass dies den effektiven Block zeigt, d.h. die Kombination aus den mittels der Konfigurationsdateien, der Umgebungsgeneratoren und IPC (d.h. mittels des nachfolgend beschriebenen set-environment) konfigurierten Umgebungsvariablen. Derzeit wird ein Unit-Prozess, der mittels fork(2) von diesem kombinierten Umgebungsblock abgetrennt wird, zusätzlich mit den Unit-bezogenen Umgebungsvariablen kombiniert, die für diesen Befehl nicht sichtbar sind.
set-environment VARIABLE=WERT…
Beachten Sie, dass dies auf einem Umgebungsblock agiert, der von dem durch den Diensteverwalter (aus dessen Konfiguration) und den Umgebungsgeneratoren konfigurierten Block getrennt ist. Wann immer ein Prozess aufgerufen wird, werden die zwei Blöcke kombiniert (auch unter Aufnahme der dienstebezogenen Umgebungsvariablen) und dieser an ihn übergeben. Der Unterbefehl show-environment wird die Kombination der Blöcke zeigen, siehe oben.
unset-environment VARIABLE…
Beachten Sie, dass dies auf einem Umgebungsblock agiert, der von dem durch den Diensteverwalter (aus dessen Konfiguration) und den Umgebungsgeneratoren konfigurierten Block getrennt ist. Wann immer ein Prozess aufgerufen wird, werden die zwei Blöcke kombiniert (auch unter Aufnahme der dienstebezogenen Umgebungsvariablen) und dieser an ihn übergeben. Der Unterbefehl show-environment wird die Kombinationen der Blöcke zeigen, siehe oben. Beachten Sie, dass dies bedeutet, dass dieser Befehl nicht dazu verwandt werden kann, Umgebungsvariablen zurückzusetzen, die in den Konfigurationsdateien des Diensteverwalters oder mittels Generatoren definiert wurden.
import-environment VARIABLE…
Der Import des vollständigen ererbten Umgebungsblocks (der Aufruf dieses Befehls ohne Argumente) ist als veraltet markiert. Eine Shell setzt Dutzende von Variablen, die nur lokal Sinn ergeben und nur für Prozesse gedacht sind, die Abkömmlinge der Shell sind. Solche Variablen sind im globalen Umgebungsblock für andere Prozesse verwirrend.
Zustandsbefehle für den Verwalter¶
daemon-reload
Dieser Befehl sollte nicht mit dem Befehl reload durcheinandergebracht werden.
daemon-reexec
log-level [STUFE]
log-target [ZIEL]
service-watchdogs [yes|no]
Systembefehle¶
is-system-running
Verwenden Sie --wait, um darauf zu warten, dass der Systemstartprozess abgeschlossen ist, bevor der aktuelle Zustand angezeigt und der angemessene Fehlerstatus zurückgeliefert wird. Falls --wait in Verwendung ist, werden die Zustände initializing oder starting nicht gemeldet, stattdessen wird der Befehl blockieren, bis ein späterer Zustand (wie running oder degraded) erreicht ist.
Tabelle 2. Ausgabe von is-system-running
| Name | Beschreibung | Exit-Code |
| initializing | Früher Systemstart, vor basic.target erreicht oder der Wartungs- Zustand betreten wurde. | > 0 |
| starting | Späte Startphase, bevor die Auftragswarteschlange erstmalig in den Leerlauf geht oder eines der Rettungsziele erreicht wird. | > 0 |
| running | Das System ist komplett betriebsbereit. | 0 |
| degraded | Das System ist betriebsbereit, aber eine oder mehrere Units sind fehlgeschlagen. | > 0 |
| maintenance | Das Rettungs- oder Notfallziel ist aktiv. | > 0 |
| stopping | Der Verwalter fährt sich herunter. | > 0 |
| offline | Der Verwalter läuft nicht. Insbesondere ist dies der Betriebszustand, falls ein inkompatibles Programm als Systemverwalter (PID 1) läuft. | > 0 |
| unknown | Der Betriebszustand konnte aufgrund von fehlenden Ressourcen oder einer anderen Fehlerursache nicht bestimmt werden. | > 0 |
default
rescue
emergency
halt
Falls mit --force kombiniert, wird das Herunterfahren aller laufenden Dienste übersprungen, alle Prozesse werden aber getötet und alle Dateisysteme ausgehängt oder nur lesbar eingehängt, sofort danach erfolgt das Anhalten des Systems. Falls --force zweimal angegeben ist, wird die Aktion sofort ausgeführt, ohne irgendeinen Prozess zu beenden oder ein Dateisystem auszuhängen. Dies kann zu Datenverlust führen. Beachten Sie, dass die Halt-Aktion von systemctl selbst ausgeführt wird, wenn --force zweimal angegeben wird und der Systemverwalter dann nicht kontaktiert wird. Dies bedeutet, dass der Befehl selbst dann erfolgreich sein sollte, wenn der Systemverwalter abgestürzt ist.
Falls mit --when= kombiniert, wird das Herunterfahren nach dem angegebenen Zeitstempel eingeplant. Und --when=cancel wird das Herunterfahren abbrechen.
poweroff
Dieser Befehl berücksichtigt --force und --when= auf eine ähnliche Art wie halt.
reboot
Dieser Befehl ist größtenteils zu systemctl start reboot.target --job-mode=replace-irreversibly --no-block äquivalent, gibt aber auch eine Wall-Nachricht an alle Benutzer aus. Dieser Befehl ist asynchron; er wird zurückkehren, nachdem die Neustart-Aktion in die Warteschlange eingereiht ist, ohne darauf zu warten, dass er abgeschlossen ist.
Falls der Schalter --reboot-argument= angegeben ist, wird er als optionales Argument an den Systemaufruf reboot(2) übergeben.
Die Optionen --boot-loader-entry=, --boot-loader-menu= und --firmware-setup können zur Auswahl, was nach einem Neustart erfolgen soll, verwandt werden. Für Details siehe die Beschreibung dieser Optionen.
Dieser Befehl berücksichtigt --force und --when= auf eine ähnliche Art wie halt.
kexec
Um einen Kernel zu laden, erfolgt eine Aufzählung gemäß der Systemlader-Spezifikation[1] und der Standard-Systemstarteintrag wird geladen. Damit dieser Schritt erfolgreich ist, muss das System UEFI verwenden und die Systemladereinträge geeignet konfiguriert sein. Zum Auflisten der Systemstarteinträge kann bootctl list verwandt werden, siehe bootctl(1).
Dieser Befehl ist asynchron; er wird zurückkehren, nachdem die Neustart-Aktion in die Warteschlange eingereiht ist, ohne darauf zu warten, dass er abgeschlossen ist.
Dieser Befehl berücksichtigt --force und --when= auf eine ähnliche Art wie halt.
soft-reboot
Dieser Befehl berücksichtigt --force und --when= auf eine ähnliche Art wie halt.
Diese Aktion startet nur den Anwendungsraum neu, der Kernel verbleibt laufend. Siehe systemd-soft-reboot.service(8) zu Details.
exit [EXIT-CODE]
Falls EXIT_CODE übergeben wurde, wird sich der Diensteverwalter mit dem angegebenen Exit-Code beenden.
switch-root [WURZEL [INIT]]
suspend
hibernate
hybrid-sleep
suspend-then-hibernate
Parametersyntax¶
Die oben aufgeführten Unit-Befehle akzeptieren entweder einen einzelnen Unit-Namen (als UNIT bezeichnet) oder mehrere Unit-Angaben (als MUSTER … bezeichnet). Im ersten Fall muss der Unit-Name mit oder ohne Endung angegeben werden. Falls die Endung nicht angegeben ist (der Unit-Name »abgekürzt« wurde), wird Systemctl eine geeignete Endung anhängen, standardmäßig ».service«, und typabhängige Endungen im Falle von Befehlen, die nur auf bestimmte Unit-Typen agieren. Beispielsweise sind
# systemctl start sshd
und
# systemctl start sshd.service
äquivalent, wie auch
# systemctl isolate default
und
# systemctl isolate default.target
Beachten Sie, dass der (absolute) Pfad zu den Geräteknoten automatisch in einen Geräte-Unit-Namen und andere (absolute) Pfade zu Einhänge-Unit-Namen umgewandelt werden.
# systemctl status /dev/sda # systemctl status /home
ist äquivalent zu:
# systemctl status dev-sda.device # systemctl status home.mount
Im zweiten Fall werden Shell-artige Globs mit den primären Namen aller derzeit im Speicher befindlichen Units abgeglichen; wörtliche Unit-Namen, mit oder ohne eine Endung, werden wie im ersten Fall behandelt. Das bedeutet, dass sich wörtliche Unit-Namen immer auf genau eine Unit beziehen, aber Globs auf null Units passen können, was nicht als Fehler betrachtet wird.
Glob-Muster verwenden fnmatch(3), daher werden normale Shell-artige Glob-Regeln verwandt und »*«, »?« und »[]« dürfen verwendet werden. Siehe glob(7) für weitere Details. Die Muster werden mit den primären Namen der derzeit im Speicher befindlichen Units verglichen und Muster, die auf nichts passen, werden ohne Rückmeldung übersprungen. Beispielsweise wird
# systemctl stop sshd@*.service
alle sshd@.service-Instanzen stoppen. Beachten Sie, dass Aliasnamen von Units und Units, die sich nicht im Speicher befinden, für die Glob-Erweiterung nicht berücksichtigt werden.
Für Unit-Dateibefehle sollte die angegebene UNIT der Name der Unit-Datei (möglicherweise abgekürzt, siehe oben) oder der absolute Pfad zu der Unit-Datei sein:
# systemctl enable foo.service
oder
# systemctl link /path/to/foo.service
OPTIONEN¶
Die folgenden Optionen werden verstanden:
-t, --type=
Als Spezialfall wird eine Liste der erlaubten Werte angezeigt und das Programm beendet sich, falls eines der Argumente help ist.
--state=
Als Spezialfall wird eine Liste der erlaubten Werte angezeigt und das Programm beendet sich, falls eines der Argumente help ist.
-p, --property=
Für den Verwalter selbst wird systemctl show alle verfügbaren Eigenschaften anzeigen. Die meisten davon sind von den in systemd-system.conf(5) beschriebenen Optionen abgeleitet oder stimmen eng mit ihnen überein.
Eigenschaften für Units unterscheiden sich zwischen Unit-Typen, daher ist die Anzeige einer Unit (selbst einer nicht vorhandenen) ein Weg, um die Eigenschaften, die diese Unit betreffen, aufzulisten. Ähnlich wird die Anzeige eines Auftrags die allen Aufträgen zugehörigen Eigenschaften auflisten. Eigenschaften für Units sind in systemd.unit(5) und den Seiten für die individuellen Unit-Typen systemd.service(5), systemd.socket(5) usw. dokumentiert.
-P
-a, --all
Um alle im Dateisystem installierten Units aufzulisten, verwenden Sie stattdessen den Befehl list-unit-files.
Zeigt beim Auflisten von Units mit list-dependencies alle abhängigen Units rekursiv an (standardmäßig werden nur Abhängigkeiten von Ziel-Units angezeigt).
Zeigt bei der Verwendung mit status Journal-Nachrichten vollständig an, selbst falls sie nicht darstellbaren Zeichen enthalten oder sehr lang sind. Standardmäßig werden Felder mit nicht darstellbaren Zeichen als »blob data« abgekürzt«. (Beachten Sie, dass das Textanzeigeprogramm die nicht darstellbaren Zeichen wieder maskieren könnte.)
-r, --recursive
--reverse
--after
Beachten Sie, dass jede Abhängigkeit After= automatisch gespiegelt wird, um eine Abhängigkeit Before= zu erstellen. Temporäre Abhängigkeiten können explizit angegeben werden, werden aber auch implizit für Units mit den Zielen WantedBy= (siehe systemd.target(5)) und als Ergebnis von anderen Anweisungen (beispielsweise RequiresMountsFor=) erstellt. Sowohl explizit als auch implizit eingeführte Abhängigkeiten werden mit list-dependencies angezeigt.
Bei der Übergabe an den Befehl list-jobs wird für jeden dargestellten Auftrag angezeigt, welche anderen Aufträge auf ihn warten. Kann mit --before kombiniert werden, um sowohl die Aufträge, die auf jeden Auftrag warten, als auch alle Aufträge, auf die jeder Auftrag wartet anzuzeigen.
--before
Bei der Übergabe an den Befehl list-jobs wird für jeden dargestellten Auftrag angezeigt, auf welche anderen Aufträge er wartet. Kann mit --after kombiniert werden, um sowohl die Aufträge, die auf jeden Auftrag warten, als auch alle Aufträge, auf die jeder Auftrag wartet anzuzeigen.
--with-dependencies
Die Optionen --reverse, --after, --before können zur Änderung, welche Abhängigkeitsarten gezeigt werden, verwandt werden.
-l, --full
Zeigt auch Installationsziele in der Ausgabe von is-enabled an.
--value
--show-types
--job-mode=
Falls »fail« angegeben ist und die angeforderte Aktion in Konflikt mit einem anhängigen Auftrag steht (genauer: dazu führt, dass ein anhängiger Auftrag in einen Stopp-Auftrag oder umgedreht umgewandelt wird), wird die Aktion fehlschlagen.
Falls (die Vorgabe) »replace« angegeben ist, wird jeder in Konflikt stehende anhängige Auftrag falls notwendig ersetzt.
Falls »replace-irreversibly« angegeben ist, wird wie bei »replace« agiert, aber die neuen Aufträge als unumkehrbar markiert. Dies hindert zukünftige in Konflikt stehende Transaktionen daran, diese Aufträge zu ersetzen (oder sie selbst daran, in die Warteschlange aufgenommen zu werden, während die irreveresiblen Aufträge noch anhängig sind). Irreversible Aufträge können weiterhin mit dem Befehl cancel abgebrochen werden. Dieser Auftragmodus sollte bei jeder Transaktion, die shutdown.target hereinzieht, verwandt werden.
»isolate« ist nur für Startaktionen gültig und führt dazu, dass alle anderen Units beendet werden, wenn die angegebene Unit gestartet wird. Dieser Modus wird immer verwandt, wenn der Befehl isolate verwandt wird.
»flush« führt dazu, dass alle Aufträge in der Warteschlange abgebrochen werden, wenn der neue Auftrag in die Warteschlange eingestellt wird.
Falls »ignore-dependencies« angegeben ist, werden alle Unit-Abhängigkeiten für diesen neuen Auftrag ignoriert und die Aktion wird sofort ausgeführt. Falls übergeben, werden keine für die Unit benötigten Units hereingezogen und keine Ordnungsabhängigkeiten berücksichtigt. Dies dient hauptsächlich der Fehlersuche und als Rettungswerkzeug für den Administrator und sollte von Anwendungen nicht verwandt werden.
»ignore-requirements« ist ähnlich zu »ignore-dependencies«, führt aber nur dazu, dass die Voraussetzungsabhängigkeiten ignoriert werden, die Ordnungsabhängigkeiten werden weiterhin respektiert.
»triggering« kann nur mit systemctl stop verwandt werden. In diesem Modus wird die angegebene Unit und alle aktiven Units, die es auslöst, gestoppt. Siehe die Diskussion von Triggers= in systemd.unit(5) für weitere Informationen über auslösende Units.
»restart-dependencies« darf nur mit systemctl start verwandt werden. In diesem Modus werden Abhängigkeiten der angegebenen Unit eine Neustart-Weiterleitung erhalten, als ob der Neustart-Auftrag für die Unit in die Warteschlange gestellt worden wäre.
-T, --show-transaction
--fail
Wird dies mit dem Befehl kill zusammen verwandt, wird die Aktion zu einem Fehler führen, falls keine Units getötet wurden.
--check-inhibitors=
Anwendungen können Unterdrückungssperren einrichten, um zu verhindern, dass bestimmte wichtige Aktionen (wie das Brennen von CDs) durch das Herunterfahren des Systems oder Schlafen unterbrochen werden. Jeder Benutzer kann diese Sperren erlangen und privilegierte Benutzer dürfen diese Sperren außer Kraft setzen. Falls irgendwelche Sperren erlangt wurden, werden Anfragen zum Herunterfahren oder für Schlafzustände normalerweise fehlschlagen (außer sie sind privilegiert). Falls allerdings »no« oder »auto« bei nicht interaktiven Anfragen angegeben wurde, wird die Aktion versucht. Falls Sperren vorhanden sind, könnte die Aktion zusätzliche Privilegien benötigen.
Die Option --force stellt eine andere Möglichkeit, Unterdrücker außer Kraft zu setzen, bereit.
-i
--dry-run
-q, --quiet
--no-warn
--no-block
--wait
Wird dies zusammen mit is-system-running verwandt, wird gewartet, bis der Systemstartprozess abgeschlossen ist, bevor zurückgekehrt wird.
--user
--system
--failed
--no-wall
--global
--no-reload
--no-ask-password
--kill-whom=
--kill-value=GANZZAHL
Falls diese Option verwandt wird, wird dieses Signal nur bei dem Steuer- oder Hauptprozess der Unit in die Warteschlange gestellt, niemals bei anderen Prozessen, die zu der Unit gehören, d.h. --kill-whom=all wird nur die Haupt- und Steuerprozesse betreffen, aber keine anderen Prozesse.
-s, --signal=
Der besondere Wert »help« wird alle bekannten Werte darstellen und das Programm wird sich sofort beenden; der besondere Wert »list« wird alle bekannten Werte zusammen mit ihren numerischen Signalnummern darstellen und das Programm wird sich sofort beenden.
--what=
-f, --force
Erstellt bei der Verwendung mit edit alle angegebenen Units, die noch nicht existieren.
Führt bei der Verwendung mit halt, poweroff, reboot oder kexec die ausgewählten Aktionen ohne Herunterfahren aller Units aus. Allerdings werden alle Prozesse zwangsweise beendet und alle Dateisysteme ausgehängt oder neu nur lesbar wieder eingehängt. Dies ist daher eine drastische, aber relativ sichere Option, um einen sofortigen Neustart anzufragen. Falls --force zweimal für diese Aktionen angegeben ist (mit der Ausnahme von kexec), werden sie sofort ausgeführt, ohne alle Prozesse zu beenden oder Dateisysteme auszuhängen. Warnung: Die zweifache Angabe von --force mit jeden dieser Aktionen kann zu Datenverlust führen. Beachten Sie, dass bei zweifacher Angabe von --force die ausgewählte Aktion von systemctl selbst ausgeführt wird und kein Kontakt zum Systemverwalter aufgenommen wird. Dies bedeutet, dass dieser Befehl erfolgreich sein sollte, selbst wenn der Systemverwalter abgestürzt ist.
--message=
--now
--root=
--image=Abbild
--image-policy=Richtlinie
--runtime
Ähnlich erfolgen bei der Verwendung mit set-property die Änderungen nur temporär, so dass sie beim nächsten Neustart verloren sind.
--preset-mode=
-n, --lines=
-o, --output=
--firmware-setup
--boot-loader-menu=Zeitüberschreitung
--boot-loader-entry=Kennung
--reboot-argument=
--plain
--timestamp=
pretty (dies ist die Vorgabe)
unix
us, μs
utc
us+utc, μs+utc
--mkdir
--marked
systemctl wird darauf warten, dass in die Warteschlange eingestellte Aufträge sich beenden, außer wenn --no-block verwandt wird.
--read-only
--drop-in=NAME
--when=
-H, --host=
-M, --machine=
--no-pager
--legend=LOGISCH
-h, --help
--version
EXIT-STATUS¶
Bei Erfolg wird 0 zurückgegeben, anderenfalls ein Fehlercode ungleich Null.
systemctl verwendet die durch LSB definierten Rückgabewerte, wie sie in LSB 3.0.0[3] definiert sind.
Tabelle 3. LSB-Rückgabe-Codes
| Wert | Beschreibung in LSB | Verwendung in Systemd |
| 0 | "Programm läuft oder Dienst ist OK" | Unit ist aktiv |
| 1 | "Programm ist tot und /var/run-PID-Datei existiert" | Unit ist nicht fehlgeschlagen (von is-failed verwandt) |
| 2 | "Programm ist tot und /var/lock-Sperrdatei existiert" | nicht verwandt |
| 3 | "Programm läuft nicht" | Unit ist nicht aktiv |
| 4 | "Programm- oder Dienstezustand unbekannt" | keine solche Unit |
Die Abbildung der LSB-Dienstezustände auf Systemd-Unit-Zustände ist nicht perfekt. Daher ist es besser, sich nicht auf diese Rückgabewerte zu verlassen, sondern stattdessen nach bestimmten Unit-Zuständen und Unterzuständen zu schauen.
UMGEBUNGSVARIABLEN¶
$SYSTEMD_EDITOR
$SYSTEMD_LOG_LEVEL
$SYSTEMD_LOG_COLOR
Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal geschrieben werden, da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen, selbständig Nachrichten gemäß ihrer Protokollierungsstufe einfärben.
$SYSTEMD_LOG_TIME
Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal oder in eine Datei geschrieben werden, da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen, selbständig Zeitstempel basierend auf ihren Metadaten den Nachrichten anhängen.
$SYSTEMD_LOG_LOCATION
Beachten Sie, dass der Protokollierort sowieso oft als Metadaten zu den Journal-Einträgen angehängt ist. Die Aufnahme in den Nachrichtentext kann bei der Fehlersuche in Programmen dennoch praktisch sein.
$SYSTEMD_LOG_TARGET
$SYSTEMD_PAGER
Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, dann wird $SYSTEMD_PAGER (sowie $PAGER) ohne Rückmeldung ignoriert.
$SYSTEMD_LESS
Benutzer könnten insbesondere zwei Optionen ändern wollen:
K
Falls der Wert von $SYSTEMD_LESS kein »K« enthält und less das aufgerufene Textanzeigeprogramm ist, wird Strg+C durch das Programm ignoriert und muss durch das Textanzeigeprogramm selbst gehandhabt werden.
X
Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESS keine Auswirkungen auf die Ausführung von less(1) durch systemd(1)-Werkzeuge hat.
Siehe less(1) für weitere Ausführungen.
$SYSTEMD_LESSCHARSET
Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESSCHARSET keine Auswirkungen auf die Ausführungen von less(1) durch systemd(1)-Werkzeuge hat.
$SYSTEMD_PAGERSECURE
Hinweis: Wenn Befehle mit erhöhten Rechten ausgeführt werden, beispielsweise mittels sudo(8) oder pkexec(1), muss Vorsicht walten gelassen werden, um sicherzustellen, dass keine ungeplanten interaktiven Funktionalitäten aktiviert werden. Der »sichere« Modus für das Textanzeigeprogramm kann wie oben beschrieben automatisch aktiviert werden. Durch Setzen von SYSTEMD_PAGERSECURE=0 oder durch Nichtenfernen dieser Einstellung aus der ererbten Umgebung wird es dem Benutzer ermöglicht, beliebige Befehle auszuführen. Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt werden muss, falls die Variablen $SYSTEMD_PAGER oder $PAGER berücksichtigt werden sollen. Es kann sinnvoll sein, stattdessen das Textanzeigeprogramm komplett mit --no-pager zu deaktivieren.
$SYSTEMD_COLORS
$SYSTEMD_URLIFY
SIEHE AUCH¶
systemd(1), journalctl(1), loginctl(1), machinectl(1), systemd.unit(5), systemd.resource-control(5), systemd.special(7), wall(1), systemd.preset(5), systemd.generator(7), glob(7)
ANMERKUNGEN¶
- 1.
- Systemladerspezifikation
- 2.
- Spezifikation für auffindbare Partitionen
- 3.
- LSB 3.0.0
ÜBERSETZUNG¶
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.
| systemd 254 |