Ubuntu Manpage: systemctl - Steuerung des Systemd-Systems und des Diensteverwalters

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.

OPTIONEN

Die folgenden Optionen werden verstanden:

-t, --type=
Dieses Argument sollte eine Kommata-getrennte Liste von Unit-Typen wie service und socket sein.

Falls eines der Argumente ein Unit-Typ ist, wird die Anzeige auf bestimmte Unit-Typen begrenzt, wenn
Units aufgelistet werden. Andernfalls werden alle Typen angezeigt.

Als Spezialfall wird eine Liste der erlaubten Werte angezeigt und das Programm beendet sich, falls
eines der Argumente help ist.

--state=
Das Argument sollte eine Kommata-getrennte Liste von Zuständen LOAD, SUB oder ACTIVE sein. Wenn Units
aufgelistet werden, werden nur die in den festgelegten Zuständen angezeigt. Verwenden Sie
--state=failed, um nur fehlgeschlagene Units anzuzeigen.

Als Spezialfall wird eine Liste der erlaubten Werte angezeigt und das Programm beendet sich, falls
eines der Argumente help ist.

-p, --property=
Bei der Anzeige der Eigenschaften von Units/Aufträgen/Verwalter mit dem Befehl show wird die Anzeige
auf die festgelegten Eigenschaften begrenzt. Das Argument sollte eine Kommata-getrennte Liste von
Eigenschaftsnamen wie »MainPID« sein. Falls nicht angegeben, werden alle bekannten Eigenschaften
angezeigt. Falls mehr als einmal festgelegt, werden alle Eigenschaften mit den festgelegten Namen
angezeigt. Für Eigenschaftsnamen ist die Shell-Vervollständigung implementiert.

Für den Verwalter selbst wird systemctl show alle verfügbaren Eigenschaften anzeigen. Diese
Eigenschaften sind in systemd-system.conf(5) dokumentiert.

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.

-a, --all
Beim Auflisten von Units mit list-units werden auch inaktive Units und Units, die anderen Units
folgen, angezeigt. Bei der Anzeige der Eigenschaften von Units/Aufträgen/Verwaltern werden alle
Eigenschaften angezeigt, unabhängig davon, ob sie gesetzt sind oder nicht.

Um alle im Dateisystem installierten Units aufzulisten, verwenden Sie stattdessen den Befehl
list-unit-files.

Beim Auflisten von Units mit list-dependencies werden alle abhängigen Units rekursiv angezeigt
(standardmäßig werden nur Abhängigkeiten von Ziel-Units angezeigt).

Bei der Verwendung mit status werden Journal-Nachrichten vollständig angezeigt, 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
Beim Auflisten von Units werden auch Units von lokalen Containern angezeigt. Units von lokalen
Containern wird der Container-Name vorangestellt, getrennt durch einen einzelnen Doppelpunkt (»:«).

--reverse
Zeigt mit list-dependencies inverse Abhängigkeiten an, d.h. folgt Abhängigkeiten vom Typ WantedBy=,
RequiredBy=, PartOf=, BoundBy= statt Wants= und ähnlichen.

--after
Zeigt mit list-dependencies Units an, die vor der festgelegten Unit angeordnet sind. Mit anderen
Worten, listet rekursiv Units, die der Abhängigkeit After= folgen, auf.

Beachten Sie, dass jede Abhängigkeit After= automatisch gespiegelt wird, um eine Abhängigkeit Before=
zu erstellen. Temporäre Abhängigkeiten können explizit festgelegt 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
Zeigt mit list-dependencies Units an, die nach der festgelegten Unit angeordnet sind. Mit anderen
Worten, listet rekursiv Units, die der Abhängigkeit Before= folgen, auf.

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.

-l, --full
Unit-Namen, Prozessbaumeinträge, Journal-Ausgabe nicht verkürzen und Unit-Beschreibungen in der
Ausgabe von status, list-units, list-jobs und list-timers nicht abschneiden.

Zeigt auch Installationsziele in der Ausgabe von is-enabled an.

--value
Wenn Eigenschaften mit show dargestellt werden, wird nur der Wert ausgegeben und der Eigenschaftsname
und »=« übersprungen.

--show-types
Bei der Anzeige von Sockets wird auch der Typ des Sockets angezeigt.

--job-mode=
Beim Einstellen eines Auftrags in die Warteschlangen steuert diese Option, wie mit bereits in der
Warteschlange befindlichen Aufträgen umgegangen werden soll. Sie akzeptiert entweder »fail«,
»replace«, »replace-irreversibly«, »isolate«, »ignore-dependencies«, »ignore-requirements« oder
»flush«. Standardmäßig »replace«, außer wenn der Befehl isolate verwandt wird, da dieser den
Auftragsmodus »isolate« impliziert.

Falls »fail« festgelegt 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« festgelegt ist, wird jeder in Konflikt stehende anhängige Auftrag falls
notwendig ersetzt.

Falls »replace-irreversibly« festgelegt 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 festgelegte 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« festgelegt 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.

-T, --show-transaction
Wenn eine Unit in die Warteschlange gestellt wird (beispielsweise als Auswirkung des Aufrufs
systemctl start oder ähnlichem) wird eine knappe Information über alle Aufträge in der Warteschlange
angezeigt. Dabei werden sowohl die angeforderten Aufträge als auch alle aufgrund von
Unit-Abhängigkeiten hinzugefügte berücksichtigt. Beachten Sie, dass die Ausgabe nur Aufträge
enthalten wird, die sofort Teil der angeforderten Transaktion sind. Es ist möglich, dass die
Ausführung des Programmcodes des Dienstes zum Hochfahren die Auswirkung hat, dass die angeforderten
Aufträge dass Hereinziehen weiterer Aufträge anfordern. Das bedeutet, dass beim Abschluss der
angezeigten Aufträge letztendlich mehr Aufträge als die angezeigten enthalten sein könnten.

--fail
Kurzform von --job-mode=fail.

Wird dies mit dem Befehl kill zusammen verwandt, wird die Aktion zu einem Fehler führen, falls keine
Units getötet wurden.

-i, --ignore-inhibitors
Unterdrückungssperren ignorieren, wenn das Herunterfahren oder der Schlafzustand erbeten wurde.
Anwendungen können Unterdrückungssperren einrichten, um zu vermeiden, dass bestimmte wichtige
Aktionen (wie das Brennen von CDs oder ähnlichem) durch das Herunterfahren des Systems oder
Schlafzustände 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) und eine Liste der aktiven Sperren wird ausgegeben. Falls allerdings
--ignore-inhibitors festgelegt wurde, werden die etablierten Sperren ignoriert und nicht angezeigt
und die Aktion wird dennoch versucht, wobei möglicherweise zusätzliche Privilegien benötigt werden.

--dry-run
Einfach ausgeben, was getan würde. Momentan von den Verben halt, poweroff, reboot, kexec, suspend,
hibernate, hybrid-sleep, suspend-then-hibernate, default, rescue, emergency und exit unterstützt.

-q, --quiet
Unterdrückt die Ausgabe des Ergebnisses der verschiedenen Befehle und auch die Hinweise auf
abgeschnittene Protokollzeilen. Dies unterdrückt nicht die Ausgabe von Befehlen, für die die
dargestellte Ausgabe das einzige Ergebnis ist (wie show). Fehler werden immer ausgegeben.

--no-block
Wartet nicht synchron darauf, dass die angefragte Aktion sich beendet. Falls dies nicht festgelegt
ist, wird der Auftrag überprüft, in die Warteschlange eingereiht und systemctl wartet, bis das
Hochfahren der Unit abgeschlossen ist. Durch Übergabe dieses Arguments wird nur überprüft und in die
Warteschlange eingereiht. Diese Option darf nicht mit --wait kombiniert werden.

--wait
Wartet synchron darauf, dass gestartete Units sich wieder beenden. Diese Option darf nicht mit
--no-block kombiniert werden. Beachten Sie, dass dies ewig warten wird, falls eine übergebene Unit
sich nie beendet (entweder selbst oder explizit gestoppt wird); insbesondere Dienste, die
»RemainAfterExit=yes« verwenden.

Wird dies zusammen mit is-system-running verwandt, wird gewartet, bis der Systemstartprozess
abgeschlossen ist, bevor zurückgekehrt wird.

--user
Kommuniziert mit dem Diensteverwalter des aufrufenden Benutzers statt mit dem Diensteverwalter des
Systems.

--system
Kommuniziert mit dem Diensteverwalter des Systems. Dies ist die implizite Vorgabe.

--failed
Listet Units im fehlgeschlagenen Zustand auf. Dies ist zu --state=failed äquivalent.

--no-wall
Keine Wall-Nachrichten vor halt, power-off und reboot versenden.

--global
Falls mit enable und disable verwandt, wird im globalen Benutzerverzeichnis agiert und somit eine
Unit-Datei global für alle zukünftigen Anmeldungen aller Benutzer freigegeben oder ausgeschaltet.

--no-reload
Falls mit enable und disable verwandt, wird die Daemon-Konfiguration nach der Ausführung der Änderung
nicht implizit neu geladen.

--no-ask-password
Bei der Verwendung mit start und verwandten Befehlen deaktiviert es Fragen nach Passwörtern.
Hintergrunddienste können die Eingabe von Passwörtern oder Passphrasenzeichenketten benötigten,
beispielsweise um Systemfestplatten oder kryptographische Zertifikate zu entsperren. Außer wenn diese
Option festgelegt ist und der Befehl von einem Terminal aus ausgeführt wird, wird systemctl den
Benutzer auf dem Terminal nach den notwendigen Geheimnissen fragen. Verwenden Sie diesen Schalter, um
das Verhalten abzuschalten. In diesem Fall muss das Passwort über einen anderen Weg bereitgestellt
werden (beispielsweise graphische Passsworte-Agenten) oder der Service könnte fehlschlagen. Dies
deaktiviert auch die Abfrage des Benutzers für die Authentifizierung für privilegierte Aktionen.

--kill-who=
Bei der Verwendung mit kill wählen Sie aus, welchen Prozessen ein Signal gesandt werden soll. Muss
einer aus main, control und all sein, um auszuwählen, ob nur der Hauptprozess, der Steuerprozess oder
alle Prozess der Unit getötet werden soll(en). Der Hauptprozess der Unit ist derjenige, der die
Lebensdauer bestimmt. Ein Steuerprozess einer Unit ist derjenige, der durch den Verwalter aufgerufen
wird, um Statusänderungen zu veranlassen. Beispielsweise sind alle Prozesse, die aufgrund von
ExecStartPre=-, ExecStop=- oder ExecReload=-Einstellungen von Dienste-Units gestartet werden,
Steuerprozesse. Beachten Sie, dass es für jeden Zeitpunkt nur einen Steuerprozess pro Unit gibt, da
nur eine Statusänderung gleichzeitig ausgeführt wird. Für Dienste vom Typ Type=forking ist der vom
Verwalter für ExecStart= initial gestartete Prozess der Steuerprozess, während der schließlich
mittels Fork gestartete Prozess dann als Hauptprozess der Unit betrachtet wird (falls er bestimmt
werden kann). Dies ist für Dienste-Units von anderen Typen verschieden, wo der vom Verwalter für
ExecStart= mit Fork gestartete Prozess immer der Hauptprozess selbst ist. Eine Dienste-Unit besteht
aus keinem oder einem Hauptprozess, keinem oder einem Steuerprozess sowie einer beliebigen Anzahl von
zusätzlichen Prozessen. Allerdings verwalten nicht alle Unit-Typen Prozesse dieser Typen. Für
Einhänge-Units sind beispielsweise Steuerprozesse definiert (die die Aufrufe von /bin/mount und
/bin/umount sind), aber es ist kein Hauptprozess definiert. Falls weggelassen, ist die Vorgabe all.

-s, --signal=
Bei der Verwendung mit kill wird das Signal ausgesucht, das an ausgewählte Prozesse gesandt wird.
Muss eines der gut bekannten Signalkennungen wie SIGTERM, SIGINT oder SIGSTOP sein. Falls
weggelassen, ist die Vorgabe SIGTERM.

--what=
Wählt aus, welche Art von Unit-bezogenen Ressourcen entfernt werden, wenn der Befehl clean aufgerufen
wird, siehe unten. Akzeptiert entweder configuration, state, cache, logs oder runtime, um die Art der
Ressource auszuwählen. Diese Option kann mehr als einmal festgelegt werden, wodurch alle festgelegten
Ressourcentypen entfernt werden. Akzeptiert auch den besonderen Wert all, als Abkürzung zur
Festlegung aller fünf Ressourcentypen. Falls diese Option nicht festgelegt ist, ist die Vorgabe die
Kombination von cache und runtime, d.h. den zwei Arten von Ressourcen, die im Allgemeinen als
redundant betrachtet und beim nächsten Aufruf rekonstruiert werden können.

-f, --force
Bei der Verwendung mit enable werden alle existierenden, im Konflikt stehenden Symlinks außer Kraft
gesetzt.

Bei der Verwendung mit edit werden alle festgelegten Units, die noch nicht existieren, erstellt.

Bei der Verwendung mit halt, poweroff, reboot oder kexec werden die ausgewählten Aktionen ohne
Herunterfahren aller Units ausgeführt. 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 festgelegt 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 Festlegung 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=
Bei der Verwendung mit halt, poweroff oder reboot wird eine kurze Nachricht, die den Grund für die
Aktion beschreibt, gesetzt. Die Nachricht wird zusammen mit der Standard-Herunterfahrnachricht
protokolliert.

--now
Bei der Verwendung mit enable werden die Units auch gestartet. Bei der Verwendung mit disable oder
mask werden die Units auch gestoppt. Die Start- oder Stopp-Aktion wird nur durchgeführt, wenn die
zugehörige Freigabe- oder Ausschaltaktion erfolgreich war.

--root=
Bei der Verwendung mit enable/disable/is-enabled (und verwandten Befehlen) werden die festgelegten
Wurzelpfade beim Suchen nach Unit-Dateien verwandt. Falls diese Option vorhanden ist, wird systemctl
auf dem Dateisystem direkt arbeiten, statt mit dem Daemon systemd zu kommunizieren, um die Änderungen
auszuführen.

--runtime
Bei der Verwendung mit enable, disable, edit (und verwandten Befehlen) werden Änderungen nur temporär
durchgeführt, so dass sie beim nächsten Neustart verloren sind. Dies hat den Effekt, dass Änderungen
nicht in dem Unterverzeichnis von /etc, sondern in /run durchgeführt werden, mit identischen
sofortigen Effekten, da allerdings die Änderungen bei letzterem beim Neustart verloren gehen, gehen
auch die Änderungen verloren.

Ähnlich erfolgen bei der Verwendung mit set-property die Änderungen nur temporär, so dass sie beim
nächsten Neustart verloren sind.

--preset-mode=
Akzeptiert »full« (die Vorgabe), »enable-only« oder »disable-only«. Bei der Verwendung mit den
Befehlen preset oder preset-all wird gesteuert, ob Units entsprechend der Voreinstellungsregeln
ausgeschaltet oder freigegeben oder nur freigegeben oder nur ausgeschaltet werden sollen.

-n, --lines=
Steuert bei der Verwendung mit status die Anzahl der anzuzeigenden Journal-Zeilen, gezählt von der
neuesten. Akzeptiert als Argument eine positive Ganzzahl oder 0, um die Journal-Ausgabe zu
deaktivieren. Standardmäßig 10.

-o, --output=
Steuert bei der Verwendung mit status die Formatierung der angezeigten Journal-Einträge. Siehe
journalctl(1) für die verfügbaren Auswahlmöglichkeiten. Standardmäßig »short«.

--firmware-setup
Zeigt der Firmware des Systems bei der Verwendung mit dem Befehl reboot an, dass in die
Firmware-Einrichtungsschnittstelle neu gestartet werden soll. Beachten Sie, dass diese Funktionalität
nicht auf allen Systemen verfügbar ist.

--boot-loader-menu=
Zeigt dem System-Bootloader im Zusammenhang mit dem Befehl reboot an, dass der Bootloader beim
nächsten Systemstart das Bootloader-Menü anzeigen soll. Akzeptiert einen Zeitwert als Parameter, der
die Zeitüberschreitung des Menüs angibt. Übergeben Sie Null, um die Zeitüberschreitung des Menüs zu
deaktivieren. Beachten Sie, dass nicht alle Bootloader diese Funktionalität unterstützten.

--boot-loader-entry=
Zeigt dem System-Bootloader im Zusammenhang mit dem Befehl reboot an, dass der Bootloader beim
nächsten Systemstart in einen bestimmten Bootloader-Eintrag starten soll. Akzeptiert einen
Bootlaoder-Eintragskennzeichner als Argument oder »help«, um die verfügbaren Einträge anzuzeigen.
Beachten Sie, dass nicht alle Bootloader diese Funktionalität unterstützten.

--plain
Bei der Verwendung mit list-dependencies, list-units oder list-machines wird die Ausgabe als Liste
statt als Baum dargestellt und die Aufzählungskreise werden weggelassen.

-H, --host=
Führt die Aktion aus der Ferne aus. Geben Sie den Rechnernamen oder einen Benutzernamen und
Rechnernamen (getrennt durch »@«) an, zu dem verbunden werden soll. Dem Rechnernamen darf optional
ein Port, auf dem SSH auf Anfragen wartet, getrennt durch »:« und dann ein Container auf dem
festgelegten Host angehängt werden, womit direkt zu einem bestimmten Container auf dem angegebenen
Rechner verbunden wird. Dies verwendet SSH, um mit der Maschinen-Verwalterinstanz auf dem Rechner in
der Ferne zu kommunizieren. Container-Namen dürfen mit machinectl -H RECHNER aufgezählt werden.
Stellen Sie IPv6-Adressen in Klammern.

-M, --machine=
Führt die Aktion in einem lokalen Container aus. Geben Sie den Namen des Containers an, zu dem
verbunden werden soll.

--no-pager
Die Ausgabe nicht an ein Textanzeigeprogramm weiterleiten.

--no-legend
Gibt die Legende nicht aus, d.h. die Spaltenköpfe und die Fußzeile mit Hinweisen.

-h, --help
Zeigt einen kurzen Hilfetext an und beendet das Programm.

--version
Zeigt eine kurze Versionszeichenkette an und beendet das Programm.

BEFEHLE

Die folgenden Befehle werden verstanden:

Unit-Befehle
list-units [MUSTER…]
Listet Units auf, die systemd derzeit im Speicher hat. Dies schließt Units ein, die entweder direkt
oder über eine Abhängigkeit referenziert sind, Units, die durch Anwendungen programmatisch festgelegt
sind und Units, die in der Vergangenheit aktiv waren und fehlschlugen. Standardmäßig werden nur
Units, die aktiv sind, wartende Aufträge haben oder die fehlschlugen, angezeigt; dies kann mit der
Option --all geändert werden. Falls eines oder mehrere MUSTER festgelegt sind, werden nur Units, die
auf diese passen, angezeigt. Die angezeigten Units werden zusätzlich durch --type= und --state=
gefiltert, falls diese Optionen festgelegt sind.

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-sockets [MUSTER…]
Listet aktuell im Speicher befindliche Socket-Units, sortiert nach der Adresse, auf der sie auf
Anfragen warten, auf. Falls eines oder mehrere MUSTER festgelegt sind, werden nur Socket-Units, die
darauf passen, angezeigt. Produziert Ausgabe ähnlich zu

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…]
Listet aktuell im Speicher befindliche Zeitgeber-Units, sortiert nach der Zeit, zu der sie ablaufen,
auf. Falls eines oder mehrere MUSTER festgelegt sind, werden nur Units, die darauf passen, angezeigt.
Produziert Ausgabe ähnlich zu

NEXT LEFT LAST PASSED UNIT ACTIVATES
n/a n/a 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 Zeitgeber läuft.

LEFT zeigt die Zeitdauer, bis der Zeitgeber das nächste Mal läuft.

LAST zeigt die Zeit, zu der der Zeitgeber das letzte Mal lief.

PASSED zeigt, welche Zeit vergangen ist, seitdem der Zeitgeber letztmalig lief.

UNIT zeigt den Namen des Zeitgebers

ACTIVATES zeigt den Namen des Dienstes, den der Zeitgeber beim Laufen aktiviert.

Siehe auch --all und --state=.

start MUSTER…
Startet (aktiviert) eine oder mehrere auf der Befehlszeile festgelegte Units.

Beachten Sie, dass Glob-Muster auf der Menge der Primärnamen von Units, die momentan im
Arbeitsspeicher sind, agieren. 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.

stop MUSTER…
Stoppt (deaktiviert) eine oder mehrere auf der Befehlszeile festgelegte Units.

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.

reload MUSTER…
Bittet alle auf der Befehlszeile aufgeführten Units, ihre Konfiguration neu zu laden. Beachten Sie,
dass dies die Dienste-spezifische Konfiguration neu lädt, nicht die Unit-Konfiguration von Systemd.
Falls Sie möchten, dass Systemd die Konfiguration einer Unit neu lädt, verwenden Sie den Befehl
daemon-reload. Mit anderen Worten: Im Falle von Apache wird dies die httpd.conf neu in den Webserver
laden, nicht die Systemd-Unit-Datei apache.service.

Dieser Befehl sollte nicht mit dem Befehl daemon-reload verwechselt werden.

restart MUSTER…
Stoppt und startet eine oder mehrere auf der Befehlszeile übergebene Units. Falls die Units noch
nicht laufen, werden sie gestartet.

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…
Stoppt und startet eine oder mehrere auf der Befehlszeile festgelegte Units, falls die Units laufen.
Dies ist wirkungslos, falls die Units nicht laufen.

reload-or-restart MUSTER…
Lädt eine oder mehrere Units neu, falls sie das unterstützen. Falls nicht, werden sie stattdessen
gestoppt und dann gestartet. Falls die Units noch nicht laufen, werden sie gestartet.

try-reload-or-restart MUSTER…
Lädt eine oder mehrere Units neu, falls sie das unterstützen. Falls nicht, werden sie stattdessen
gestoppt und neugestartet. Dies ist wirkungslos, falls die Units nicht laufen.

isolate UNIT
Startet die auf der Befehlszeile festgelegte Unit und ihre Abhängigkeiten und stoppt alle anderen,
außer sie haben IgnoreOnIsolate=yes (siehe systemd.unit(5)). Falls ein Unit-Name ohne Erweiterung
angegeben wird, wird eine Erweiterung ».target« angenommen.

Dies ist ähnlich zu der Änderung von Runleveln in traditionellen Init-Systemen. Der Befehl isolate
wird sofort Prozesse stoppen, die in der neuen Unit nicht freigegeben sind, möglicherweise
einschließlich der graphischen Umgebung oder des Terminals, das Sie gerade benutzen.

Beachten Sie, dass dies nur auf Units erlaubt ist, bei denen AllowIsolate= aktiviert ist. Siehe
systemd.unit(5) für Details.

kill MUSTER…
Sendet ein Signal an einen oder mehrere Prozesse der Unit. Verwenden Sie --kill-who=, um den zu
tötenden Prozess auszuwählen. Verwenden Sie --signal=, um das zu sendende Signal auszuwählen.

clean MUSTER…
Entfernt die Konfiguration, den Zustand, den Zwischenspeicher, die Protokolle oder die Laufzeitdaten
der festgelegten Units. Verwenden Sie --what=, um auszuwählen, welche Ressourcenarten Sie entfernen
möchten.Für Dienste-Units kann dies zur Entfernung von mit ConfigurationDirectory=, StateDirectory=,
CacheDirectory=, LogsDirectory= und RuntimeDirectory= konfigurierten Verzeichnissen verwandt werden,
siehe systemd.exec(5) für Details. Für Zeitgeber-Units kann dies zur Bereinigung der dauerhaften
Zeitstempeldaten verwandt werden, falls Persistent= eingesetzt und --what=state ausgewählt ist, siehe
systemd.timer(5). Dieser Befehl wird nur auf Unit angewandt, die eine dieser Einstellungen verwenden.
Falls --what= nicht festgelegt ist, werden sowohl die Zwischenspeicher- als auch die Laufzeitdaten
entfernt (da diese zwei Datenarten im Allgemeinen redundant und beim nächsten Aufruf der Unit
reproduzierbar sind).

is-active MUSTER…
Prüft, ob eine der festgelegten Units aktiv ist (d.h. läuft). Liefert einen Exit-Code von 0, falls
mindestens eine aktiv ist oder einen von Null verschiedenen Wert andernfalls. Außer wenn --quiet
festgelegt ist, wird dies auch den aktuellen Zustand der Unit auf der Standardausgabe ausgeben.

is-failed MUSTER…
Prüft, ob eine der festgelegten Units im »fehlgeschlagenen« Zustand ist. Liefert einen Exit-Code von
0, falls mindestens eine fehlgeschlagen ist oder einen von Null verschiedenen Wert andernfalls. Außer
wenn --quiet festgelegt ist, wird dies auch den aktuellen Zustand der Unit auf der Standardausgabe
ausgeben.

status [MUSTER…|PID…]]
Zeigt knappe Laufzeitstatusinformationen über eine oder mehrere Units, gefolgt von den neusten
Protokolldaten aus dem Journal. Falls keine Units festgelegt sind, wird der Systemstatus angezeigt.
In Kombination mit --all wird auch der Status aller Units angezeigt (in Abhängigkeit von den mit -t
festgelegten Einschränkungen). Falls eine PID übergeben wird, werden die Informationen über die Unit,
zu der der Prozess gehört, angezeigt.

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.

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; vendor 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. Weiß zeigt den Zustand »inactive« oder »deactivating« an. Rot zeigt einen Zustand
»failed« oder »error« und grün zeigt einen Zustand »active«, »reloading« oder »activating« an.

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 Befehle starten beim Systemstart. 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…]
Zeigt die Eigenschaften einer oder mehrerer Units, von Aufträgen oder dem Verwalter selbst. Falls
kein Argument festgelegt ist, werden die Eigenschaften des Verwalters angezeigt. Falls ein Unit-Name
festgelegt ist, werden die Eigenschaften der Unit angezeigt und falls eine Auftragskennung festgelegt
ist, werden die Eigenschaften des Auftrags angezeigt. Standardmäßig werden leere Eigenschaften
unterdrückt. Verwenden Sie --all, um diese auch anzuzeigen. Um bestimmte anzuzeigende Eigenschaften
auszuwählen, verwenden Sie --property=. Dieser Befehl ist dazu gedacht, wannimmer
Computer-auswertbare Ausgabe benötigt wird. Verwenden Sie status, falls Sie formatierte,
menschenlesbare Ausgabe wünschen.

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 verwandte normierte Zeiteinheit sind.

cat MUSTER…
Zeigt zugrundeliegende Dateien von einer oder mehr Units. Gibt die »Fragmente« und
»Ergänzungsdateien« (Quelldateien) von Units aus. Jeder Datei wird ein Kommentar vorangestellt, der
den Dateinamen enthält. Beachten Sie, dass dieses die Inhalte der auf Platte zugrundeliegenden
Dateien anzeigt, was sich von dem unterscheiden kann, was der Systemverwalter von diesen Units denkt,
falls die Units seitdem aktualisiert wurden und nicht der Befehl daemon-reload aufgerufen worden war.

set-property UNIT EIGENSCHAFT=WERT…
Setzt die festgelegten Unit-Eigenschaften zur Laufzeit, wo dies unterstützt wird. Dies erlaubt die
Änderung von Konfigurationsparametereigenschaften wie Ressourcensteuereinstellungen zur Laufzeit. Es
können nicht alle Eigenschaften zur Laufzeit geändert werden, aber viele
Ressourcensteuereinstellungen (primär die in systemd.resource-control(5)). Die Änderungen werden
sofort angewandt und auf Platte für zukünftige Systemstarts gespeichert, außer --runtime wird
übergeben, wodurch die Einstellungen nur bis zum nächsten Systemneustart angewandt werden. Die Syntax
der Eigenschaftszuweisung folgt eng der Syntax der Zuweisungen in Unit-Dateien.

Beispiel: systemctl set-property foobar.service CPUWeight=200

Falls die festgelegte 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=

help MUSTER…|PID…
Zeigt die Handbuchseiten für eine oder mehrere Units, falls verfügbar. Falls eine PID übergeben wird,
wird die Handbuchseite für die Unit, zu der der Prozess gehört, gezeigt.

reset-failed [MUSTER…]
Setzt den Zustand »failed« der festgelegten Unit zurück oder, falls kein Unit-Name übergeben wird,
setzt den Zustand aller Units zurück. Wenn eine Unit auf irgendeine Art fehlschlägt (d.h. sich der
Prozess mit einem von Null verschiedenen Fehler-Code beendet, sich abnormal beendet oder in eine
Zeitüberschreitung läuft), tritt sie automatisch in den Zustand »failed« und ihr Exit-Code und ihr
Status wird zur Prüfung durch den Administrator aufgezeichnet, bis der Dienst gestoppt/neugestartet
oder mit diesem Befehl zurückgesetzt ist.

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.

list-dependencies [UNIT]
Zeigt Units, die von der festgelegten Unit benötigt und gewünscht werden. Diese rekursive Liste folgt
den Abhängigkeiten Requires=, Requisite=, ConsistsOf=, Wants=, BindsTo=. Falls keine Unit festgelegt
ist, wird default.target 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.

Unit-Dateibefehle
list-unit-files [MUSTER…]
Listet auf dem System installierte Units zusammen mit ihrem Freigabezustand (wie von is-enabled)
gemeldet) auf. Falls ein oder mehrere Muster festgelegt sind, werden nur Units, deren Name auf sie
passen, gezeigt (Muster, die auf Unit-Dateisystempfade passen, werden nicht unterstützt).

enable UNIT…, enable PFAD…
Gibt eine oder mehrere Units oder Unit-Instanzen frei. Dies wird eine Gruppe von Symlinks erzeugen,
wie dies in dem Abschnitt »[Install]« der angezeigten Unit-Dateien kodiert ist. Nachdem die Symlinks
erstellt wurden, wird die Systemverwalterkonfiguration neu geladen (auf einer zu daemon-reload
äquivalenten Art), um sicherzustellen, dass die Änderungen sofort berücksichtigt werden. Beachten
Sie, dass dies nicht den Effekt hat, dass die freigegebenen Units auch gestartet werden. Falls dies
gewünscht ist, kombinieren Sie den Befehl mit dem Schalter --now oder rufen Sie später start mit
geeigneten Argumenten auf. Beachten Sie, dass bei der Freigabe von Unit-Instanzen (d.h. Freigabe von
Units der Form foo@bar.service) Symlinks mit dem gleichen Namen wie die erstellten Instanzen im
Unit-Konfigurationsverzeichnis erstellt werden, allerdings zeigen sie auf die einzelne
Vorlagen-Unit-Datei, aus der sie instanziiiert wurden.

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 festgelegte
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 /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.

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, dss 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 festgelegt 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…
Schaltet eine oder mehrere Units aus. Dies entfernt alle Symlinks auf die Unit-Dateien, die den
festgelegten Units aus dem Unit-Konfigurationsverzeichnis hinterlegt sind und nimmt daher alle durch
enable oder link vorgenommenen Änderungen zurück. Beachten Sie, dass dies alle Symlinks auf passende
Unit-Dateien entfernt, einschließlich manuell erstellter Symlinks, und nicht nur die tatsächlich von
enable oder link erstellten. Beachten Sie, dass zwar disable den Effekt von enable rückgängig macht,
die zwei Befehle aber ansonsten nicht symmetrisch sind, da disable mehr Symlinks entfernen könnte,
als ein vorheriger Aufruf von enable für die gleiche Unit erstellte.

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.

Dieser Befehl berücksichtigt --system, --user, --runtime und --global auf eine ähnliche Art wie
enable.

reenable UNIT…
Gibt eine oder mehrere Units erneut frei, wie dies auf der Befehlszeile festgelegt ist. Dies ist eine
Kombination von disable und enable und ist nützlich, um die Symlinks, mit der eine Unit-Datei
freigegeben wird, auf die in seinem Abschnitt »[Install]« festgelegten Vorgaben zurückzusetzen.
Dieser Befehl erwartet nur einen Unit-Namen und akzeptiert keine Pfade zu Unit-Dateien.

preset UNIT…
Setzt den Status Freigegeben/Ausgeschaltet einer oder mehrerer Unit-Dateien, wie auf der Befehlszeile
festgelegt, auf die in den Voreinstellungsrichtliniendateien konfigurierten Standardwerte zurück.
Dies hat den gleichen Effekt wie disable oder enable, abhängig davon, wie die Unit in den
Voreinstellungsdateien aufgeführt ist.

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.

Für weitere Informationen über das Voreinstellungsrichtlinienformat, siehe systemd.preset(5). Für
weitere Informationen über das Voreinstellungskonzept, ziehen Sie bitte das Dokument Preset[1] zu
Rate.

preset-all
Setzt alle installierten Unit-Dateien auf die in der Voreinstellungsrichtliniendatei konfigurierten
Vorgaben zurück (siehe oben).

Verwenden Sie --preset-mode=, um zu steuern, ob Units freigegeben und ausgeschaltet oder nur
freigegeben oder nur ausgeschaltet sein sollen.

is-enabled UNIT…
Prüft, ob eine der festgelegten Unit-Dateien eingeschaltet ist (wie mit enable). Liefert einen
Exit-Code 0 zurück, falls mindestens eine freigegeben ist, andernfalls eine von Null verschiedene
Zahl. Gibt den derzeitigen Freigabestatus (siehe Tabelle) aus. Um diese Ausgabe zu unterdrücken,
verwenden Sie --quiet. Um Installationsziele anzuzeigen, verwenden Sie --full.

Tabelle 1. Ausgabe von is-enabled
┌───────────────────┬──────────────────────────────┬───────────┐
│ Name │ Beschreibung │ Exit-Code │
├───────────────────┼──────────────────────────────┼───────────┤
│ "enabled" │ Über .wants/, .requires/ │ │
├───────────────────┤ oder Alias=-Symlinks │ │
│ "enabled-runtime" │ freigegeben (dauerhaft in │ 0 │
│ │ /etc/systemd/system/ oder │ │
│ │ flüchtig in │ │
│ │ /run/systemd/system/). │ │
├───────────────────┼──────────────────────────────┼───────────┤
│ "linked" │ Über einen oder mehrere │ │
├───────────────────┤ Symlinks auf die Unit-Datei │ │
│ "linked-runtime" │ verfügbar gemacht (dauerhaft │ │
│ │ in /etc/systemd/system/ oder │ │
│ │ flüchtig in │ > 0 │
│ │ /run/systemd/system/), │ │
│ │ obwohl die Unit-Datei selbst │ │
│ │ außerhalb des │ │
│ │ Unit-Dateisuchpfades liegen │ │
│ │ kann. │ │
├───────────────────┼──────────────────────────────┼───────────┤
│ "masked" │ Komplett ausgeschaltet, so │ │
├───────────────────┤ dass jede Startaktion darauf │ │
│ "masked-runtime" │ fehlschlägt (dauerhaft in │ > 0 │
│ │ /etc/systemd/system/ oder │ │
│ │ flüchtig in │ │
│ │ /run/systemd/systemd/). │ │
├───────────────────┼──────────────────────────────┼───────────┤
│ "static" │ Die Unit-Datei ist nicht │ 0 │
│ │ freigegeben und hat keine │ │
│ │ Vorkehrungen für die │ │
│ │ Freigabe in dem │ │
│ │ Unit-Dateiabschnitt │ │
│ │ »[Install]«. │ │
├───────────────────┼──────────────────────────────┼───────────┤
│ "indirect" │ Die Unit-Datei selbst ist │ 0 │
│ │ 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= │ │
│ │ festgelegt ist. Für │ │
│ │ Vorlagen-Unit-Dateien ist │ │
│ │ eine Instanz, die sich von │ │
│ │ der in DefaultInstance= │ │
│ │ festgelegten unterscheidet, │ │
│ │ freigegeben. │ │
├───────────────────┼──────────────────────────────┼───────────┤
│ "disabled" │ Die Unit-Datei ist nicht │ > 0 │
│ │ freigegeben, enthält aber │ │
│ │ einen Abschnitt »[Install]« │ │
│ │ mit │ │
│ │ Installationsanweisungen. │ │
├───────────────────┼──────────────────────────────┼───────────┤
│ "generated" │ Die Unit wurde dynamisch mit │ 0 │
│ │ einem Generatorwerkzeug │ │
│ │ erstellt. Siehe │ │
│ │ systemd.generator(7). │ │
│ │ Erstellte Unit-Dateien │ │
│ │ können nicht freigegeben │ │
│ │ werden, sie werden implizit │ │
│ │ durch ihren Generator │ │
│ │ freigegeben. │ │
├───────────────────┼──────────────────────────────┼───────────┤
│ "transient" │ Die Unit-Datei wurde │ 0 │
│ │ dynamisch mit der │ │
│ │ Laufzeit-API erstellt. │ │
│ │ Flüchtige Units können nicht │ │
│ │ freigegeben werden. │ │
├───────────────────┼──────────────────────────────┼───────────┤
│ "bad" │ Die Unit-Datei ist ungültig │ > 0 │
│ │ 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. │ │
└───────────────────┴──────────────────────────────┴───────────┘

mask UNIT…
Blendet eine oder mehrere Units, wie auf der Befehlszeile festgelegt, aus. Dies wird die Unit-Dateien
nach /dev/null linken, wodurch sie nicht gestartet werden können. Dies ist eine stärkere Version von
disable, da sie alle Arten von Aktivierung der Unit verbietet, einschließlich der Freigabe und
manueller Aktivierung. Verwenden Sie diese Option mit Vorsicht. Die Option --runtime wird
berücksichtigt, um nur bis zum nächsten Systemneustart auszublenden. Die Option --now kann verwandt
werden, um sicherzustellen, dass die Units auch gestoppt werden. Dieser Befehl erwartet nur gültige
Unit-Namen, er akzeptiert keine Unit-Dateipfade.

unmask UNIT…
Blendet eine oder mehrere Unit-Dateien, wie auf der Befehlszeile festgelegt, ein. Dies macht die
Wirkung von mask rückgängig. Dieser Befehl erwartet nur gültige Unit-Namen, er akzeptiert keine
Unit-Dateipfade.

link PFAD…
Linkt eine Unit-Datei, die nicht im Unit-Dateisuchpfad ist, in den Dateisuchpfad. Dieser Befehl
erwartet einen absoluten Pfad zu einer Unit-Datei. Die Wirkung kann mit disable zurückgenommen
werden. Die Wirkung des Befehls besteht darin, dass die Unit-Datei für Befehle wie start verfügbar
gemacht wird, obwohl sie nicht direkt im Unit-Dateisuchpfad installiert ist. Das Dateisystem, in dem
sich die verlinkte Unit-Datei befindet, muss beim Start von Systemd zugreifbar sein (d.h. alles
unterhalb von /home oder /var ist nicht erlaubt, außer diese Verzeichnisse befinden sich im
Wurzeldateisystem).

revert UNIT…
Bringt eine oder mehrere Unit-Dateien auf die Version des Lieferanten zurück. Dieser Befehl entfernt
Ergänzungskonfigurationsdateien, die die festgelegte Unit verändern, sowie alle
benutzerkonfigurierten Unit-Dateien, die eine passende, vom Lieferanten bereitgestellte Unit-Datei
außer Kraft setzen. Konkret wird für eine Unit »foo.service« das passende Verzeichnis
»foo.service.d/« mit allen darin enthaltenen Dateien entfernt, sowohl unterhalb der dauerhaften als
auch der Laufzeitkonfigurationsverzeichnisse (d.h. unterhalb von /etc/systemd/system und
/run/systemd/system). Falls es von der Unit-Datei eine durch den Lieferanten bereitgestellte Version
gibt (d.h. eine Unit-Datei unterhalb von /usr), werden alle passenden dauerhaften und
Laufzeit-Unit-Dateien, die diese außer Kraft setzen, auch entfernt. Beachten Sie, dass eine
Unit-Datei, für die es keine vom Lieferanten bereitgestellte Version gibt (d.h. sie wurde nur
unterhalb von /etc/systemd/system oder /run/systemd/system definiert, aber nicht in einer Unit-Datei
unterhalb von /usr), nicht entfernt wird. Falls eine Unit ausgeblendet ist, wird sie eingeblendet.

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…
Fügt zu dem ZIEL für eine oder mehrere Units Abhängigkeiten »Wants=« bzw. »Requires=« hinzu.

Dieser Befehl berücksichtigt --system, --user, --runtime und --global auf eine ähnliche Art wie
enable.

edit UNIT…
Bearbeitet ein Ergänzungsschnippsel oder eine gesamte Ersetzungsdatei, falls --full festgelegt ist,
oder erweitert die festgelegte Unit oder setzt sie außer Kraft.

Abhängig davon, ob --system (die Vorgabe), --user, oder --global festgelegt 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 --full festgelegt ist, wird diese die ursprüngliche Unit kopieren, statt Ergänzungsdateien zu
erstellen.

Falls --force festgelegt ist und eine der Units nicht existiert, werden neue Unit-Dateien für die
Bearbeitung geöffnet.

Falls --runtime festgelegt 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
Liefert das Standardziel, in welches der Systemstart erfolgt, zurück. Dies liefert den
Ziel-Unit-Namen, auf das der Alias (Symlink) von default.target zeigt.

set-default ZIEL
Setzt das Vorgabeziel, in das der Systemstart erfolgen soll. Dies setzt (als Symlink) den
default.target-Alias auf die angegebene Ziel-Unit.

Maschinenbefehle
list-machines [MUSTER…]
Listet den Rechner und alle laufenden Container mit ihren Zuständen auf. Falls eines oder mehrere
MUSTER festgelegt sind, werden nur auf die Muster passende Container angezeigt.

Auftragsbefehle
list-jobs [MUSTER…]
Listet laufende Aufträge auf. Falls eines oder mehrere MUSTER festgelegt sind, werden nur Aufträge
von Units, die auf die Muster passen, angezeigt.

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…
Bricht einen oder mehrere auf der Befehlszeile durch ihre numerische Auftragskennung festgelegte
Aufträge ab. Falls keine Auftragskennung festgelegt ist, werden alle wartenden Aufträge abgebrochen.

Umgebungsbefehle
show-environment
Zeigt den Umgebungsblock des Systemd-Verwalters an. Dies ist der Umgebungsblock, der an alle vom
Verwalter erzeugten Prozesse übergeben wird. Der Umgebungsblock wird in einer direkten Form, geeignet
für die Einbindung in die meisten Shells, ausgegeben. Falls in den Variablenwerten keine besonderen
Zeichen oder Leerraumzeichen enthalten sind, erfolgt keine Maskierung und die Zuweisungen haben die
Form »VARIABLE=Wert«. Falls Leerraumzeichen oder Zeichen, die für die Shell eine besondere Bedeutung
haben, vorhanden sind, wird Dollar-Einzelanführungszeichen-Maskierung verwandt und die Zuweisungen
haben die Form »VARIABLE=$'Wert'«. Diese Syntax wird bekanntermaßen von bash(1), zsh(1), ksh(1) und
der busybox(1)-ash(1), aber nicht von dash(1) und fish(1) unterstützt.

set-environment VARIABLE=WERT…
Setzt eine oder mehrere Systemd-Verwalter-Umgebungsvariablen, wie auf der Befehlszeile festgelegt.

unset-environment VARIABLE…
Setzt eine oder mehrere Umgebungsvariablen des Systemd-Verwalters zurück. Falls nur ein Variablenname
festgelegt ist, wird er unabhängig von seinem Wert entfernt. Falls eine Variable und ein Wert
festgelegt werden, wird die Variable nur entfernt, falls sie den festgelegten Wert hat.

import-environment [VARIABLE…]
Importiert alle, eine oder mehrere Umgebungsvariablen, die auf dem Client gesetzt sind, in den
Umgebungsblock des Systemd-Verwalters. Falls keine Argumente übergeben werden, wird der gesamte
Umgebungsblock importiert. Andernfalls sollte eine Liste mit einer oder mehrerer
Umgebungsvariablennamen übergeben werden, dessen Wert auf der Client-Seite dann in den Umgebungsblock
des Verwalters importiert wird.

Lebenszyklusbefehle für den Verwalter
daemon-reload
Lädt die Systemverwalterkonfiguration neu. Dies wird alle Generatoren neu ausführen (siehe
systemd.generator(7)), alle Unit-Dateien neu laden und den gesamten Abhängigkeitsbaum neu erstellen.
Während der Daemon neu geladen wird, bleiben sämtliche Sockets, an denen Systemd aufgrund von
Benutzerkonfiguration auf Anfragen wartet, erreichbar.

Dieser Befehl sollte nicht mit dem Befehl reload durcheinandergebracht werden.

daemon-reexec
Führt den Systemd-Verwalter neu aus. Dies wird den Verwalterzustand serialisieren, die Prozesse neu
ausführen und den Zustand wieder deserialisieren. Dieser Befehl ist eigentlich nur für die
Fehlersuche und Paket-Upgrades geeignet. Manchmal mag er für schwergewichtige daemon-reload hilfreich
sein. Während der Daemon neu ausgeführt wird, bleiben sämtliche Sockets, an denen Systemd aufgrund
von Benutzerkonfiguration auf Anfragen wartet, erreichbar.

Systembefehle
is-system-running
Prüft, ob das System einsatzfähig ist. Dies liefert Erfolg (Exit-Code 0) zurück, wenn das System
komplett hochgefahren und im Betrieb und insbesondere nicht beim Hochfahren, beim Herunterfahren oder
im Wartungsmodus ist und wenn keine Dienste fehlgeschlagen sind. Ansonsten wird ein Fehlschlag
zurückgeliefert (Exit-Code ist nicht null). Zusätzlich wird der aktuelle Zustand in einer kurzen
Zeichenkette auf der Standardausgabe ausgegeben, siehe nachfolgende Tabelle. Verwenden Sie --quiet
zum Unterdrücken dieser Ausgabe.

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 │ > 0 │
│ │ basic.target erreicht oder │ │
│ │ der Wartungs- Zustand │ │
│ │ betreten wurde. │ │
├──────────────┼──────────────────────────────┼───────────┤
│ starting │ Späte Startphase, bevor die │ > 0 │
│ │ Auftragswarteschlange │ │
│ │ erstmalig in den Leerlauf │ │
│ │ geht oder eines der │ │
│ │ Rettungsziele erreicht wird. │ │
├──────────────┼──────────────────────────────┼───────────┤
│ running │ Das System ist komplett │ 0 │
│ │ betriebsbereit. │ │
├──────────────┼──────────────────────────────┼───────────┤
│ degraded │ Das System ist │ > 0 │
│ │ betriebsbereit, aber eine │ │
│ │ oder mehrere Units sind │ │
│ │ fehlgeschlagen. │ │
├──────────────┼──────────────────────────────┼───────────┤
│ maintenance │ Das Rettungs- oder │ > 0 │
│ │ Notfallziel ist aktiv. │ │
├──────────────┼──────────────────────────────┼───────────┤
│ stopping │ Der Verwalter fährt sich │ > 0 │
│ │ herunter. │ │
├──────────────┼──────────────────────────────┼───────────┤
│ offline │ Der Verwalter läuft nicht. │ > 0 │
│ │ Insbesondere ist dies der │ │
│ │ Betriebszustand, falls ein │ │
│ │ inkompatibles Programm als │ │
│ │ Systemverwalter (PID 1) │ │
│ │ läuft. │ │
├──────────────┼──────────────────────────────┼───────────┤
│ unknown │ Der Betriebszustand konnte │ > 0 │
│ │ aufgrund von fehlenden │ │
│ │ Ressourcen oder einer │ │
│ │ anderen Fehlerursache nicht │ │
│ │ bestimmt werden. │ │
└──────────────┴──────────────────────────────┴───────────┘

default
Betritt den Standardmodus. Dies ist zu systemctl isolate default.target äquivalent. Diese Aktion
blockiert standardmäßig, verwenden Sie --no-block für asynchrones Verhalten.

rescue
Betritt den Rettungsmodus. Dies ist zu systemctl isolate rescue.target äquivalent. Diese Aktion
blockiert standardmäßig, verwenden Sie --no-block für asynchrones Verhalten.

emergency
Betritt den Notfallmodus. Dies ist zu systemctl isolate emergency.target äquivalent. Diese Aktion
blockiert standardmäßig, verwenden Sie --no-block für asynchrones Verhalten.

halt
Fährt das System herunter und hält es an. Dies ist größtenteils äquivalent zu systemctl start
halt.target --job-mode=replace-irreversibly --no-block, gibt aber auch eine Wall-Nachricht an alle
Benutzer aus. Dieser Befehl ist asynchron; er wird zurückkehren, nachdem die Halt-Aktion in die
Warteschlange eingereiht ist, ohne darauf zu warten, dass er abgeschlossen ist. Beachten Sie, dass
diese Aktion einfach den Betriebssystemkernel nach dem Herunterfahren anhalten wird, die Hardware
verbleibt eingeschaltet. Verwenden Sie systemctl poweroff, um das System auszuschalten (siehe unten).

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 festgelegt 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.

poweroff
Fährt das System herunter und schaltet es aus. Dies ist größtenteils zu systemctl start
poweroff.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
Ausschalt-Aktion in die Warteschlange eingereiht ist, ohne darauf zu warten, dass er abgeschlossen
ist.

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 Ausschalten des Systems. Falls --force zweimal festgelegt 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 Ausschalt-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.

reboot [Arg]
Fährt das System herunter und startet es neu. Dies 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 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 der Neustart des Systems. Falls --force zweimal festgelegt 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 Neustart-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 das optionale Argument Arg angegeben ist, wird es als das optionale Argument an den
Systemaufruf reboot(2) übergeben. Der Wert ist architektur- und firmwarespezifisch. Beispielsweise
könnte »recovery« zum Auslösen der Systemwiederherstellung, »fota« könnte zum Auslösen der
schnurlosen Firmware-Aktualisierung verwandt werden.

kexec
Fährt das System herunter und startet mit kexec neu. Dies ist zu systemctl start kexec.target
--job-mode=replace-irreversibly --no-block äquivalent. 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.

exit [EXIT-CODE]
Bittet den Diensteverwalter, sich zu beenden. Dies wird nur für Benutzerdiensteverwalter (d.h. im
Zusammenspiel mit der Option --user) oder in Containern unterstützt und ist andernfalls zu poweroff
äquivalent. Dieser Befehl ist asynchron; er wird zurückkehren, nachdem die Beende-Aktion in die
Warteschlange eingereiht ist, ohne darauf zu warten, dass er abgeschlossen ist.

Falls EXIT_CODE übergeben wurde, wird sich der Diensteverwalter mit dem festgelegten Exit-Code
beenden.

switch-root WURZEL [INIT]
Schaltet auf ein anderes Wurzelverzeichnis und führt darunter einen neuen Systemverwalter aus. Dies
ist für den Einsatz in anfänglichen RAM-Platten (»initrd«) gedacht und wird vom Systemverwalter der
Initrd (d.h. dem »Init«-Prozess) auf dem Hauptsystemverwalterprozess wechseln, der vom tatsächlichen
Datenträger des Rechners geladen wird. Dieser Aufruf akzeptiert zwei Argumente: das Verzeichnis, das
das neue Wurzelverzeichnis werden soll und der Pfad des neuen Systemverwalterprogramms darunter, das
als PID 1 ausgeführt werden soll. Falls letzterer nicht angegeben wird oder die leere Zeichenkette
ist, wird automatisch nach einem Systemd-Programm gesucht und dieses als Init verwandt/. Falls der
Systemverwalterpfad nicht angegeben wird, der leeren Zeichenkette gleicht oder identisch zu dem Pfad
zu dem Systemdprogramm ist, wird der Zustand des Systemverwalterprozesses der Initrd an den
Hauptsystemverwalter übergeben, womit Letzterem eine Selbstüberprüfung des Zustands der in der
Initird-Systemstartphase beteiligten Dienste ermöglicht wird.

suspend
Suspendiert das System. Dies wird die Aktivierung der besonderen Ziel-Unit suspend.target auslösen.
Dieser Befehl ist asynchron; er wird zurückkehren, nachdem die Suspendier-Aktion erfolgreich in die
Warteschlange eingereiht ist. Er wird nicht darauf warten, dass der Suspendier-/Wiederaufnahmezyklus
abgeschlossen ist.

hibernate
Bringt das System in den Ruhezustand. Dies wird die Aktivierung der besonderen Ziel-Unit
hibernate.target auslösen. Dieser Befehl ist asynchron; er wird zurückkehren, nachdem die
Ruhezustandsaktion erfolgreich in die Warteschlange eingereiht ist. Er wird nicht darauf warten, dass
der Ruhezustand-/Wiederaufwachzyklus abgeschlossen ist.

hybrid-sleep
Das System in den Ruhezustand bringen und suspendieren. Dies wird die Aktivierung der besonderen
Ziel-Unit hybrid-sleep.target auslösen. Dieser Befehl ist asynchron; er wird zurückkehren, nachdem
die hybride Schlafaktion erfolgreich in die Warteschlange eingereiht ist. Er wird nicht darauf
warten, dass der Schlaf-/Wiederaufwachzyklus abgeschlossen ist.

suspend-then-hibernate
Das System nach einer in systemd-sleep.conf festgelegten Verzögerung suspendieren und in den
Ruhezustand bringen. Dies wird die Aktivierung der besonderen Ziel-Unit suspend-then-hibernate.target
auslösen. Dieser Befehl ist asynchron; er wird zurückkehren, nachdem die hybride Schlafaktion
erfolgreich in die Warteschlange eingereiht ist. Er wird nicht darauf warten, dass der
Schlaf-/Wiederaufwachzyklus oder Ruhezustand-/Wiederaufwachzyklus abgeschlossen ist.

Parametersyntax
Die oben aufgeführten Unit-Befehle akzeptieren entweder einen einzelnen Unit-Namen (als UNIT bezeichnet)
oder mehrere Unit-Festlegungen (als MUSTER … bezeichnet). Im ersten Fall muss der Unit-Name mit oder ohne
Endung angegeben werden. Falls die Endung nicht festgelegt 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 festgelegte 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

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[2] definiert sind.

       Tabelle 3. LSB-Rückgabe-Codes
       ┌──────┬─────────────────────────────┬───────────────────────┐
       │ Wert │ Beschreibung in LSB         │ Verwendung in Systemd │
       ├──────┼─────────────────────────────┼───────────────────────┤
       │ 0    │ "Programm läuft oder Dienst │ Unit ist aktiv        │
       │      │ ist OK"                     │                       │
       ├──────┼─────────────────────────────┼───────────────────────┤
       │ 1    │ "Programm ist tot und       │ Unit ist nicht        │
       │      │ /var/run-PID-Datei          │ fehlgeschlagen (von   │
       │      │ existiert"                  │ is-failed verwandt)   │
       ├──────┼─────────────────────────────┼───────────────────────┤
       │ 2    │ "Programm ist tot und       │ nicht benutzt         │
       │      │ /var/lock-Sperrdatei        │                       │
       │      │ existiert"                  │                       │
       ├──────┼─────────────────────────────┼───────────────────────┤
       │ 3    │ "Programm läuft nicht"      │ Unit ist nicht aktiv  │
       ├──────┼─────────────────────────────┼───────────────────────┤
       │ 4    │ "Programm- oder             │ keine solche Unit     │
       │      │ Dienstezustand unbekannt"   │                       │
       └──────┴─────────────────────────────┴───────────────────────┘

       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
Der bei der Bearbeitung von Units zu verwendende Editor: setzt $EDITOR und $VISUAL außer Kraft. Falls
weder $SYSTEMD_EDITOR, $EDITOR noch $VISUAL vorhanden sind oder falls es auf eine leere Zeichenkette
gesetzt ist oder falls seine Ausführung fehlschlug, wird Systemctl versuchen, gut bekannte Editoren
in dieser Reihenfolge auszuführen: editor(1), nano(1), vim(1), vi(1).

$SYSTEMD_PAGER
Zu verwendendes Textanzeigeprogramm, wenn --no-pager nicht angegeben ist, setzt $PAGER außer Kraft.
Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe wohlbekannter
Textanzeigeprogrammimplementierungen der Reihe nach ausprobiert, einschließlich less(1) und more(1),
bis eines gefunden wird. Falls keine Textanzeigeprogrammimplementierung gefunden wird, wird keines
aufgerufen. Setzen der Umgebungsvariablen auf die leere Zeichenkette oder den Wert »cat« ist
äquivalent zur Übergabe von --no-pager.

$SYSTEMD_LESS
Setzt die an less übergebenen Optionen (standardmäßig »FRSXMK«) außer Kraft.

Benutzer könnten insbesondere zwei Optionen ändern wollen:

K
Diese Option weist den Seitenbetrachter an, sich sofort beim Druck von Strg-C zu beenden. Um less
die Handhabung von Strg-C selbst zum Umschalten auf die Eingabeaufforderung zu erlauben, setzen
Sie diese Option zurück.

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
Diese Option weist den Seitenbetrachter an, keine Termcap-Initialisierungs- und
-Deinitalisierungszeichenketten an das Terminal zu senden. Dies ist standardmäßig gesetzt, damit
die Darstellung von Befehlen selbst nach dem Beenden des Seitenanzeigeprogramms sichtbar bleibt.
Allerdings verhindert dies, dass ein Teil der Funktionalität des Seitenbetrachtungsprogramms
funktioniert, insbesondere kann die Ausgabe des Seitenbetrachtungsprogramms nicht mit der Maus
durchlaufen werden.

Siehe less(1) für weitere Ausführungen.

$SYSTEMD_LESSCHARSET
Setzt den an less übergebenen Zeichensatz (standardmäßig »utf-8«, falls das aufrufende Terminal als
UTF-8-kompatibel erkannt wurde) außer Kraft.

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. Voreinstellung
           https://www.freedesktop.org/wiki/Software/systemd/Preset

        2. LSB 3.0.0
           http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html

Ü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
       <debian-l10n-german@lists.debian.org>.

systemd 243                                                                                         SYSTEMCTL(1)