Systemctl: Unterschied zwischen den Versionen

Aus Foxwiki
Subpages:
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
VisuellWikitext
Keine Bearbeitungszusammenfassung
Zeile 237: Zeile 237:
* Die dann unter Umständen mithilfe von Udev generierten Units erscheinen zwar in der Ausgabe von "systemctl", es existieren aber keine passenden Unit-Dateien auf der Festplatte.  
* Die dann unter Umständen mithilfe von Udev generierten Units erscheinen zwar in der Ausgabe von "systemctl", es existieren aber keine passenden Unit-Dateien auf der Festplatte.  
* Von diesen dynamisch generierten Units dürfen aber wiederum andere Units abhängen.
* Von diesen dynamisch generierten Units dürfen aber wiederum andere Units abhängen.
= TMP =
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…]
    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 angegeben sind, werden nur Units,
    die auf diese passen, angezeigt. Die angezeigten Units werden zusätzlich durch
    --type= und --state= gefiltert, falls diese Optionen angegeben sind.
    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-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 angegeben 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 Timer-Units, sortiert nach der Zeit, zu der
    sie ablaufen, auf. Falls eines oder mehrere MUSTER angegeben 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 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…
    Prüft, ob eine der angegebenen 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 angegeben ist, wird dies auch den aktuellen Zustand
    der Unit auf der Standardausgabe ausgeben.
is-failed MUSTER…
    Prüft, ob eine der angegebenen 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 angegeben 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 angegeben sind, wird
    der Systemstatus angezeigt. In Kombination mit --all wird auch der Status aller
    Units angezeigt (in Abhängigkeit von den mit -t angegebenen 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. 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 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 angegeben ist, werden die Eigenschaften des Verwalters
    angezeigt. Falls ein Unit-Name angegeben ist, werden die Eigenschaften der Unit
    angezeigt und falls eine Auftragskennung angegeben 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
    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…
    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.
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.
list-dependencies [UNIT…]
    Zeigt Units, die von den angegebenen Units benötigt und gewünscht werden. Diese
    rekursive Liste folgt den Abhängigkeiten Requires=, Requisite=, ConsistsOf=, Wants=,
    BindsTo=. Falls keine Units angegeben sind, 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.
start MUSTER…
    Startet (aktiviert) eine oder mehrere auf der Befehlszeile angegebene Units.
    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…
    Stoppt (deaktiviert) eine oder mehrere auf der Befehlszeile angegebene 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 angegebene 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 angegebene 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.
    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 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 angegebenen 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 Timer-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 angegeben
    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).
freeze MUSTER…
    Friert eine oder mehrere auf der Befehlszeile angegebene Units mittels des
    Cgroup-Freezers ein.
    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…
    Taut eine oder mehrere auf der Befehlszeile angegebenen Units auf.
    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…
    Setzt die angegebenen 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 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]
    Hängt eine Datei oder ein Verzeichnis von dem Rechner in den angegebenen
    Einhänge-Namensraum der Unit mit bind ein. Das erste Pfadargument ist die Quelldatei
    oder das Quellverzeichnis auf dem Rechner, das zweite Pfadargument ist die Zieldatei
    oder das Zielverzeichnis in dem Einhänge-Namensraum der Unit. Falls letzteres fehlt,
    ist der Zielpfad in dem Einhänge-Namensraum der Unit identisch zum Quellpfad im
    Rechner. Wird dies mit dem Schalter --read-only kombiniert, dann wird eine
    nur-lesbare Bind-Einhängung erstellt. Wird dies mit dem Schalter --mkdir kombiniert,
    dann wird der Zielpfad zuerst erstellt, bevor die Einhängung angewandt wird.
    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]]
    Hängt eine Abbild von dem Rechner in den angegebene Einhänge-Namensraum der Unit
    ein. Das erste Pfadargument ist das Quellabbild auf dem Rechner, das zweite
    Pfadargument ist das Zielverzeichnis in dem Einhänge-Namensraum der Unit (d.h.
    innerhalb von RootImage=/RootDirectory=). Die folgenden Argumente, falls vorhanden,
    werden als Doppelpunkt-getrenntes Tupel von Partitionsnamen und Kommata-getrennten
    Listen von Einhängeoptionen für diese Partition interpretiert. Das Format ist
    identisch zu der Diensteeinstellung MountImages=. Wird dies mit dem Schalter
    --read-only kombiniert, dann wird eine nur-lesbare Einhängung erstellt. Wird dies
    mit dem Schalter --mkdir kombiniert, dann wird der Zielpfad zuerst erstellt, bevor
    die Einhängung angewandt wird.
    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]
    Gibt die aktuelle Protokollierstufe, wie sie von DIENST gemeldet wird, aus, falls
    das Argument STUFE nicht angegeben ist.
    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]
    Gibt das aktuelle Protokollierziel, wie es von DIENST gemeldet wird, aus, falls das
    Argument ZIEL nicht angegeben ist.
    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…]
    Setzt den Zustand »failed« der angegebenen 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.
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 angegeben sind, werden nur
    Units, deren Name auf sie passen, gezeigt (Muster, die auf Unit-Dateisystempfade
    passen, werden nicht unterstützt).
    Anders als list-units wird dieser Befehl zusätzlich zu den explizit instanziierten
    Units Vorlagenunits auflisten.
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 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.
    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…
    Schaltet eine oder mehrere Units aus. Dies entfernt alle Symlinks auf die
    Unit-Dateien, die den angegebenen 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 angegeben
    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]« konfigurierten 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 angegeben, 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.
    Weitere Informationen über das Format der Voreinstellungsrichtlinien finden Sie
    unter systemd.preset(5).
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 angegebenen 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    │ 0        │
    │                  │ in /etc/systemd/system/  │          │
    │                  │ oder flüchtig in          │          │
    │                  │ /run/systemd/system/).    │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"linked"          │ Über einen oder mehrere  │          │
    ├──────────────────┤ Symlinks auf die          │          │
    │"linked-runtime"  │ Unit-Datei 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.              │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"alias"          │ Der Name ist ein Alias    │ 0        │
    │                  │ (Symlink auf eine andere  │          │
    │                  │ Unit-Datei).              │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"masked"          │ Komplett ausgeschaltet,  │          │
    ├──────────────────┤ so dass jede Startaktion  │          │
    │"masked-runtime"  │ darauf 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    │ 0        │
    │                  │ 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.              │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"disabled"        │ Die Unit-Datei ist nicht  │ > 0      │
    │                  │ freigegeben, enthält      │          │
    │                  │ aber einen Abschnitt      │          │
    │                  │ »[Install]« mit          │          │
    │                  │ Installationsanweisungen. │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"generated"      │ Die Unit wurde dynamisch  │ 0        │
    │                  │ mit 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        │ > 0      │
    │                  │ 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.                │          │
    └──────────────────┴───────────────────────────┴───────────┘
mask UNIT…
    Blendet eine oder mehrere Units, wie auf der Befehlszeile angegeben, 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 angegeben, 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 angegebene 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
    angegeben ist, oder erweitert die angegebene Unit oder setzt sie außer Kraft.
    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 --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
    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 angegeben sind, werden nur auf die Muster passende Container
    angezeigt.
Auftragsbefehle
list-jobs [MUSTER…]
    Listet laufende Aufträge auf. Falls eines oder mehrere MUSTER angegeben 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
    angegebene Aufträge ab. Falls keine Auftragskennung angegeben ist, werden alle
    wartenden Aufträge abgebrochen.
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
    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 angegeben. Dieser Befehl wird fehlschlagen, falls die Variablennamen
    und -werte nicht den vorher beschriebenen Regeln folgen.
unset-environment VARIABLE…
    Setzt eine oder mehrere Umgebungsvariablen des Systemd-Verwalters zurück. Falls nur
    ein Variablenname angegeben ist, wird er unabhängig von seinem Wert entfernt. Falls
    eine Variable und ein Wert angegeben werden, wird die Variable nur entfernt, falls
    sie den angegebenen Wert hat.
import-environment VARIABLE…
    Importiert alle, eine oder mehrere Umgebungsvariablen, die auf dem Client gesetzt
    sind, in den Umgebungsblock des Systemd-Verwalters. Falls eine Liste mit einer oder
    mehrerer Umgebungsvariablennamen übergeben wird, werden deren Wert auf der
    Client-Seite dann in den Umgebungsblock des Verwalters importiert. Falls Namen davon
    keine gültigen Umgebungsvariablen sind oder gemäß der oben beschriebenen Regeln
    ungültige Werte haben, wird ein Fehler ausgelöst. Falls keine Argumente übergeben
    werden, wird der gesamte, vom Prozess systemctl geerbte Umgebungsblock importiert.
    In diesem Modus werden alle geerbten und ungültigen Variablen stillschweigend
    ignoriert.
    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
    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.
log-level [STUFE]
    Zeigt die aktuelle Protokollierstufe des Verwalters an, falls kein Argument
    angegeben ist. Falls das optionale Argument STUFE bereitgestellt wird, dann ändert
    der Befehl die aktuelle Protokollierstufe des Verwalters auf STUFE (akzeptiert die
    gleichen Werte wie für das in systemd(1) beschriebene --log-level=).
log-target [ZIEL]
    Zeigt das aktuelle Protokollierziel des Verwalters an, falls kein Argument angegeben
    ist. Falls das optionale Argument ZIEL bereitgestellt wird, dann ändert der Befehl
    das aktuelle Protokollierziel des Verwalters auf ZIEL (akzeptiert die gleichen Werte
    wie für das in systemd(1) beschriebene --log-target=).
service-watchdogs [yes|no]
    Zeigt den aktuellen Zustand des Laufzeitdienste-Watchdogs an, falls kein Argument
    angegeben ist. Falls ein optionales logisches Argument bereitgestellt wird, werden
    die globalen Laufzeitdienste-Watchdogs (WatchdogSec=) und Notfallaktionen (z.B.
    OnFailure= oder StartLimitAction=) aktiviert oder deaktiviert; siehe
    systemd.service(5). Der Hardware-Watchdog ist von dieser Einstellung nicht
    betroffen.
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  │ > 0      │
    │            │ die                      │          │
    │            │ 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      │ > 0      │
    │            │ nicht. Insbesondere ist  │          │
    │            │ dies der                │          │
    │            │ Betriebszustand, falls  │          │
    │            │ ein inkompatibles        │          │
    │            │ Programm als            │          │
    │            │ Systemverwalter (PID 1)  │          │
    │            │ läuft.                  │          │
    ├─────────────┼──────────────────────────┼───────────┤
    │unknown      │ Der Betriebszustand      │ > 0      │
    │            │ konnte 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 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.
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 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 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
    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 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 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 der Schalter --reboot-argument= angegeben ist, wird er als optionales Argument
    an den Systemaufruf reboot(2) übergeben.
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.
    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.
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 angegebenen
    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
    Bringt das System in den Ruhezustand und suspendiert es. 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
    Suspendiert das System nach einer in systemd-sleep.conf angegebenen Verzögerung und
    bringt es in den Ruhezustand. 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-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=
    Dieses Argument sollte eine Kommata-getrennte Liste von Unit-Typen wie service und
    socket sein.
    Begrenzt die Anzeige auf bestimmte Unit-Typen, wenn Units aufgelistet werden, falls
    eines der Argumente ein Unit-Typ ist. 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. Zeigt nur die Units in den angegebenen Zuständen an, wenn diese aufgelistet
    werden. 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=
    Begrenzt die Anzeige auf die angegebenen Eigenschaften bei der Anzeige der
    Eigenschaften von Units/Aufträgen/Verwalter mit dem Befehl show. Das Argument sollte
    eine Kommata-getrennte Liste von Eigenschaftsnamen wie »MainPID« sein. Falls nicht
    angegeben, werden alle bekannten Eigenschaften angezeigt. Falls mehr als einmal
    angegeben, werden alle Eigenschaften mit den angegebenen Namen angezeigt. Für
    Eigenschaftsnamen ist die Shell-Vervollständigung implementiert.
    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
    Äquivalent zu --value --property=, d.h. zeigt den Wert der Eigenschaft ohne den
    Eigenschaftsnamen und »=«. Beachten Sie, dass die einmalige Verwendung von -P auch
    die mit -p/--property= aufgeführten Eigenschaften betrifft.
-a, --all
    Zeigt beim Auflisten von Units mit list-units auch inaktive Units und Units, die
    anderen Units folgen, an. 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.
    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
    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 angegebenen 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
    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
    Zeigt mit list-dependencies Units an, die nach der angegebenen 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.
--with-dependencies
    Bei der Verwendung mit status, cat, list-units und list-unit-files geben diese
    Befehle alle angegebenen Units und die Abhängigkeiten von diesen Units aus.
    Die Optionen --reverse, --after, --before können zur Änderung, welche
    Abhängigkeitsarten gezeigt werden, verwandt werden.
-l, --full
    Verkürzt Unit-Namen, Prozessbaumeinträge, Journal-Ausgabe nicht und schneidet
    Unit-Beschreibungen in der Ausgabe von status, list-units, list-jobs und list-timers
    nicht ab.
    Zeigt auch Installationsziele in der Ausgabe von is-enabled an.
--value
    Zeigt bei der Ausgabe der Eigenschaften mit show nur den Wert an, der
    Eigenschaftsname und das »=« wird übersprungen. Siehe auch obige Option -P.
--show-types
    Zeigt bei der Anzeige von Sockets auch den Typ des Sockets an.
--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«, »flush« oder »triggering«.
    Standardmäßig »replace«, außer wenn der Befehl isolate verwandt wird, da dieser den
    Auftragsmodus »isolate« impliziert.
    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.
-T, --show-transaction
    Zeigt eine knappe Information über alle Aufträge in der Warteschlange an, wenn eine
    Unit in die Warteschlange gestellt wird (beispielsweise als Auswirkung des Aufrufs
    systemctl start oder ähnlichem). 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.
--check-inhibitors=
    Diese Option steuert, wie mit Unterdrückungssperren umgegangen werden soll, wenn das
    Herunterfahren oder der Schlafzustand erbeten wurde. Sie akzeptiert entweder »auto«,
    »yes« oder »no«. Standardmäßig »auto«, das sich wie »yes« für interaktive Aufrufe
    (d.h. von einem TTY) und wie »no« für nicht interaktive Aufrufe verhalten wird.
    »yes« ermöglicht es, dass die Anfrage Unterdrückungssperren berücksichtigt. »no«
    führt dazu, dass die Anfrage Unterdrückungssperren ignoriert.
    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 »no« oder »auto« bei
    nicht interaktiven Anfragen angegeben wurde, werden die etablierten Sperren
    ignoriert und nicht angezeigt und die Aktion wird dennoch versucht, wobei
    möglicherweise zusätzliche Privilegien benötigt werden. Kann durch --force außer
    Kraft gesetzt werden.
-i
    Kurzform für --check-inhibitors=no.
--dry-run
    Gibt einfach aus, was getan würde. Momentan von den Unterbefehlen 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 angegeben 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
    Versendet keine Wall-Nachrichten vor halt, power-off und reboot.
--global
    Agiert im globalen Benutzerverzeichnis, falls mit enable und disable verwandt, und
    gibt somit eine Unit-Datei global für alle zukünftigen Anmeldungen aller Benutzer
    frei oder schaltetet sie aus.
--no-reload
    Lädt Daemon-Konfiguration nach der Ausführung der Änderung nicht implizit neu, falls
    mit enable und disable verwandt.
--no-ask-password
    Deaktiviert bei der Verwendung mit start und verwandten Befehlen 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 angegeben 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=
    Sucht bei der Verwendung mit kill das Signal aus, 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.
    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=
    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 angegeben werden, wodurch alle angegebenen Ressourcentypen entfernt werden.
    Akzeptiert auch den besonderen Wert all, als Abkürzung zur Angabe aller fünf
    Ressourcentypen. Falls diese Option nicht angegeben 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
    Setzt bei der Verwendung mit enable alle existierenden, im Konflikt stehenden
    Symlinks außer Kraft.
    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=
    Setzt bei der Verwendung mit halt, poweroff oder reboot eine kurze Nachricht, die
    den Grund für die Aktion beschreibt. Die Nachricht wird zusammen mit der
    Standard-Herunterfahrnachricht protokolliert.
--now
    Startet bei der Verwendung mit enable die Units auch. 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=
    Verwendet beim Einsatz mit enable/disable/is-enabled (und verwandten Befehlen) die
    angegebenen 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
    Führt bei der Verwendung mit enable, disable, edit (und verwandten Befehlen)
    Änderungen nur temporär durch, 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«. Steuert bei der
    Verwendung mit den Befehlen preset oder preset-all, 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. Für die Auswahlmöglichkeiten siehe journalctl(1). 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.
--reboot-argument=
    Dieser Schalter wird mit reboot verwandt. 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.
--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.
--timestamp=
    Ändert das Format der ausgegebenen Zeitstempel. Die folgenden Werte können verwandt
    werden:
    pretty (dies ist die Vorgabe)
        "Tag YYYY-MM-DD HH:MM:SS TZ"
    us, µs
        "Tag YYYY-MM-DD HH:MM:SS.UUUUUU TZ"
    utc
        "Tag YYYY-MM-DD HH:MM:SS UTC"
    us+utc, µs+utc
        "Tag YYYY-MM-DD HH:MM:SS.UUUUUU UTC"
--mkdir
    Wird dies mit bind verwandt, dann wird die Zieldatei oder das Zielverzeichnis
    erstellt, bevor die Bind-Einhängung angewandt wird. Beachten Sie, dass der Name
    dieser Option zwar anzeigt, dass sie nur für Verzeichnisse geeignet ist, sie aber
    auch den Zieldateiknoten, über den eingehängt werden soll, falls das einzuhängende
    Objekt kein Verzeichnis, sondern eine reguläre Datei, ein Geräteknoten, ein Socket
    oder ein FIFO ist, erstellt.
--marked
    Nur zusammen mit reload-or-restart erlaubt. Stellt Neustartaufträge für alle Units,
    die die Markierung »needs-restart« tragen und Neulade-Aufträge für Units, die die
    Markierung »needs-reload« tragen, in die Warteschlange. Wenn eine Unit, die zum
    Neuladen markiert ist, kein Neuladen unterstützt, dann wird ein Neustart in die
    Warteschlange eingestellt. Diese Eigenschaften können mittels set-property Marks
    gesetzt werden.
    systemctl wird darauf warten, dass in die Warteschlange eingestellte Aufträge sich
    beenden, außer wenn --no-block verwandt wird.
--read-only
    Erstellt bei der Verwendung mit bind eine nur lesbare Bind-Einhängung.
-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 angegebenen 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. Optional kann diesem ein Benutzername, abgetrennt
    durch ein »@«-Zeichen, als der verbunden werden soll, vorangestellt werden. Falls
    die besondere Zeichenkette ».host« anstelle des Container-Names verwandt wird, wird
    eine Verbindung zu dem lokalen System aufgebaut (das ist nützlich, um sich zu dem
    Benutzerbus eines bestimmten Benutzers zu verbinden: »--user
    --machine=lennart@.host«. Falls die »@«-Syntax nicht verwandt wird, wird die
    Verbindung als Benutzer »root« vorgenommen. Falls die »@«-Syntax verwandt wird, kann
    entweder die linke oder die rechte Seite fortgelassen werden (aber nicht beide). In
    diesem Fall wird der lokale Benutzername und ».host« angenommen.
--no-pager
    Leitet die Ausgabe nicht an ein Textanzeigeprogramm weiter.
--legend=LOGISCH
    Aktiviert oder deaktiviert die Ausgabe der Legende, d.h. der Spaltenüberschriften
    und der Fußzeile mit Hinweisen. Standardmäßig wird die Legende ausgegeben, außer
    dies wurde mit --quiet oder ähnlichem deaktiviert.
-h, --help
    Zeigt einen kurzen Hilfetext an und beendet das Programm.
--version
    Zeigt eine kurze Versionszeichenkette an und beendet das Programm.
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[1]
definiert sind.
Tabelle 3. LSB-Rückgabe-Codes
┌─────┬────────────────────────┬───────────────────────┐
│Wert │ Beschreibung in LSB    │ Verwendung in Systemd │
├─────┼────────────────────────┼───────────────────────┤
│0    │ "Programm läuft oder  │ Unit ist aktiv        │
│    │ Dienst 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 verwandt        │
│    │ /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_LOG_LEVEL
    Die maximale Protokollierstufe ausgesandter Nachrichten (Nachrichten mit einer
    höheren Protokollierstufe, d.h. weniger wichtige, werden unterdrückt). Sie muss (in
    absteigender Reihenfolge) entweder alert, crit, err, warning, notice, info, debug
    oder eine Ganzzahl im Bereich 0…7 sein. Siehe syslog(3) für weitere Informationen.
$SYSTEMD_LOG_COLOR
    Ein logischer Wert. Falls wahr, werden auf das TTY geschriebene Nachrichten gemäß
    ihrer Priorität eingefärbt.
    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
    Ein logischer Wert. Falls wahr, wird den Protokollnachrichten der Konsole ein
    Zeitstempel vorangestellt.
    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 werden.
$SYSTEMD_LOG_LOCATION
    Ein logischer Wert. Falls wahr, wird den Protokollnachrichten ein Dateinamen und
    eine Zeilenummer in dem Quellcode, aus dem die Nachrichten stammen, vorangestellt.
    Beachten Sie, dass der Protokollierort sowieso oft als Metadaten zu den
    Journal-Einträgen angehängt ist. Die Aufnahme in den Nachrichtentext kann bei der
    Fehlersuche in Programmen dennoch praktisch sein.
$SYSTEMD_LOG_TARGET
    Das Ziel für Protokolliernachrichten. Entweder console (auf das angehängte TTY
    protokollieren), console-prefixed (auf das angehängte TTY protokollieren, aber die
    Protokollierstufe und »Einrichtung« voranstellen, siehe syslog(3)), kmsg (in den
    zirkulären Kernel-Protokollpuffer protokollieren), journal (in das Journal
    protokollieren (journal-or-kmsg (in das Journal protokollieren, falls verfügbar, und
    andernfalls nach Kmsg), auto (das geeignete Protokollierziel automatisch ermitteln,
    die Vorgabe) oder null (die Protokollierung deaktivieren).
$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 das Textanzeigeprogramm an, sich sofort beim Druck von Strg-C
        zu beenden. Um less die Handhabung von Strg-C selbst zum Umschalten auf die
        Eingabeaufforderung zu erlauben, setzen Sie diese Option 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 das Textanzeigeprogramm 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 Textanzeigeprogramms sichtbar bleibt. Allerdings stehen dadurch
        einige Funktionen des Textanzeigeprogramms nicht zur Verfügung; insbesondere ist
        das Scrollen in der Ausgabe mit der Maus nicht möglich.
    Siehe less(1) für weitere Ausführungen.
$SYSTEMD_LESSCHARSET
    Setzt den an less zu übergebenden Zeichensatz (standardmäßig »utf-8«, falls das
    aufrufende Terminal als UTF-8-kompatibel erkannt wurde) außer Kraft.
$SYSTEMD_PAGERSECURE
    Akzeptiert einen logischen Wert. Wenn wahr, wird der »sichere« Modus des
    Seitenanzeigeprogramms verwandt, falls falsch, wird dieser deaktiviert. Falls
    $SYSTEMD_PAGERSECURE überhaupt nicht gesetzt ist, dann wird der sichere Modus
    aktiviert, falls die effektive Kennung nicht identisch zu dem Eigentümer der
    Anmeldesitzung ist, siehe geteuid(2) und sd_pid_get_owner_uid(3). Im sicheren Modus
    wird LESSSECURE=1 beim Aufruf des Seitenanzeigeprogramms gesetzt und das
    Seitenanzeigeprogramm muss Befehle deaktivieren, die neue Dateien öffnen oder
    erstellen oder die einen neuen Unterprozess starten. Falls $SYSTEMD_PAGERSECURE
    überhaupt nicht gesetzt ist, werden Seitenanzeigeprogramme, bei denen unbekannt ist,
    ob sie einen sicheren Modus implementieren, nicht verwandt. (Derzeit implementiert
    nur less(1) einen sicheren Modus.)
    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 Seitenanzeigeprogramm 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 den Seitenanzeiger komplett mit --no-pager zu
    deaktivieren.
$SYSTEMD_COLORS
    Akzeptiert ein logisches Argument. Wenn wahr, werden systemd und verwandte
    Hilfswerkzeuge Farben in ihrer Ausgabe verwenden, andernfalls wird die Ausgabe
    einfarbig sein. Zusätzlich kann die Variable eine der folgenden besonderen Werte
    annehmen: »16«, »256«, um die Verwendung von Farbe auf die grundlegenden 16 bzw. 256
    ANSI-Farben zu beschränken. Dies kann festgelegt werden, um die auf $TERM und der
    vorliegenden Verbindung der Konsole basierende automatische Entscheidung außer Kraft
    zu setzen.
$SYSTEMD_URLIFY
    Dies muss ein logischer Wert sein. Er steuert, ob anklickbare Links für
    Terminal-Emulatoren, die dies unterstützen, erstellt werden sollen. Dies kann
    angegeben werden, um die Entscheidung, die systemd basierend auf $TERM und anderen
    Bedingungen trifft, außer Kraft zu setzen.
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. 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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copy‐
right-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 ⟨debian-l10n-german@lists.debian.org⟩.
systemd 250                                                                        SYSTEMCTL(1)




[[Category:Linux:Systemd]]
[[Category:Linux:Systemd]]
[[Category:Linux:Befehl]]
[[Category:Linux:Befehl]]

Version vom 30. Mai 2022, 13:21 Uhr

systemctl steuert den Systemd

Beschreibung

Installation

Syntax

Parameter

Optionen

Umgebungsvariablen

Exit-Status

Konfiguration

Dateien

Anwendungen

Sicherheit

Dokumentation

RFC

Man-Pages

Info-Pages

Siehe auch

Links

Projekt-Homepage

Weblinks

Einzelnachweise


Testfragen

Testfrage 1

Antwort1

Testfrage 2

Antwort2

Testfrage 3

Antwort3

Testfrage 4

Antwort4

Testfrage 5

Antwort5

TMP

Anwendungen

  • Änderungen als root
    • Alle vorgestellten Informationen darf jeder Nutzer abfragen.
  • Um Änderungen an der Konfiguration vorzunehmen, müssen Sie "systemctl" jedoch mit Root-Rechten starten.
  • Dann lassen sich einzelne Units über »systemctl start« aktivieren beziehungsweise mit »systemctl stop« anhalten.

Der folgende Befehl fährt den SSH-Daemon hoch: 

# systemctl start sshd.service
  • Auf Systemen mit SysV-Init würde dies dem Aufruf des Skripts "/etc/init.d/sshd start" entsprechen.
  • Vergessen Sie im Unit-Namen den Typ, geht Systemd von ".service" aus.
  • Den SSH-Daemon könnten Sie folglich einfach mit »systemctl start sshd« anwerfen. "systemctl" wechselt natürlich auch Targets.

Der folgende Befehl aktiviert beispielsweise das Target "rescue.target", was wiederum zu einem Rettungssystem führt: 

# systemctl isolate rescue.target
  • Die Angabe "isolate" sorgt dafür, dass ausschließlich die von "rescue.target" vorgegebenen Units aktiv sind, alle anderen Dienste und Units beendet Systemd.

Um zu verhindern, dass ein Dienst beim Systemstart automatisch hochfährt, deaktivieren Sie ihn: 

# systemctl disable sshd.service

In diesem Beispiel würde Systemd den SSH-Daemon aus sämtlichen Targets nehmen. Mit "enable" knipsen Sie ihn wieder an: 

# systemctl enable sshd.service

Damit gehört der SSH-Daemon wieder zu allen Targets, die in seiner Unit-Datei (aus dem Listing "sshd.service") hinter "WantedBy" vermerkt sind.

  • Im Hintergrund setzt Systemd dabei übrigens lediglich die symbolischen Links in den ".wants"-Unterverzeichnissen.
[[Image:Bild1.png|top]]
  • Bild 2: In den Status-Informationen liefert "systemctl" unter anderem auch die PID (hier die 1270) und die Laufzeit des Dienstes (hier über eine Stunde).

Wichtige Systemd-Befehle

systemctl  
systemctl start sshd.service  
systemctl stop sshd.service  
systemctl disable sshd.service  
systemctl enable sshd.service  
systemctl --failed  
systemctl isolate graphical.target  
systemctl isolate multi-user.target  
systemctl daemon-reload  

Listing running services

# systemctl
UNIT                       LOAD   ACTIVE SUB         JOB DESCRIPTION
accounts-daemon.service    loaded active running     Accounts Service
atd.service                loaded active running     Job spooling tools
avahi-daemon.service       loaded active running     Avahi mDNS/DNS-SD Stack
bluetooth.service          loaded active running     Bluetooth Manager
colord-sane.service        loaded active running     Daemon for monitoring attached scanners and registering them with colord
colord.service             loaded active running     Manage, Install and Generate Color Profiles
crond.service              loaded active running     Command Scheduler
cups.service               loaded active running     CUPS Printing Service
dbus.service               loaded active running     D-Bus System Message Bus
...

Showing runtime status

#  systemctl status udisks2.service
udisks2.service - Storage Daemon
          Loaded: loaded (/usr/lib/systemd/system/udisks2.service; static)
          Active: active (running) since Wed, 27 Jun 2012 20:49:25 +0200; 1 day and 1h ago
        Main PID: 615 (udisksd)
          CGroup: name=systemd:/system/udisks2.service
                  └ 615 /usr/lib/udisks2/udisksd --no-debug

Jun 27 20:49:25 epsilon udisksd[615]: udisks daemon version 1.94.0 starting
Jun 27 20:49:25 epsilon udisksd[615]: Acquired the name org.freedesktop.UDisks2 on the system message bus

Runlevel

What would get started?

… if I booted into a specific target?

  • If you want systemd to calculate the "initial" transaction it would execute on boot, try something like this:
# systemd --test --system --unit=foobar.target

for a boot target foobar.target. Note that this is mostly a debugging tool that actually does a lot more than just calculate the initial transaction, so don't build scripts based on this.

Change current runlevel

In systemd runlevels are exposed via "target units". You can change them like this: 

# systemctl isolate runlevel5.target
  • Note however, that the concept of runlevels is a bit out of date, and it is usually nicer to use modern names for this. e.g.:
# systemctl isolate graphical.target
  • This will only change the current runlevel, and has no effect on the next boot.

Change default runlevel

  • The symlink /etc/systemd/system/default.target controls where we boot into by default. Link it to the target unit of your choice. For example, like this:
 # ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target

or 

 # ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target

Current runlevel

Note that there might be more than one target active at the same time. So the question regarding the runlevel might not always make sense. Here's how you would figure out all targets that are currently active: 

 $ systemctl list-units --type=target
  • If you are just interested in a single number, you can use the venerable runlevel command, but again, its output might be misleading.

Enable another getty

Simply instantiate a new getty service for the port of your choice (internally, this places another symlink for instantiating another serial getty in the getty.target.wants/ directory). 

# systemctl enable serial-getty@ttyS2.service
# systemctl start serial-getty@ttyS2.service
  • Note that gettys on the virtual console are started on demand. You can control how many you get via the NAutoVTs= setting in logind.conf(7). Also see this blog story.

Which service a process belongs to?

You may either use ps for that: 

$ alias psc='ps xawf -eo pid,user,cgroup,args'
$ psc
...
  • Or you can even check /proc/$PID/cgroup directly.
  • Also see this blog story.

journalctl - display full messages

Even if less is not used? 

# journalctl --full

/tmp and tmpfs

Links

Dateien

Man-Pages

Intern

  1. cgroups

Weblinks

Kontrollfragen

Testfrage 1

Antwort1

Testfrage 2

Antwort2

Testfrage 3

Antwort3

Testfrage 4

Antwort4

Testfrage 5

Antwort5

TMP

Beschreibung

  • Wer nur an bestimmten Units interessiert ist, kann die Anzeige über den Parameter "--type=" einschränken.
  • Alle Dienste präsentiert etwa "systemctl --type=service".
  • Die Ausgaben von "systemctl" zeigt standardmäßig "less" an, die Navigation erfolgt mit den Pfeiltasten und der Leertaste, [q] wiederum beendet die Anzeige.
  • Neben dem Namen der Unit verrät "systemctl" in der zweiten und dritten Spalte, ob es die Unit laden und aktivieren konnte.
  • Die Spalte "SUB" gibt Auskunft über den derzeitigen Status: Bei einem Dateisystem erfährt man etwa, ob dieses gemountet ist, bei einem Dienst hingegen, ob dieser läuft ("running").
  • In der letzten Spalte findet man schließlich noch eine kurze Beschreibung der Unit.
  • Sofern ein Dienst beim Start nicht hochfahren wollte oder abgestürzt ist, markiert "systemctl" dies in seiner Ausgabe in hell leuchtendem Rot.
  • Eine Liste mit allen nicht funktionierenden Units liefert "systemctl --failed", detaillierte Informationen über eine Unit zeigt ein Aufruf von "systemctl status" an
  • In bestimmten Situationen erzeugt Systemd selbst eine Unit.
  • Das passiert beispielsweise nach dem Anstöpseln eines neuen Gerätes.
  • Die dann unter Umständen mithilfe von Udev generierten Units erscheinen zwar in der Ausgabe von "systemctl", es existieren aber keine passenden Unit-Dateien auf der Festplatte.
  • Von diesen dynamisch generierten Units dürfen aber wiederum andere Units abhängen.

TMP

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…]
    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 angegeben sind, werden nur Units,
    die auf diese passen, angezeigt. Die angezeigten Units werden zusätzlich durch
    --type= und --state= gefiltert, falls diese Optionen angegeben sind.

    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-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 angegeben 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 Timer-Units, sortiert nach der Zeit, zu der
    sie ablaufen, auf. Falls eines oder mehrere MUSTER angegeben 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 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…
    Prüft, ob eine der angegebenen 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 angegeben ist, wird dies auch den aktuellen Zustand
    der Unit auf der Standardausgabe ausgeben.

is-failed MUSTER…
    Prüft, ob eine der angegebenen 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 angegeben 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 angegeben sind, wird
    der Systemstatus angezeigt. In Kombination mit --all wird auch der Status aller
    Units angezeigt (in Abhängigkeit von den mit -t angegebenen 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. 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 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 angegeben ist, werden die Eigenschaften des Verwalters
    angezeigt. Falls ein Unit-Name angegeben ist, werden die Eigenschaften der Unit
    angezeigt und falls eine Auftragskennung angegeben 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
    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…
    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.

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.

list-dependencies [UNIT…]
    Zeigt Units, die von den angegebenen Units benötigt und gewünscht werden. Diese
    rekursive Liste folgt den Abhängigkeiten Requires=, Requisite=, ConsistsOf=, Wants=,
    BindsTo=. Falls keine Units angegeben sind, 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.

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

    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…
    Stoppt (deaktiviert) eine oder mehrere auf der Befehlszeile angegebene 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 angegebene 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 angegebene 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.

    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 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 angegebenen 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 Timer-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 angegeben
    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).

freeze MUSTER…
    Friert eine oder mehrere auf der Befehlszeile angegebene Units mittels des
    Cgroup-Freezers ein.

    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…
    Taut eine oder mehrere auf der Befehlszeile angegebenen Units auf.

    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…
    Setzt die angegebenen 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 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]
    Hängt eine Datei oder ein Verzeichnis von dem Rechner in den angegebenen
    Einhänge-Namensraum der Unit mit bind ein. Das erste Pfadargument ist die Quelldatei
    oder das Quellverzeichnis auf dem Rechner, das zweite Pfadargument ist die Zieldatei
    oder das Zielverzeichnis in dem Einhänge-Namensraum der Unit. Falls letzteres fehlt,
    ist der Zielpfad in dem Einhänge-Namensraum der Unit identisch zum Quellpfad im
    Rechner. Wird dies mit dem Schalter --read-only kombiniert, dann wird eine
    nur-lesbare Bind-Einhängung erstellt. Wird dies mit dem Schalter --mkdir kombiniert,
    dann wird der Zielpfad zuerst erstellt, bevor die Einhängung angewandt wird.

    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]]
    Hängt eine Abbild von dem Rechner in den angegebene Einhänge-Namensraum der Unit
    ein. Das erste Pfadargument ist das Quellabbild auf dem Rechner, das zweite
    Pfadargument ist das Zielverzeichnis in dem Einhänge-Namensraum der Unit (d.h.
    innerhalb von RootImage=/RootDirectory=). Die folgenden Argumente, falls vorhanden,
    werden als Doppelpunkt-getrenntes Tupel von Partitionsnamen und Kommata-getrennten
    Listen von Einhängeoptionen für diese Partition interpretiert. Das Format ist
    identisch zu der Diensteeinstellung MountImages=. Wird dies mit dem Schalter
    --read-only kombiniert, dann wird eine nur-lesbare Einhängung erstellt. Wird dies
    mit dem Schalter --mkdir kombiniert, dann wird der Zielpfad zuerst erstellt, bevor
    die Einhängung angewandt wird.

    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]
    Gibt die aktuelle Protokollierstufe, wie sie von DIENST gemeldet wird, aus, falls
    das Argument STUFE nicht angegeben ist.

    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]
    Gibt das aktuelle Protokollierziel, wie es von DIENST gemeldet wird, aus, falls das
    Argument ZIEL nicht angegeben ist.

    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…]
    Setzt den Zustand »failed« der angegebenen 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.

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 angegeben sind, werden nur
    Units, deren Name auf sie passen, gezeigt (Muster, die auf Unit-Dateisystempfade
    passen, werden nicht unterstützt).

    Anders als list-units wird dieser Befehl zusätzlich zu den explizit instanziierten
    Units Vorlagenunits auflisten.

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

    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…
    Schaltet eine oder mehrere Units aus. Dies entfernt alle Symlinks auf die
    Unit-Dateien, die den angegebenen 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 angegeben
    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]« konfigurierten 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 angegeben, 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.

    Weitere Informationen über das Format der Voreinstellungsrichtlinien finden Sie
    unter systemd.preset(5).

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 angegebenen 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    │ 0         │
    │                  │ in /etc/systemd/system/   │           │
    │                  │ oder flüchtig in          │           │
    │                  │ /run/systemd/system/).    │           │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"linked"          │ Über einen oder mehrere   │           │
    ├──────────────────┤ Symlinks auf die          │           │
    │"linked-runtime"  │ Unit-Datei 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.              │           │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"alias"           │ Der Name ist ein Alias    │ 0         │
    │                  │ (Symlink auf eine andere  │           │
    │                  │ Unit-Datei).              │           │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"masked"          │ Komplett ausgeschaltet,   │           │
    ├──────────────────┤ so dass jede Startaktion  │           │
    │"masked-runtime"  │ darauf 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     │ 0         │
    │                  │ 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.              │           │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"disabled"        │ Die Unit-Datei ist nicht  │ > 0       │
    │                  │ freigegeben, enthält      │           │
    │                  │ aber einen Abschnitt      │           │
    │                  │ »[Install]« mit           │           │
    │                  │ Installationsanweisungen. │           │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"generated"       │ Die Unit wurde dynamisch  │ 0         │
    │                  │ mit 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        │ > 0       │
    │                  │ 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.                │           │
    └──────────────────┴───────────────────────────┴───────────┘

mask UNIT…
    Blendet eine oder mehrere Units, wie auf der Befehlszeile angegeben, 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 angegeben, 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 angegebene 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
    angegeben ist, oder erweitert die angegebene Unit oder setzt sie außer Kraft.

    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 --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
    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 angegeben sind, werden nur auf die Muster passende Container
    angezeigt.

Auftragsbefehle 

list-jobs [MUSTER…]
    Listet laufende Aufträge auf. Falls eines oder mehrere MUSTER angegeben 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
    angegebene Aufträge ab. Falls keine Auftragskennung angegeben ist, werden alle
    wartenden Aufträge abgebrochen.

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
    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 angegeben. Dieser Befehl wird fehlschlagen, falls die Variablennamen
    und -werte nicht den vorher beschriebenen Regeln folgen.

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

import-environment VARIABLE…
    Importiert alle, eine oder mehrere Umgebungsvariablen, die auf dem Client gesetzt
    sind, in den Umgebungsblock des Systemd-Verwalters. Falls eine Liste mit einer oder
    mehrerer Umgebungsvariablennamen übergeben wird, werden deren Wert auf der
    Client-Seite dann in den Umgebungsblock des Verwalters importiert. Falls Namen davon
    keine gültigen Umgebungsvariablen sind oder gemäß der oben beschriebenen Regeln
    ungültige Werte haben, wird ein Fehler ausgelöst. Falls keine Argumente übergeben
    werden, wird der gesamte, vom Prozess systemctl geerbte Umgebungsblock importiert.
    In diesem Modus werden alle geerbten und ungültigen Variablen stillschweigend
    ignoriert.

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

log-level [STUFE]
    Zeigt die aktuelle Protokollierstufe des Verwalters an, falls kein Argument
    angegeben ist. Falls das optionale Argument STUFE bereitgestellt wird, dann ändert
    der Befehl die aktuelle Protokollierstufe des Verwalters auf STUFE (akzeptiert die
    gleichen Werte wie für das in systemd(1) beschriebene --log-level=).

log-target [ZIEL]
    Zeigt das aktuelle Protokollierziel des Verwalters an, falls kein Argument angegeben
    ist. Falls das optionale Argument ZIEL bereitgestellt wird, dann ändert der Befehl
    das aktuelle Protokollierziel des Verwalters auf ZIEL (akzeptiert die gleichen Werte
    wie für das in systemd(1) beschriebene --log-target=).

service-watchdogs [yes|no]
    Zeigt den aktuellen Zustand des Laufzeitdienste-Watchdogs an, falls kein Argument
    angegeben ist. Falls ein optionales logisches Argument bereitgestellt wird, werden
    die globalen Laufzeitdienste-Watchdogs (WatchdogSec=) und Notfallaktionen (z.B.
    OnFailure= oder StartLimitAction=) aktiviert oder deaktiviert; siehe
    systemd.service(5). Der Hardware-Watchdog ist von dieser Einstellung nicht
    betroffen.

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  │ > 0       │
    │             │ die                      │           │
    │             │ 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      │ > 0       │
    │             │ nicht. Insbesondere ist  │           │
    │             │ dies der                 │           │
    │             │ Betriebszustand, falls   │           │
    │             │ ein inkompatibles        │           │
    │             │ Programm als             │           │
    │             │ Systemverwalter (PID 1)  │           │
    │             │ läuft.                   │           │
    ├─────────────┼──────────────────────────┼───────────┤
    │unknown      │ Der Betriebszustand      │ > 0       │
    │             │ konnte 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 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.

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 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 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
    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 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 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 der Schalter --reboot-argument= angegeben ist, wird er als optionales Argument
    an den Systemaufruf reboot(2) übergeben.

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.

    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.

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 angegebenen
    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
    Bringt das System in den Ruhezustand und suspendiert es. 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
    Suspendiert das System nach einer in systemd-sleep.conf angegebenen Verzögerung und
    bringt es in den Ruhezustand. 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-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=
    Dieses Argument sollte eine Kommata-getrennte Liste von Unit-Typen wie service und
    socket sein.

    Begrenzt die Anzeige auf bestimmte Unit-Typen, wenn Units aufgelistet werden, falls
    eines der Argumente ein Unit-Typ ist. 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. Zeigt nur die Units in den angegebenen Zuständen an, wenn diese aufgelistet
    werden. 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=
    Begrenzt die Anzeige auf die angegebenen Eigenschaften bei der Anzeige der
    Eigenschaften von Units/Aufträgen/Verwalter mit dem Befehl show. Das Argument sollte
    eine Kommata-getrennte Liste von Eigenschaftsnamen wie »MainPID« sein. Falls nicht
    angegeben, werden alle bekannten Eigenschaften angezeigt. Falls mehr als einmal
    angegeben, werden alle Eigenschaften mit den angegebenen Namen angezeigt. Für
    Eigenschaftsnamen ist die Shell-Vervollständigung implementiert.

    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
    Äquivalent zu --value --property=, d.h. zeigt den Wert der Eigenschaft ohne den
    Eigenschaftsnamen und »=«. Beachten Sie, dass die einmalige Verwendung von -P auch
    die mit -p/--property= aufgeführten Eigenschaften betrifft.

-a, --all
    Zeigt beim Auflisten von Units mit list-units auch inaktive Units und Units, die
    anderen Units folgen, an. 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.

    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
    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 angegebenen 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
    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
    Zeigt mit list-dependencies Units an, die nach der angegebenen 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.

--with-dependencies
    Bei der Verwendung mit status, cat, list-units und list-unit-files geben diese
    Befehle alle angegebenen Units und die Abhängigkeiten von diesen Units aus.

    Die Optionen --reverse, --after, --before können zur Änderung, welche
    Abhängigkeitsarten gezeigt werden, verwandt werden.

-l, --full
    Verkürzt Unit-Namen, Prozessbaumeinträge, Journal-Ausgabe nicht und schneidet
    Unit-Beschreibungen in der Ausgabe von status, list-units, list-jobs und list-timers
    nicht ab.

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

--value
    Zeigt bei der Ausgabe der Eigenschaften mit show nur den Wert an, der
    Eigenschaftsname und das »=« wird übersprungen. Siehe auch obige Option -P.

--show-types
    Zeigt bei der Anzeige von Sockets auch den Typ des Sockets an.

--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«, »flush« oder »triggering«.
    Standardmäßig »replace«, außer wenn der Befehl isolate verwandt wird, da dieser den
    Auftragsmodus »isolate« impliziert.

    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.

-T, --show-transaction
    Zeigt eine knappe Information über alle Aufträge in der Warteschlange an, wenn eine
    Unit in die Warteschlange gestellt wird (beispielsweise als Auswirkung des Aufrufs
    systemctl start oder ähnlichem). 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.

--check-inhibitors=
    Diese Option steuert, wie mit Unterdrückungssperren umgegangen werden soll, wenn das
    Herunterfahren oder der Schlafzustand erbeten wurde. Sie akzeptiert entweder »auto«,
    »yes« oder »no«. Standardmäßig »auto«, das sich wie »yes« für interaktive Aufrufe
    (d.h. von einem TTY) und wie »no« für nicht interaktive Aufrufe verhalten wird.
    »yes« ermöglicht es, dass die Anfrage Unterdrückungssperren berücksichtigt. »no«
    führt dazu, dass die Anfrage Unterdrückungssperren ignoriert.

    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 »no« oder »auto« bei
    nicht interaktiven Anfragen angegeben wurde, werden die etablierten Sperren
    ignoriert und nicht angezeigt und die Aktion wird dennoch versucht, wobei
    möglicherweise zusätzliche Privilegien benötigt werden. Kann durch --force außer
    Kraft gesetzt werden.

-i
    Kurzform für --check-inhibitors=no.

--dry-run
    Gibt einfach aus, was getan würde. Momentan von den Unterbefehlen 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 angegeben 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
    Versendet keine Wall-Nachrichten vor halt, power-off und reboot.

--global
    Agiert im globalen Benutzerverzeichnis, falls mit enable und disable verwandt, und
    gibt somit eine Unit-Datei global für alle zukünftigen Anmeldungen aller Benutzer
    frei oder schaltetet sie aus.

--no-reload
    Lädt Daemon-Konfiguration nach der Ausführung der Änderung nicht implizit neu, falls
    mit enable und disable verwandt.

--no-ask-password
    Deaktiviert bei der Verwendung mit start und verwandten Befehlen 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 angegeben 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=
    Sucht bei der Verwendung mit kill das Signal aus, 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.

    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=
    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 angegeben werden, wodurch alle angegebenen Ressourcentypen entfernt werden.
    Akzeptiert auch den besonderen Wert all, als Abkürzung zur Angabe aller fünf
    Ressourcentypen. Falls diese Option nicht angegeben 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
    Setzt bei der Verwendung mit enable alle existierenden, im Konflikt stehenden
    Symlinks außer Kraft.

    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=
    Setzt bei der Verwendung mit halt, poweroff oder reboot eine kurze Nachricht, die
    den Grund für die Aktion beschreibt. Die Nachricht wird zusammen mit der
    Standard-Herunterfahrnachricht protokolliert.

--now
    Startet bei der Verwendung mit enable die Units auch. 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=
    Verwendet beim Einsatz mit enable/disable/is-enabled (und verwandten Befehlen) die
    angegebenen 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
    Führt bei der Verwendung mit enable, disable, edit (und verwandten Befehlen)
    Änderungen nur temporär durch, 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«. Steuert bei der
    Verwendung mit den Befehlen preset oder preset-all, 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. Für die Auswahlmöglichkeiten siehe journalctl(1). 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.

--reboot-argument=
    Dieser Schalter wird mit reboot verwandt. 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.

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

--timestamp=
    Ändert das Format der ausgegebenen Zeitstempel. Die folgenden Werte können verwandt
    werden:

    pretty (dies ist die Vorgabe)
        "Tag YYYY-MM-DD HH:MM:SS TZ"

    us, µs
        "Tag YYYY-MM-DD HH:MM:SS.UUUUUU TZ"

    utc
        "Tag YYYY-MM-DD HH:MM:SS UTC"

    us+utc, µs+utc
        "Tag YYYY-MM-DD HH:MM:SS.UUUUUU UTC"

--mkdir
    Wird dies mit bind verwandt, dann wird die Zieldatei oder das Zielverzeichnis
    erstellt, bevor die Bind-Einhängung angewandt wird. Beachten Sie, dass der Name
    dieser Option zwar anzeigt, dass sie nur für Verzeichnisse geeignet ist, sie aber
    auch den Zieldateiknoten, über den eingehängt werden soll, falls das einzuhängende
    Objekt kein Verzeichnis, sondern eine reguläre Datei, ein Geräteknoten, ein Socket
    oder ein FIFO ist, erstellt.

--marked
    Nur zusammen mit reload-or-restart erlaubt. Stellt Neustartaufträge für alle Units,
    die die Markierung »needs-restart« tragen und Neulade-Aufträge für Units, die die
    Markierung »needs-reload« tragen, in die Warteschlange. Wenn eine Unit, die zum
    Neuladen markiert ist, kein Neuladen unterstützt, dann wird ein Neustart in die
    Warteschlange eingestellt. Diese Eigenschaften können mittels set-property Marks
    gesetzt werden.

    systemctl wird darauf warten, dass in die Warteschlange eingestellte Aufträge sich
    beenden, außer wenn --no-block verwandt wird.

--read-only
    Erstellt bei der Verwendung mit bind eine nur lesbare Bind-Einhängung.

-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 angegebenen 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. Optional kann diesem ein Benutzername, abgetrennt
    durch ein »@«-Zeichen, als der verbunden werden soll, vorangestellt werden. Falls
    die besondere Zeichenkette ».host« anstelle des Container-Names verwandt wird, wird
    eine Verbindung zu dem lokalen System aufgebaut (das ist nützlich, um sich zu dem
    Benutzerbus eines bestimmten Benutzers zu verbinden: »--user
    --machine=lennart@.host«. Falls die »@«-Syntax nicht verwandt wird, wird die
    Verbindung als Benutzer »root« vorgenommen. Falls die »@«-Syntax verwandt wird, kann
    entweder die linke oder die rechte Seite fortgelassen werden (aber nicht beide). In
    diesem Fall wird der lokale Benutzername und ».host« angenommen.

--no-pager
    Leitet die Ausgabe nicht an ein Textanzeigeprogramm weiter.

--legend=LOGISCH
    Aktiviert oder deaktiviert die Ausgabe der Legende, d.h. der Spaltenüberschriften
    und der Fußzeile mit Hinweisen. Standardmäßig wird die Legende ausgegeben, außer
    dies wurde mit --quiet oder ähnlichem deaktiviert.

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

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

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

Tabelle 3. LSB-Rückgabe-Codes
┌─────┬────────────────────────┬───────────────────────┐
│Wert │ Beschreibung in LSB    │ Verwendung in Systemd │
├─────┼────────────────────────┼───────────────────────┤
│0    │ "Programm läuft oder   │ Unit ist aktiv        │
│     │ Dienst 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 verwandt        │
│     │ /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_LOG_LEVEL
    Die maximale Protokollierstufe ausgesandter Nachrichten (Nachrichten mit einer
    höheren Protokollierstufe, d.h. weniger wichtige, werden unterdrückt). Sie muss (in
    absteigender Reihenfolge) entweder alert, crit, err, warning, notice, info, debug
    oder eine Ganzzahl im Bereich 0…7 sein. Siehe syslog(3) für weitere Informationen.

$SYSTEMD_LOG_COLOR
    Ein logischer Wert. Falls wahr, werden auf das TTY geschriebene Nachrichten gemäß
    ihrer Priorität eingefärbt.

    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
    Ein logischer Wert. Falls wahr, wird den Protokollnachrichten der Konsole ein
    Zeitstempel vorangestellt.

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

$SYSTEMD_LOG_LOCATION
    Ein logischer Wert. Falls wahr, wird den Protokollnachrichten ein Dateinamen und
    eine Zeilenummer in dem Quellcode, aus dem die Nachrichten stammen, vorangestellt.

    Beachten Sie, dass der Protokollierort sowieso oft als Metadaten zu den
    Journal-Einträgen angehängt ist. Die Aufnahme in den Nachrichtentext kann bei der
    Fehlersuche in Programmen dennoch praktisch sein.

$SYSTEMD_LOG_TARGET
    Das Ziel für Protokolliernachrichten. Entweder console (auf das angehängte TTY
    protokollieren), console-prefixed (auf das angehängte TTY protokollieren, aber die
    Protokollierstufe und »Einrichtung« voranstellen, siehe syslog(3)), kmsg (in den
    zirkulären Kernel-Protokollpuffer protokollieren), journal (in das Journal
    protokollieren (journal-or-kmsg (in das Journal protokollieren, falls verfügbar, und
    andernfalls nach Kmsg), auto (das geeignete Protokollierziel automatisch ermitteln,
    die Vorgabe) oder null (die Protokollierung deaktivieren).

$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 das Textanzeigeprogramm an, sich sofort beim Druck von Strg-C
        zu beenden. Um less die Handhabung von Strg-C selbst zum Umschalten auf die
        Eingabeaufforderung zu erlauben, setzen Sie diese Option 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 das Textanzeigeprogramm 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 Textanzeigeprogramms sichtbar bleibt. Allerdings stehen dadurch
        einige Funktionen des Textanzeigeprogramms nicht zur Verfügung; insbesondere ist
        das Scrollen in der Ausgabe mit der Maus nicht möglich.

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

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

$SYSTEMD_PAGERSECURE
    Akzeptiert einen logischen Wert. Wenn wahr, wird der »sichere« Modus des
    Seitenanzeigeprogramms verwandt, falls falsch, wird dieser deaktiviert. Falls
    $SYSTEMD_PAGERSECURE überhaupt nicht gesetzt ist, dann wird der sichere Modus
    aktiviert, falls die effektive Kennung nicht identisch zu dem Eigentümer der
    Anmeldesitzung ist, siehe geteuid(2) und sd_pid_get_owner_uid(3). Im sicheren Modus
    wird LESSSECURE=1 beim Aufruf des Seitenanzeigeprogramms gesetzt und das
    Seitenanzeigeprogramm muss Befehle deaktivieren, die neue Dateien öffnen oder
    erstellen oder die einen neuen Unterprozess starten. Falls $SYSTEMD_PAGERSECURE
    überhaupt nicht gesetzt ist, werden Seitenanzeigeprogramme, bei denen unbekannt ist,
    ob sie einen sicheren Modus implementieren, nicht verwandt. (Derzeit implementiert
    nur less(1) einen sicheren Modus.)

    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 Seitenanzeigeprogramm 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 den Seitenanzeiger komplett mit --no-pager zu
    deaktivieren.

$SYSTEMD_COLORS
    Akzeptiert ein logisches Argument. Wenn wahr, werden systemd und verwandte
    Hilfswerkzeuge Farben in ihrer Ausgabe verwenden, andernfalls wird die Ausgabe
    einfarbig sein. Zusätzlich kann die Variable eine der folgenden besonderen Werte
    annehmen: »16«, »256«, um die Verwendung von Farbe auf die grundlegenden 16 bzw. 256
    ANSI-Farben zu beschränken. Dies kann festgelegt werden, um die auf $TERM und der
    vorliegenden Verbindung der Konsole basierende automatische Entscheidung außer Kraft
    zu setzen.

$SYSTEMD_URLIFY
    Dies muss ein logischer Wert sein. Er steuert, ob anklickbare Links für
    Terminal-Emulatoren, die dies unterstützen, erstellt werden sollen. Dies kann
    angegeben werden, um die Entscheidung, die systemd basierend auf $TERM und anderen
    Bedingungen trifft, außer Kraft zu setzen.

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. 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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copy‐
right-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 ⟨debian-l10n-german@lists.debian.org⟩.

systemd 250 SYSTEMCTL(1)

Abgerufen von „https://wiki.foxtom.de/index.php?title=Systemctl&oldid=36816“