SYSTEMCTL(1)

BEZEICHNUNG
systemctl - Steuerung des Systemd-Systems und des Service-Managers

ÜBERSICHT

systemctl [OPTIONEN…] BEFEHL [UNIT…]

BESCHREIBUNG

systemctl kann zum Prüfen und Steuern des Zustandes des »Systemd«-Systems und -Diensteverwalters verwandt werden. Bitte lesen Sie systemd(1) für eine Einführung in die grundlegenden Konzepte und Funktionalitäten, die dieses Werkezeug verwaltet.

OPTIONEN

Die folgenden Optionen werden verstanden:

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

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

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

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

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

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

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

    Eigenschaften für Units unterscheiden sich zwischen Unit-Typen, daher ist die Anzeige einer Unit (selbst einer nicht vorhandenen) ein Weg, um die Eigenschaften, die diese Unit betreffen, aufzulisten. Ähnlich wird die Anzeige eines Auftrags die allen Aufträgen zugehörigen Eigenschaften auflisten. Eigenschaften für Units sind in systemd.unit(5) und den Seiten für die individuellen Unit-Typen systemd.service(5), systemd.socket(5) usw. dokumentiert.

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

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

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

-r, --recursive
    Beim Auflisten von Units werden auch Units von lokalen Containern angezeigt. Units von lokalen Containern wird der Container-Name vorangestellt, getrennt durch ein einzelnen Doppelpunkt (»:«).

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

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

    Beachten Sie, dass jede Abhängigkeit After= automatisch gespiegelt wird, um eine Abhängigkeit Before= zu erstellen. Temporäre Abhängigkeiten können explizit festgelegt werden, werden aber auch implizit für Units mit den Zielen WantedBy= (siehe systemd.target(5)) und als Ergebnis von anderen Direktiven (beispielsweise RequiresMountsFor=) erstellt. Sowohl explizit als auch implizit eingeführte Abhängigkeiten werden mit list-dependencies angezeigt.

    Bei der Übergabe an den Befehl list-jobs wird für jeden dargestellten Auftrag angezeigt, welche anderen Aufträge auf ihn warten. Kann mit --before kombiniert werden, um sowohl die Aufträge, die auf jeden Auftrag warten, als auch alle Aufträge auf die jeder Auftrag wartet anzuzeigen.

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

    Bei der Übergabe an den Befehl list-jobs wird für jeden dargestellten Auftrag angezeigt, auf welche anderen Aufträge er wartet. Kann mit --after kombiniert werden, um sowohl die Aufträge, die auf jeden Auftrag warten, als auch alle Aufträge auf die jeder Auftrag wartet anzuzeigen.

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

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

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

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

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

    Falls »fail« festgelegt ist und die angeforderte Aktion in Konflikt mit einem anhängigen Auftrag steht (genauer: dazu führt, dass ein anhängiger Auftrag in einen Stopp-Auftrag oder umgedreht aufgehoben wird), wird die Aktion fehlschlagen.

    Falls (die Vorgabe) »replace« festgelegt ist, wird jeder in Konflikt stehender anhängiger Auftrag falls notwendig ersetzt.

    Falls »replace-irreversibly« festgelegt ist, wird wie bei »replace« agiert, aber die neuen Aufträge als unumkehrbar markiert. Dies hindert zukünftige in Konflikt stehende Transaktionen daran, diese Aufträge zu ersetzen (oder sie selbst daran, in die Warteschlange aufgenommen zu werden, während die irreveresiblen Aufträge noch anhängig sind). Irreversible Aufträge können weiterhin mit dem Befehl cancel abgebrochen werden. Dieser Auftragmodus sollte bei jeder Transaktion, die shutdown.target hereinzieht, verwandt werden.

    »isolate« ist nur für Startaktionen gültig und führt dazu, dass alle anderen Units beendet werden, wenn die festgelegte Unit gestartet wird. Dieser Modus wird immer verwandt, wenn der Befehl isolate verwandt wird.

    »flush« führt dazu, dass alle Aufträge in der Warteschlange abgebrochen werden, wenn der neue Auftrag in die Warteschlange eingestellt wird.

    Falls »ignore-dependencies« festgelegt ist, werden alle Unit-Abhängigkeiten für diesen neuen Auftrag ignoriert und die Aktion wird sofort ausgeführt. Falls übergeben, werden keine für die Unit benötigten Units hereingezogen und keine Ordnungsabhängigkeiten berücksichtigt. Dies dient hauptsächlich der Fehlersuche und als Rettungswerkzeug für den Administrator und sollte von Anwendungen nicht verwandt werden.

    »ignore-requirements« ist ähnlich zu »ignore-dependencies«, führt aber nur dazu, dass die Voraussetzungsabhängigkeiten ignoriert werden, die Ordnungsabhängigkeiten werden weiterhin respektiert.

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

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

-i, --ignore-inhibitors
    Unterdrückungssperren ignorieren, wenn das Herunterfahren oder der Schlafzustand erbeten wurde. Anwendungen können Unterdrückungssperren einrichten, um zu vermeiden, dass bestimmte wichtige Aktionen (wie das Brennen von CDs oder ähnlichem) durch das Herunterfahren des Systems oder Schlafzustände unterbrochen werden. Jeder Benutzer kann diese Sperren erlangen und privilegierte Benutzer dürfen diese Sperren außer Kraft setzen. Falls irgendwelche Sperren erlangt wurden, werden Anfragen zum Herunterfahren oder für Schlafzustände normalerweise fehlschlagen (unabhängig davon, ob sie privilegiert waren oder nicht) und eine Liste der aktiven Sperren wird ausgegeben. Falls allerdings --ignore-inhibitors festgelegt wurde, werden diese Sperren ignoriert und nicht ausgegeben und die Aktion wird dennoch versucht, wobei möglicherweise zusätzliche Privilegien benötigt werden.

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

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

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

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

--user
    Spricht zu dem Dienste-Manager des aufrufenden Benutzers statt zu dem Dienste-Manager des Systems.

--system
    Spricht zum Dienste-Manager des Systems. Dies ist die implizite Vorgabe.

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

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

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

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

--no-ask-password
    Bei der Verwendung mit start und verwandten Befehlen deaktiviert es Fragen nach Passwörtern. Hintergrunddienste können die Eingabe von Passworten oder Passphrasenzeichenketten benötigten, beispielsweise um Systemfestplatten oder kryptographische Zertifikate zu entsperren. Außer wenn diese Option festgelegt ist und der Befehl von einem Terminal aus ausgeführt wird, wird systemctl den Benutzer auf dem Terminal nach den notwendigen Geheimnissen fragen. Verwenden Sie diesen Schalter, um das Verhalten abzuschalten. In diesem Fall muss das Password ü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, wessen Prozesse 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 null oder einem Hauptprozess(en), null oder einem Steuerprozess(n) sowie eine beliebige Anzahl von zusätzlichen Prozessen. Allerdings verwalten nicht alle Unit-Typen Prozesse dieser Typen. Für Einhänge-Units sind beispielsweise Steuerprozesse definiert (die die Aufrufe von /bin/mount und /bin/umount sind), aber es ist kein Hauptprozess definiert. Falls weggelassen ist die Vorgabe all.

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

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

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

    Bei der Verwendung mit halt, poweroff, reboot oder kexec werden die ausgewählten Aktionen ohne Herunterfahren aller Units ausgeführt. Allerdings werden alle Prozesse zwangsweise beendet und alle Dateisysteme ausgehängt oder neu nur lesbar wieder eingehängt. Dies ist daher eine drastische, aber relativ sichere Option, um einen sofortigen Neustart anzufragen. Falls --force zweimal für diese Aktionen festgelegt ist (mit der Ausnahme von kexec)) werden sie sofort ausgeführt, ohne alle Prozesse zu beenden oder Dateisysteme auszuhängen. Warnung: Die zweifache Angabe von --force mit jeden dieser Aktionen kann zu Datenverlust führen. Beachten Sie, dass bei zweifacher Festlegung von --force die ausgewählte Aktion von systemctl selbst ausgeführt wird und kein Kontakt zum Systemverwalter aufgenommen wird. Dies bedeutet, dass dieser Befehl erfolgreich sein sollte, selbst wenn der Systemverwalter abgestürzt ist.

--message=
    Bei der Verwendung mit halt, poweroff oder reboot wird eine kurze Nachricht, die den Grund für die Aktion beschreibt, gesetzt. Die Nachricht wird zusammen mit der Standard-Herunterfahrnachricht protokolliert.

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

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

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

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

--preset-mode=
    Akzeptiert »full« (die Vorgabe), »enable-only« oder »disable-only«. Bei der Verwendung mit den Befehlen preset oder preset-all wird gesteuert, ob Units entsprechend der Voreinstellungsregeln deaktiviert oder aktiviert oder nur aktiviert oder nur deaktiviert 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. Standardmäßig 10.

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

--firmware-setup
    Zeigt der Firmware des Systems bei der Verwendung mit dem Befehl reboot an, dass in den Einrichtungsmodus gestartet werden soll. Beachten Sie, dass dies derzeit nur auf einigen EFI-Systemen und nur, falls das System in den EFI-Modus gestartet wurde, unterstützt wird.

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

-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 Container-Name angehängt werden, getrennt durch »:«, womit direkt zu einem bestimmten Container auf dem angegebenen Rechner verbunden wird. Dies verwendet SSH, um mit der Maschinen-Manager-Instanz auf dem Rechner in der Ferne zu sprechen. Container-Namen dürfen mit machinectl -H RECHNER aufgezählt werden.

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

--no-pager
    Die Ausgabe nicht an einen Pager weiterleiten.

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

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

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

BEFEHLE

Die folgenden Befehle werden verstanden:

  Unit-Befehle

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

    Produziert eine Ausgabe ähnlich zu

          UNIT                         LOAD   ACTIVE SUB     DESCRIPTION
          sys-module-fuse.device       loaded active plugged /sys/module/fuse
          -.mount                      loaded active mounted Root Mount
          boot-efi.mount               loaded active mounted /boot/efi
          systemd-journald.service     loaded active running Journal Service
          systemd-logind.service       loaded active running Login Service
        â user@1000.service            loaded active running User Manager for UID 1000
        ...
          systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories
        LOAD   = Reflects whether the unit definition was properly loaded.
        ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
        SUB    = The low-level unit activation state, values depend on unit type.
        123 loaded units listed. Pass --all to see loaded but inactive units, too.
        To show all installed unit files use 'systemctl list-unit-files'.

    Die Kopfzeilen und die letzte Unit des angegebenen Typs werden unterstrichen, falls das Terminal dies unterstützt. Ein farbiger Punkt wird neben den Diensten, die maskiert, nicht gefunden oder sonstwie fehlgeschlagen sind, angezeigt.

    Die Spalte LOAD zeigt den Ladezustand, einen aus loaded, not-found, bad-setting, error, masked. Die Spalte ACTIVE zeigt den allgemeinen Unit-Zustand, einen aus active, reloading, inactive, failed, activating, deactivating. Die Spalte SUB zeigt den Unit-Typ-spezifischen detaillierten Zustand der Unit, mögliche Werte hängen vom Unit-Typ ab. Die Liste der möglichen LOAD-, ACTIVE- und SUB-Zustände ist nicht konstant und neue Systemd-Veröffentlichungen können sowohl Werte hinzufügen als auch welche entfernen.

        systemctl --state=help

    Der Befehl kann zur Anzeige der aktuell möglichen Menge von Werten verwandt werden.

    Dies ist der Standardbefehl.

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

        LISTEN           UNIT                        ACTIVATES
        /dev/initctl     systemd-initctl.socket      systemd-initctl.service
        ...
        [::]:22          sshd.socket                 sshd.service
        kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
        5 sockets listed.

    Beachten Sie: Da die Adressen Leerraum 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 festgelegt sind, werden nur Units, die darauf passen, angezeigt. Produziert Ausgabe ähnlich zu

        NEXT                         LEFT          LAST                         PASSED     UNIT                         ACTIVATES
        n/a                          n/a           Thu 2017-02-23 13:40:29 EST  3 days ago ureadahead-stop.timer        ureadahead-stop.service
        Sun 2017-02-26 18:55:42 EST  1min 14s left Thu 2017-02-23 13:54:44 EST  3 days ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
        Sun 2017-02-26 20:37:16 EST  1h 42min left Sun 2017-02-26 11:56:36 EST  6h ago     apt-daily.timer              apt-daily.service
        Sun 2017-02-26 20:57:49 EST  2h 3min left  Sun 2017-02-26 11:56:36 EST  6h ago     snapd.refresh.timer          snapd.refresh.service

    NEXT zeigt die nächste Zeit, zu der der 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 letzmalig lief.

    UNIT zeigt den Namen des Timers

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

    Siehe auch --all und --state=.

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

    Beachten Sie, dass Glob-Muster auf der Menge der Primärnamen von Units, die momentan im Arbeitsspeicher sind, agieren. Units, die nicht aktiv und nicht in einem Fehlzustand sind, sind normalerweise nicht im Speicher und es wird kein Muster auf sie passen. Bei instanziierten Units ist Systemd zusätzlich oft in Unkenntnis über den Instanzennamen, bis die Instanz gestartet wurde. Daher hat die Verwendung von Glob-Mustern mit start nur begrenzten Nutzen. Auch werden sekundäre Alias-Namen von Units nicht berücksichtigt.

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

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 rausschreibt, bevor sie neu gestartet wird. Beispielsweise wird die Dienste-bezogene Dateideskriptorspeichereinrichtung (siehe FileDescriptoreStoreMax= in systemd.service(5)) intakt bleiben, solange ein Auftrag in der Unit wartet und wird nur bereinigt, wenn die Unit komplett gestoppt wird und keine Aufträge mehr warten. Falls gewünscht ist, dass der Dateideskriptorspeicher auch rausgeschrieben wird, dann sollte während der Neustartaktion ein expliziter Befehl systemctl stop gefolgt von systemctl start eingegeben werden.

try-restart MUSTER…
    Stoppt und startet eine oder mehrere auf der Befehlszeile festgelegte Units, falls die Units laufen. Dies macht nichts, 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 macht nichts, falls die Units nicht laufen.

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

    Dies ist ähnlich zu der Änderung von Runleveln in traditionellen Init-Systemen. Der Befehl isolate wird sofort Prozesse stoppen, die in der neuen Unit nicht aktiviert 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.

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

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

status [MUSTER…|PID…]]
    Zeigt knappe Laufzeitstatusinformationen über eine oder mehrere Units, gefolgt von den neusten Protokolldaten aus dem Journal. Falls keine Units festgelegt sind, wird der Systemstatus angezeigt. In Kombination mit --all wird auch der Status aller Units angezeigt (in Abhängigkeit von den mit -t festgelegten Einschränkungen). Falls ein 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.

    Sytemd lädt Units implizit nach Notwendigkeit, daher wird die reine Ausführung von status versuchen, eine Datei zu laden. Der Befehl ist daher nicht nützlich, um zu bestimmen, ob etwas bereits geladen war oder nicht. Die Units könnten sich auch schnell entladen, nachdem die Aktion abgeschlossen ist, falls es keinen Grund gibt, sie danach im Speicher zu halten.

    Beispiel 1. Beispielausgabe von systemctl status

        $ systemctl status bluetooth
        â bluetooth.service - Bluetooth service
           Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
           Active: active (running) since Wed 2017-01-04 13:54:04 EST; 1 weeks 0 days ago
             Docs: man:bluetoothd(8)
         Main PID: 930 (bluetoothd)
           Status: "Running"
            Tasks: 1
           Memory: 648.0K
              CPU: 435ms
           CGroup: /system.slice/bluetooth.service
                   ââ930 /usr/lib/bluetooth/bluetoothd
        Jan 12 10:46:45 example.com bluetoothd[8900]: Not enough free handles to register service
        Jan 12 10:46:45 example.com bluetoothd[8900]: Current Time Service could not be registered
        Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output error (5)

    Der Punkt (»â«) verwendet auf unterstützten Terminals Farbe, um den Unit-Zustand auf einen Blick zusammenzufassen. Weiß zeigt den Zustand »inactive« oder »deactivating« an. Rot zeigt einen Zustand »failed« oder »error« und grün zeigt einen Zustand »active«, »reloading« oder »activating« an.

    Die Zeile »Loaded:« in der Ausgabe wird »loaded« anzeigen, falls die Unit in den Speicher geladen wurde. Andere mögliche Werte für »Loaded:« sind u.A.: »error«, falls es ein Problem beim Laden gab, »not-found«, falls für diese Unit keine Unit-Datei gefunden wurde, »bad-setting«, falls eine essenzielle Unit-Datei-Einstellung nicht ausgewertet werden konnte und »masked«, falls die Unit-Datei maskiert wurde. Zusammen mit dem Pfad zu der Unit-Datei wird diese Zeile auch den Aktivierungszustand anzeigen. Aktivierte Befehle starten beim Systemstart. Lesen Sie die vollständige Tabelle der möglichen Aktivierungszustä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« berichten. Ein besonderer Zustand »failed« wird erreicht, wenn der Zustand auf irgendeine Art, z.B. durch einen Absturz, der Beendigung mit einem Fehler-Code oder einer Zeitüberschreitung, fehlgeschlagen ist. Falls ein Fehlerzustand erreicht wurde, wird der Grund protokolliert.

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

    Viele durch systemctl show gezeigte Eigenschaften können direkt auf Konfigurationseigenschaften des System- und Diensteverwalters und seiner Unit-Dateien abgebildet werden. Beachten Sie, dass die durch den Befehl angezeigten Eigenschaften im Allgemeinen systemnahe, normalisierte Versionen der ursprünglichen Konfigurationseinstellungen sind und zusätzlich zur Konfiguration Laufzeitzustand offenlegen. Eigenschaften für Dienste-Units enthalten beispielsweise die Kennzeichnung des aktuellen Hauptprozesses des Dienstes als »MainPID« (was Laufzeitzustand ist) und die Zeiteinstellungen werden immer als Eigenschaften, die in »…Sec« enden, offengelegt, da Mikrosekunden die vom System- und Diensteverwalter verwandte normierte Zeiteinheit sind.

cat MUSTER…
    Show backing files of one or more units. Prints the "fragment" and "drop-ins" (source files) of units. Each file is preceded by a comment which includes the file name. Note that this shows the contents of the backing files on disk, which may not match the system manager's understanding of these units if any unit files were updated on disk and the daemon-reload command wasn't issued since.

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

    Beispiel: systemctl set-property foobar.service CPUShares=777

    Falls die festgelegte Unit-Datei inaktiv zu sein scheint, werden die Änderungen nur wie früher beschrieben auf Platte gespeichert, daher werden sie erst beim Starten der Unit zur Geltung kommen.

    Beachten Sie, dass dieser Befehl das Ändern mehrerer Eigenschaften auf einmal erlaubt, was gegenüber der individuellen Einstellung bevorzugt werden sollte. Ähnlich zu Unit-Dateikonfigurationseinstellungen wird die Zuweisung der leeren Liste die Eigenschaft zurücksetzen.

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

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

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

    Standardmäßig werden nur Ziel-Units rekursiv expandiert. Wenn --all übergeben wird, werden auch alle anderen Units rekursiv expandiert.

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

  Unit-Dateibefehle

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

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

    Dieser Befehl erwartet entweder gültige Unit-Namen (in diesem Fall werden verschiedene Unit-Datei-Verzeichnisse automatisch nach Unit-Dateien mit geeigneten Namen durchsucht) oder absolute Pfade zu Unit-Dateien (in diesem Fall werden die Dateien direkt eingelesen). Falls eine festgelegte Unit-Datei sich außerhalb der gewöhnlichen Unit-Dateiverzeichnisse befindet, wird ein zusätzlicher Symlink erstellt, der sie in den Unit-Konfigurationspfad verlinkt, und daher sicherstellt, dass sie durch Befehle wie start gefunden wird. Das Dateisystem, in dem sich die verlinkten Unit-Dateien befinden, muss verfügbar sein, wenn Systemd gestartet wird (z.B. ist alles unterhalb von /var nicht erlaubt, außer diese Verzeichnisse befinden sich auf dem Wurzeldateisystem).

    Dieser Befehl wird die ausgeführten Dateisystemaktionen ausgeben. Diese Ausgabe kann durch Übergabe von --quiet unterdrückt werden.

    Beachten Sie, dass diese Aktion nur die in dem Abschnitt »[Install]« der Unit-Dateien vorgeschlagenen Symlinks erstellt. Obwohl dieser Befehl die empfohlene Art ist, das Unit-Konfigurationsverzeichnis zu bearbeiten, ist der Administrator frei, manuell zusätzliche Änderungen vorzunehmen, indem er in diesem Verzeichnis Symlinks anlegt oder entfernt. Dies ist besonders nützlich, um Konfigurationen zu erstellen, die von den vorgeschlagenen Standardinstallationen abweichen. In diesem Falle muss der Administrator sicherstellen, daemon-reload wo notwendig aufzurufen, um sicherzustellen, dass die Änderungen berücksichtigt werden.

    Freigeben von Units sollte nicht mit dem Starten (Aktivieren) verwechselt werden, wie dies durch den Befehl start erfolgt. Freigeben und starten von Units ist orthogonal: Units können freigegeben sein, ohne gestartet zu sein und gestartet ohne freigegeben zu sein. Die Freigabe hängt die Unit an verschiedenen vorgeschlagenen Stellen ein (beispielsweise so, dss die Unit automatisch beim Systemstart gestartet wird oder wenn ein bestimmte Art von Hardware eingesteckt wird). Starten führt den Daemon-Prozess tatsächlich aus (im Falle von Dienste-Units) oder bindet das Socket (im Falle von Socket-Units) und so weiter.

    Abhängig davon ob --system, --user, --runtime oder --global festgelegt wurde, gibt dies die Unit für das System, nur den aufrufenden Benutzer, nur für diesen Systemstart oder für alle zukünftigen Anmeldungen aller Benutzer frei. Beachten Sie, dass in letzterem Fall keine Systemd-Daemonkonfiguration neu geladen wird.

    Die Verwendung von enable auf maskierten Units wird nicht unterstützt und führt zu einem Fehler.

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

    Dieser Befehl erwartet nur gültige Unit-Namen, er akzeptiert keine Pfade zu Unit-Dateien.

    Zusätzlich zu den als Argument angegebenen Unit-Dateien werden alle Units ausgeschaltet, die in der in Abschnitt »[Install]« aufgeführten Einstellung Also= in jeder der Unit-Dateien, auf die agiert wird, enthalten sind.

    Dieser Befehl lädt implizit die Systemverwalterkonfiguration nach Abschluss der Aktion neu. Beachten Sie, dass dieser Befehl die ausgeschalteten Units nicht implizit stoppt. Falls dies gewünscht ist, kombinieren Sie diesen Befehl entweder mit dem Schalter --now oder rufen Sie den Befehl stop mit geeigneten Argumenten später auf.

    Dieser Befehl wird Informationen über die ausgeführten Dateisystemaktionen (Entfernung der Symlinks) ausgeben. Durch Übergabe von --quiet kann diese Ausgabe unterdrückt werden.

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

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

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

    Use --preset-mode= to control whether units shall be enabled and disabled, or only enabled, or only disabled.

    If the unit carries no install information, it will be silently ignored by this command. UNIT must be the real unit name, any alias names are ignored silently.

    For more information on the preset policy format, see systemd.preset(5). For more information on the concept of presets, please consult the Preset[1] document.

preset-all
    Resets all installed unit files to the defaults configured in the preset policy file (see above).

    Use --preset-mode= to control whether units shall be enabled and disabled, or only enabled, or only disabled.

is-enabled UNIT…
    Checks whether any of the specified unit files are enabled (as with enable). Returns an exit code of 0 if at least one is enabled, non-zero otherwise. Prints the current enable status (see table). To suppress this output, use --quiet. To show installation targets, use --full.

    Tabelle 1. Ausgabe von is-enabled
    Name | Beschreibung | Exit-Code
    "enabled" | Aktiviert über .wants/, .requires/ oder Alias=-Symlinks (permanent in /etc/systemd/system/ oder flüchtig in /run/systemd/system/). | 0
    "enabled-runtime" |  |
    "linked" | Made available through one or more symlinks to the unit file (permanently in /etc/systemd/system/ or transiently in /run/systemd/system/), even though the unit file might reside outside of the unit file search path. | > 0
    "linked-runtime" |  |
    "masked" | Completely disabled, so that any start operation on it fails (permanently in /etc/systemd/system/ or transiently in /run/systemd/systemd/). | > 0
    "masked-runtime" |  |
    "static" | The unit file is not enabled, and has no provisions for enabling in the "[Install]" unit file section. | 0
    "indirect" | The unit file itself is not enabled, but it has a non-empty Also= setting in the "[Install]" unit file section, listing other unit files that might be enabled, or it has an alias under a different name through a symlink that is not specified in Also=. For template unit file, an instance different than the one specified in DefaultInstance= is enabled. | 0
    "disabled" | The unit file is not enabled, but contains an "[Install]" section with installation instructions. | > 0
    "generated" | The unit file was generated dynamically via a generator tool. See systemd.generator(7). Generated unit files may not be enabled, they are enabled implicitly by their generator. | 0
    "transient" | The unit file has been created dynamically with the runtime API. Transient units may not be enabled. | 0
    "bad" | The unit file is invalid or another error occurred. Note that is-enabled will not actually return this state, but print an error message instead. However the unit file listing printed by list-unit-files might show it. | > 0

mask UNIT…
    Mask one or more units, as specified on the command line. This will link these unit files to /dev/null, making it impossible to start them. This is a stronger version of disable, since it prohibits all kinds of activation of the unit, including enablement and manual activation. Use this option with care. This honors the --runtime option to only mask temporarily until the next reboot of the system. The --now option may be used to ensure that the units are also stopped. This command expects valid unit names only, it does not accept unit file paths.

unmask UNIT…
    Unmask one or more unit files, as specified on the command line. This will undo the effect of mask. This command expects valid unit names only, it does not accept unit file paths.

link PFAD…
    Link a unit file that is not in the unit file search paths into the unit file search path. This command expects an absolute path to a unit file. The effect of this may be undone with disable. The effect of this command is that a unit file is made available for commands such as start, even though it is not installed directly in the unit search path. The file system where the linked unit files are located must be accessible when systemd is started (e.g. anything underneath /home or /var is not allowed, unless those directories are located on the root file system).

revert UNIT…
    Revert one or more unit files to their vendor versions. This command removes drop-in configuration files that modify the specified units, as well as any user-configured unit file that overrides a matching vendor supplied unit file. Specifically, for a unit "foo.service" the matching directories "foo.service.d/" with all their contained files are removed, both below the persistent and runtime configuration directories (i.e. below /etc/systemd/system and /run/systemd/system); if the unit file has a vendor-supplied version (i.e. a unit file located below /usr) any matching persistent or runtime unit file that overrides it is removed, too. Note that if a unit file has no vendor-supplied version (i.e. is only defined below /etc/systemd/system or /run/systemd/system, but not in a unit file stored below /usr), then it is not removed. Also, if a unit is masked, it is unmasked.

    Effectively, this command may be used to undo all changes made with systemctl edit, systemctl set-property and systemctl mask and puts the original unit file with its settings back in effect.

add-wants ZIEL UNIT…, add-requires ZIELUNIT…
    Adds "Wants=" or "Requires=" dependencies, respectively, to the specified TARGET for one or more units.

    This command honors --system, --user, --runtime and --global in a way similar to enable.

edit UNIT…
    Edit a drop-in snippet or a whole replacement file if --full is specified, to extend or override the specified unit.

    Depending on whether --system (the default), --user, or --global is specified, this command creates a drop-in file for each unit either for the system, for the calling user, or for all futures logins of all users. Then, the editor (see the "Environment" section below) is invoked on temporary files which will be written to the real location if the editor exits successfully.

    If --full is specified, this will copy the original units instead of creating drop-in files.

    If --force is specified and any units do not already exist, new unit files will be opened for editing.

    If --runtime is specified, the changes will be made temporarily in /run and they will be lost on the next reboot.

    If the temporary file is empty upon exit, the modification of the related unit is canceled.

    After the units have been edited, systemd configuration is reloaded (in a way that is equivalent to daemon-reload).

    Note that this command cannot be used to remotely edit units and that you cannot temporarily edit units which are in /etc, since they take precedence over /run.

get-default
    Return the default target to boot into. This returns the target unit name default.target is aliased (symlinked) to.

set-default ZIEL
    Set the default target to boot into. This sets (symlinks) the default.target alias to the given target unit.

  Maschinenbefehle

list-machines [MUSTER…]
    List the host and all running local containers with their state. If one or more PATTERNs are specified, only containers matching one of them are shown.

  Job Commands

list-jobs [MUSTER…]
    List jobs that are in progress. If one or more PATTERNs are specified, only jobs for units matching one of them are shown.

    When combined with --after or --before the list is augmented with information on which other job each job is waiting for, and which other jobs are waiting for it, see above.

cancel JOB...
    Cancel one or more jobs specified on the command line by their numeric job IDs. If no job ID is specified, cancel all pending jobs.

  Umgebungsbefehle

show-environment
    Dump the systemd manager environment block. This is the environment block that is passed to all processes the manager spawns. The environment block will be dumped in straight-forward form suitable for sourcing into most shells. If no special characters or whitespace is present in the variable values, no escaping is performed, and the assignments have the form "VARIABLE=value". If whitespace or characters which have special meaning to the shell are present, dollar-single-quote escaping is used, and assignments have the form "VARIABLE=$'value'". This syntax is known to be supported by bash(1), zsh(1), ksh(1), and busybox(1)'s ash(1), but not dash(1) or fish(1).

set-environment VARIABLE=WERT…
    Set one or more systemd manager environment variables, as specified on the command line.

unset-environment VARIABLE…
    Unset one or more systemd manager environment variables. If only a variable name is specified, it will be removed regardless of its value. If a variable and a value are specified, the variable is only removed if it has the specified value.

import-environment [VARIABLE…]
    Import all, one or more environment variables set on the client into the systemd manager environment block. If no arguments are passed, the entire environment block is imported. Otherwise, a list of one or more environment variable names should be passed, whose client-side values are then imported into the manager's environment block.

  Manager Lifecycle Commands

daemon-reload
    Reload the systemd manager configuration. This will rerun all generators (see systemd.generator(7)), reload all unit files, and recreate the entire dependency tree. While the daemon is being reloaded, all sockets systemd listens on behalf of user configuration will stay accessible.

    This command should not be confused with the reload command.

daemon-reexec
    Reexecute the systemd manager. This will serialize the manager state, reexecute the process and deserialize the state again. This command is of little use except for debugging and package upgrades. Sometimes, it might be helpful as a heavy-weight daemon-reload. While the daemon is being reexecuted, all sockets systemd listening on behalf of user configuration will stay accessible.

  Systembefehle

is-system-running
    Checks whether the system is operational. This returns success (exit code 0) when the system is fully up and running, specifically not in startup, shutdown or maintenance mode, and with no failed services. Failure is returned otherwise (exit code non-zero). In addition, the current state is printed in a short string to standard output, see the table below. Use --quiet to suppress this output.

    Tabelle 2. Ausgabe von is-system-running
    Name | Beschreibung | Exit-Code
    initializing | Early bootup, before basic.target is reached or the maintenance state entered. | > 0
    starting | Late bootup, before the job queue becomes idle for the first time, or one of the rescue targets are reached. | > 0
    running | The system is fully operational. | 0
    degraded | The system is operational but one or more units failed. | > 0
    maintenance | The rescue or emergency target is active. | > 0
    stopping | The manager is shutting down. | > 0
    offline | The manager is not running. Specifically, this is the operational state if an incompatible program is running as system manager (PID 1). | > 0
    unknown | The operational state could not be determined, due to lack of resources or another error cause. | > 0

default
    Enter default mode. This is equivalent to systemctl isolate default.target. This operation is blocking by default, use --no-block to request asynchronous behavior.

rescue
    Enter rescue mode. This is equivalent to systemctl isolate rescue.target. This operation is blocking by default, use --no-block to request asynchronous behavior.

emergency
    Enter emergency mode. This is equivalent to systemctl isolate emergency.target. This operation is blocking by default, use --no-block to request asynchronous behavior.

halt
    Shut down and halt the system. This is mostly equivalent to systemctl start halt.target --job-mode=replace-irreversibly --no-block, but also prints a wall message to all users. This command is asynchronous; it will return after the halt operation is enqueued, without waiting for it to complete. Note that this operation will simply halt the OS kernel after shutting down, leaving the hardware powered on. Use systemctl poweroff for powering off the system (see below).

    If combined with --force, shutdown of all running services is skipped, however all processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the system halt. If --force is specified twice, the operation is immediately executed without terminating any processes or unmounting any file systems. This may result in data loss. Note that when --force is specified twice the halt operation is executed by systemctl itself, and the system manager is not contacted. This means the command should succeed even when the system manager has crashed.

poweroff
    Shut down and power-off the system. This is mostly equivalent to systemctl start poweroff.target --job-mode=replace-irreversibly --no-block, but also prints a wall message to all users. This command is asynchronous; it will return after the power-off operation is enqueued, without waiting for it to complete.

    If combined with --force, shutdown of all running services is skipped, however all processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the powering off. If --force is specified twice, the operation is immediately executed without terminating any processes or unmounting any file systems. This may result in data loss. Note that when --force is specified twice the power-off operation is executed by systemctl itself, and the system manager is not contacted. This means the command should succeed even when the system manager has crashed.

reboot [Arg]
    Shut down and reboot the system. This is mostly equivalent to systemctl start reboot.target --job-mode=replace-irreversibly --no-block, but also prints a wall message to all users. This command is asynchronous; it will return after the reboot operation is enqueued, without waiting for it to complete.

    If combined with --force, shutdown of all running services is skipped, however all processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the reboot. If --force is specified twice, the operation is immediately executed without terminating any processes or unmounting any file systems. This may result in data loss. Note that when --force is specified twice the reboot operation is executed by systemctl itself, and the system manager is not contacted. This means the command should succeed even when the system manager has crashed.

    If the optional argument arg is given, it will be passed as the optional argument to the reboot(2) system call. The value is architecture and firmware specific. As an example, "recovery" might be used to trigger system recovery, and "fota" might be used to trigger a “firmware over the air” update.

kexec
    Shut down and reboot the system via kexec. This is equivalent to systemctl start kexec.target --job-mode=replace-irreversibly --no-block. This command is asynchronous; it will return after the reboot operation is enqueued, without waiting for it to complete.

    If combined with --force, shutdown of all running services is skipped, however all processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the reboot.

exit [EXIT-CODE]
    Ask the service manager to quit. This is only supported for user service managers (i.e. in conjunction with the --user option) or in containers and is equivalent to poweroff otherwise. This command is asynchronous; it will return after the exit operation is enqueued, without waiting for it to complete.

    The service manager will exit with the specified exit code, if EXIT_CODE is passed.

switch-root WURZEL [INIT]
    Switches to a different root directory and executes a new system manager process below it. This is intended for usage in initial RAM disks ("initrd"), and will transition from the initrd's system manager process (a.k.a. "init" process) to the main system manager process which is loaded from the actual host volume. This call takes two arguments: the directory that is to become the new root directory, and the path to the new system manager binary below it to execute as PID 1. If the latter is omitted or the empty string, a systemd binary will automatically be searched for and used as init. If the system manager path is omitted, equal to the empty string or identical to the path to the systemd binary, the state of the initrd's system manager process is passed to the main system manager, which allows later introspection of the state of the services involved in the initrd boot phase.

suspend
    Suspend the system. This will trigger activation of the special target unit suspend.target. This command is asynchronous, and will return after the suspend operation is successfully enqueued. It will not wait for the suspend/resume cycle to complete.

hibernate
    Hibernate the system. This will trigger activation of the special target unit hibernate.target. This command is asynchronous, and will return after the hibernation operation is successfully enqueued. It will not wait for the hibernate/thaw cycle to complete.

hybrid-sleep
    Hibernate and suspend the system. This will trigger activation of the special target unit hybrid-sleep.target. This command is asynchronous, and will return after the hybrid sleep operation is successfully enqueued. It will not wait for the sleep/wake-up cycle to complete.

  Parametersyntax

Unit commands listed above take either a single unit name (designated as UNIT), or multiple unit specifications (designated as PATTERN...). In the first case, the unit name with or without a suffix must be given. If the suffix is not specified (unit name is "abbreviated"), systemctl will append a suitable suffix, ".service" by default, and a type-specific suffix in case of commands which operate only on specific unit types. For example,

    # systemctl start sshd

und

    # systemctl start sshd.service

sind äquivalent, wie auch

    # systemctl isolate default

und

    # systemctl isolate default.target

Note that (absolute) paths to device nodes are automatically converted to device unit names, and other (absolute) paths to mount unit names.

    # systemctl status /dev/sda
    # systemctl status /home

ist äquivalent zu:

    # systemctl status dev-sda.device
    # systemctl status home.mount

In the second case, shell-style globs will be matched against the primary names of all units currently in memory; literal unit names, with or without a suffix, will be treated as in the first case. This means that literal unit names always refer to exactly one unit, but globs may match zero units and this is not considered an error.

Glob patterns use fnmatch(3), so normal shell-style globbing rules are used, and "*", "?", "[]" may be used. See glob(7) for more details. The patterns are matched against the primary names of units currently in memory, and patterns which do not match anything are silently skipped. For example:

    # systemctl stop sshd@*.service

will stop all sshd@.service instances. Note that alias names of units, and units that aren't in memory are not considered for glob expansion.

For unit file commands, the specified UNIT should be the name of the unit file (possibly abbreviated, see above), or the absolute path to the unit file:

    # systemctl enable foo.service

oder

    # systemctl link /path/to/foo.service

RÜCKGABEWERT

Bei Erfolg wird 0 zurückgegeben, anderenfalls ein Fehlercode ungleich Null.

UMGEBUNGSVARIABLEN

$SYSTEMD_EDITOR
    Editor to use when editing units; overrides $EDITOR and $VISUAL. If neither $SYSTEMD_EDITOR nor $EDITOR nor $VISUAL are present or if it is set to an empty string or if their execution failed, systemctl will try to execute well known editors in this order: editor(1), nano(1), vim(1), vi(1).

$SYSTEMD_PAGER
    Zu verwendender Pager, wenn --no-pager nicht angegeben ist, setzt $PAGER außer Kraft. Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe gut-bekannter Pagerimplementierungen der Reihe nach ausprobiert, einschließlich less(1) und more(1), bis einer gefunden wird. Falls keine Pager-Implementierung gefunden wird, wird keiner aufgerufen. Setzten der Umgebungsvariablen auf die leere Zeichenkette oder den Wert »cat« is äquivalent zur Übergabe von --no-pager.

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

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

SIEHE AUCH

systemd(1), journalctl(1), loginctl(1), machinectl(1), systemd.unit(5), systemd.resource-control(5), systemd.special(7), wall(1), systemd.preset(5), systemd.generator(7), glob(7)

ANMERKUNGEN

1.  Preset
    https://www.freedesktop.org/wiki/Software/systemd/Preset

ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> und FIXME: Global enable → freigeben erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an <debian-l10n-german@lists.debian.org>.