plucky (5) systemd.service.5.gz

Provided by: manpages-de_4.25.1-1_all bug

BEZEICHNUNG

       systemd.service - Dienste-Unit-Konfiguration

ÜBERSICHT

       Dienst.service

BESCHREIBUNG

       Eine Unit-Konfigurationsdatei, deren Name in ».service« endet, kodiert Informationen über einen von
       Systemd gesteuerten und überwachten Prozess.

       Diese Handbuchseite listet die für diesen Unit-Typ spezifischen Konfigurationsoptionen auf. Siehe
       systemd.unit(5) für die gemeinsamen Optionen von allen Unit-Konfigurationsdateien. Die gemeinsamen
       Konfigurationselemente werden in den generischen Abschnitten »[Unit]« und »[Install]« konfiguriert. Die
       dienstespezifischen Konfigurationsoptionen werden im Abschnitt »[Service]« konfiguriert.

       Zusätzliche Optionen sind in systemd.exec(5), das die Ausführungsumgebung, in der die Befehle ausgeführt
       werden und in systemd.kill(5), das die Art der Beendigung der Prozesse des Dienstes definiert und in
       systemd.resource-control(5), das die Ressourcensteuerungseinstellungen für die Prozesse des Dienstes
       konfiguriert, aufgeführt.

       Falls SysV-Init-Kompatibilität aktiviert ist, erstellt Systemd automatisch Dienste-Units, die
       SysV-Init-Skripte einhüllen (der Dienstename ist der gleich wie der Name des Skripts, mit hinzugefügter
       Endung ».service«); siehe systemd-sysv-generator(8).

       Der Befehl erlaubt das dynamische und flüchtige Erstellen von ».service«- und ».scope«-Units auf der
       Befehlszeile.

DIENSTEVORLAGEN

       systemd-Dienste können ein einzelnes Argument über die Syntax »Dienst@Argument.service« akzeptieren.
       Solche Dienste heißen »instanziierte« Dienste, während die Unit-Definition ohne den Parameter Argument
       »Vorlage« genannt wird. Eine Beispiel könnte die Dienstevorlage dhcpcd@.service sein, die eine
       Netzwerkschnittstelle als Parameter akzeptiert, um einen instanziierten Dienst zu formen. Innerhalb
       dieser Dienstedatei kann auf diesen Parameter oder den »Instanzennamen« mit Kennzeichnern »%« zugegriffen
       werden. Siehe systemd.unit(5) für Details.

AUTOMATISCHE ABHÄNGIGKEITEN

   Implizite Abhängigkeiten
       Die folgenden Abhängigkeiten werden implizit hinzugefügt:

       •   Dienste mit Type=dbus erlangen automatisch Abhängigkeiten des Typs Requires= und After= von
           dbus.socket.

       •   Socket-aktivierte Dienste werden automatisch nach ihren aktivierenden .socket-Units mittels einer
           automatischen After=-Abhängigkeit sortiert. Dienste ziehen auch alle in Sockets= aufgeführten
           .socket-Units mittels automatischer Wants=- und After=-Abhängigkeiten herein.

       Zusätzliche implizite Abhängigkeiten als Ergebnis der Ausführung und der gemäß systemd.exec(5) und
       systemd.resource-control(5) dokumentierten Ressourcen-Steuerungsparameter können hinzugefügt werden.

   Standardabhängigkeiten
       Die folgenden Abhängigkeiten werden hinzugefügt, es sei denn, DefaultDependencies=no ist gesetzt:

       •   Dienste-Units werden Abhängigkeiten des Typs Requires= und After= von sysinit.target, eine
           Abhängigkeit des Typs After= on basic.target sowie Abhängigkeiten vom Typ Conflicts= und Before= von
           shutdown.target haben. Dies stellt sicher, dass normale Dienste-Units alle grundlegenden
           Systeminitialisierungen hereinziehen und sauber vor dem Herunterfahren des Systems beendet werden.
           Nur Dienste, die an der frühen Systemstartphase oder beim Herunterfahren des Systems beteiligt sind,
           sollten diese Option deaktivieren.

       •   Instanziierten Dienste-Units (d.h. Dienste-Units mit einem »@« in ihrem Namen) wird standardmäßig
           eine vorlagenbezogene Scheiben-Unit zugewiesen (siehe systemd.slice(5)), die nach der Vorlagen-Unit
           benannt wird und alle Instanzen der festgelegten Vorlage enthält. Diese Scheibe wird normalerweise
           beim Herunterfahren zusammen mit allen Vorlageninstanzen gestoppt. Falls dies nicht gewünscht ist,
           setzen Sie DefaultDependencies=no in der Vorlagen-Unit und definieren entweder Ihre eigene,
           vorlagenbezogene Scheiben-Unit-Datei, die auch DefaultDependencies=no setzt oder setzen
           Slice=system.slice (oder eine andere geeignete Scheibe) in der Vorlagen-Unit. Siehe auch
           systemd.resource-control(5).

OPTIONEN

       Dienste-Unit-Dateien können Abschnitte [Unit] und [Install] enthalten, die in systemd.unit(5) beschrieben
       sind.

       Dienste-Unit-Dateien müssen einen Abschnitt »[Service]« enthalten, der Informationen über den Dienst und
       den Prozess, den er überwacht, zusammenträgt. Eine Reihe von Optionen, die in diesem Abschnitt genutzt
       werden können, werden mit anderen Unit-Typen gemeinsam benutzt. Diese Optionen sind in systemd.exec(5),
       systemd.kill(5) und systemd.resource-control(5) beschrieben. Die für den Abschnitt »[Service]« von
       Dienste-Units spezifischen Optionen sind:

       Type=
           Konfiguriert den Mechanismus, über den der Dienst den Verwalter informiert, dass der Startvorgang des
           Dienstes abgeschlossen ist. Einer aus simple, exec, forking, oneshot, dbus, notify, notify-reload
           oder idle:

           •   Falls auf simple gesetzt ist (die Vorgabe, falls ExecStart= angegeben ist, aber weder Type= noch
               BusName= gesetzt sind und keine Zugangsberechtigungen verwandt werden), wird der Diensteverwalter
               die Unit als gestartet betrachten, sobald der Hauptdiensteprozess mittels »fork« erzeugt wurde
               (d.h. direkt nach fork() und bevor verschiedene Prozessarttribute konfiguriert wurden und
               insbesondere bevor der neue Prozess execve() aufgerufen hat, um das eigentliche Diensteprogramm
               zu starten). Typischerweise ist Type=exec die bessere Wahl, siehe unten.

               Es wird erwartet, dass der mit ExecStart= konfigurierte Prozess der Hauptprozess des Dienstes
               ist. In diesem Modus sollte der Kommunikationskanal vor dem Starten des Dienstes installiert sein
               (d.h. die Sockets von Systemd mittels Socket-Aktivierung eingerichtet sein), da der
               Diensteverwalter sofort mit dem Starten von nachfolgenden Units beginnt, direkt nachdem der
               Hauptdiensteprozess erstellt und bevor das Programm des Dienstes ausgeführt wurde. Beachten Sie,
               dass dies bedeutet, dass Befehlszeilen systemctl start für simple-Dienste Erfolg melden werden,
               selbst wenn das Programm des Dienstes nicht erfolgreich aufgerufen werden kann (beispielsweise
               weil der ausgewählte User= nicht existiert oder das Programm des Dienstes fehlt).

           •   Der Typ exec ist ähnlich zu simple, aber der Diensteverwalter wird die Unit sofort nach der
               Ausführung des Hauptdiensteprogramms als gestartet betrachten. Der Diensteverwalter wird das
               Starten nachfolgender Units bis zu diesem Zeitpunkt verzögern. (Oder in anderen Worten: simple
               fährt einfach mit weiteren Aufträgen fort, direkt nachdem fork() zurückkehrt, während exec nicht
               fortfahren wird, bevor sowohl fork() als auch execve() im Diensteprozess erfolgreich waren.)
               Beachten Sie, dass dies bedeutet, dass die Befehlszeile systemctl start für exec-Dienste einen
               Fehlschlag melden wird, wenn das Programm des Dienstes nicht erfolgreich aufgerufen werden kann
               (beispielsweise weil der ausgewählte User= nicht existiert oder das Dienstprogramm fehlt). Dieser
               Typ wird impliziert, falls Zugangsberechtigungen verwandt werden (lesen Sie LoadCredential= in
               systemd.exec(5) zu Details).

           •   Falls auf forking gesetzt, wird der Verwalter die Unit sofort als gestartet betrachten, nachdem
               sich das vom Verwalter mittels Fork gestartete Programm beendet. Von der Verwendung dieses Typs
               wird abgeraten, verwenden Sie stattdessen  notify, notify-reload oder dbus.

               Es wird erwartet, dass der mit ExecStart= konfigurierte Prozess fork() als Teil seines
               Hochfahrens aufrufen wird. Es wird erwartet, dass der Elternprozess sich nach dem Hochfahren und
               der Einrichtung aller Kommunikationskanäle beendet. Der Kindprozess läuft als Hauptdiensteprozess
               weiter und der Diensteverwalter wird die Unit als gestartet betrachten, wenn sich der
               Elternprozess beendet. Dies ist das Verhalten traditioneller UNIX-Dienste. Falls diese
               Einstellung verwandt wird, wird empfohlen, auch die Option PIDFile= zu verwenden, so dass Systemd
               zuverlässig den Hauptprozess des Dienstes identifizieren kann. Der Verwalter wird mit dem Starten
               von nachfolgenden Units fortfahren, nachdem sich der Elternprozess beendet.

           •   Das Verhalten von oneshot ist ähnlich zu simple, allerdings wird der Diensteverwalter die Unit
               als hochgebracht betrachten, nachdem sich der Hauptprozess beendet hat. Er wird dann nachfolgende
               Units starten. RemainAfterExit= ist für diesen Dienstetyp besonders nützlich. Type=oneshot ist
               die implizierte Vorgabe, falls weder Type= noch ExecStart= angegeben ist. Beachten Sie, dass bei
               der Verwendung dieser Option ohne RemainAfterExit= der Dienst niemals den Zustand »active«
               erreichen wird, sondern direkt von »activating« zu »deactivating« oder »dead« übergehen wird, da
               kein Prozess zum dauerhaften Betrieb konfiguriert ist. Insbesondere bedeutet dies, dass nach der
               Ausführung eines Dienstes dieser Art (und der RemainAfterExit= nicht gesetzt hat), dieser danach
               nicht als gestartet sondern als tot angezeigt wird.

           •   Verhalten von dbus ist ähnlich zu simple; allerdings muss für Units dieses Typ der BusName=
               festgelegt werden und der Diensteverwalter wird die Unit als »oben« betrachten, wenn der
               festgelegte Busname erlangt wurde. Dieser Typ ist die Vorgabe, falls BusName= angegeben ist.

               Dienste-Units, bei denen diese Option konfiguriert ist, erlangen implizit eine Abhängigkeit von
               der Unit dbus.socket. Eine Dienste-Unit von diesem Typ wird im aktivierenden Zustand betrachtet,
               bis der angegebene Busname erlangt wurde. Sie wird als aktiviert angesehen, solange der Bus-Name
               belegt ist. Sobald der Busname freigegeben ist, wird der Dienst nicht mehr als funktional
               betrachtet. Dies hat die Auswirkung, dass der Diensteverwalter versucht, alle verbliebenen
               Prozesse, die zu dem Dienst gehören, zu beenden. Dienste, die ihren Bus-Namen als Teil ihrer
               Herunterfahrlogik abgeben, sollten daher darauf vorbereitet sein, ein SIGTERM (oder ein anderes,
               in KillSignal= konfiguriertes Signal) im Ergebnis zu erhalten.

           •   Das Verhalten von notify ist ähnlich zu exec, allerdings wird erwartet, dass der Dienst mittels
               sd_notify(3) oder einem Äquivalent eine »READY=1«-Benachrichtigung sendet, wenn er mit dem
               Hochfahren fertig ist. Systemd wird mit dem Starten nachfolgender Units fortfahren, nachdem diese
               Benachrichtigung gesandt wurde. Falls diese Option verwandt wird, sollte NotifyAccess= (siehe
               unten) auf offenen Zugriff auf den von Systemd bereitgestellten Benachrichtigungs-Socket gesetzt
               werden. Falls NotifyAccess= fehlt oder auf none gesetzt ist, wird er zwangsweise auf main
               gesetzt.

               Falls der Dienst das Neuladen unterstützt und ein Signal zum Starten des Neuladens benutzt, wird
               stattdessen notify-reload empfohlen.

           •   Das Verhalten von notify-reload ist ähnlich zu notify mit einem Unterschied: das
               UNIX-Prozessignal SIGHUP wird an den Hauptprozess des Dienstes gesandt, wenn der Dienst um einen
               Neuladen gebeten wird und der Verwalter wird auf eine Benachrichtigung, dass das Neuladen
               abgeschlossen ist, warten.

               Wenn der Neuladeprozess initiiert wird, wird erwartet, dass der Dienst mit einer
               Benachrichtigungsmeldung über sd_notify(3) antwortet, die das Feld »RELOADING=1« in Kombination
               mit »MONOTONIC_USEC=«, gesetzt auf die aktuelle monotone Zeit, enthält (d.h. CLOCK_MONOTONIC in
               clock_gettime(2)) in µs, formatiert als dezimale Zeichenkette.) Sobald das Neuladen abgeschlossen
               ist, muss eine weitere Benachrichtigungsmeldung, die »READY=1« enthält, gesandt werden.
               Verwendung dieses Dienstetyps und Implementierung dieses Neuladeprotokolls ist eine effiziene
               Alternative zur Bereitstellung des Befehls ExecReload= zum Neuladen der Konfiguration des
               Dienstes.

               Das zu sendende Signal kann mittels ReloadSignal= angepasst werden, siehe unten.

           •   Das Verhalten von idle ist sehr ähnlich zu simple; allerdings wird die tatsächliche Ausführung
               des Dienstprogramms verzögert, bis alle aktiven Aufträge abgefertigt sind. Dadurch wird
               vermieden, dass die Ausgabe von Shell-Diensten mit der Statusausgabe auf der Konsole vermischt
               wird. Beachten Sie, dass dieser Typ nur zur Verbesserung der Konsolenausgabe nützlich ist, er ist
               nicht als allgemeines Werkzeug zum Sortieren von Units nützlich und der Effekt dieses Dienstetyps
               unterliegt einer Zeitüberschreitung von 5 s, nach der das Dienstprogramm auf jeden Fall
               ausgeführt wird.

           Es wird empfohlen, Type=exec für langlaufende Dienste zu verwenden, da es sicherstellt, dass
           Prozess-Einrichtungsfehler (z.B. Fehler wie ein fehlendes Diensteprogramm oder fehlende Benutzer)
           korrekt nachverfolgt werden. Da dieser Dienstetyp allerdings Fehler im eigenen Einrichtungscode nicht
           weiterleitet (im Gegensatz zu Fehlern in den vorbereitenden Schritten, die der Diensteverwalter vor
           execve() ausführt) und keine Ordnung von anderen Units nach Abschluss der Initialisierung des
           Dienste-Codes selbst erlaubt (was beispielsweise für Clients sinnvoll ist, die sich mittels
           irgendeiner Art von IPC mit dem Dienst verbinden und der IPC-Kanal nur durch den Dienst selbst
           errichtet wird (statt dies vorab mittels Socket- oder Bus-Aktivierung oder ähnlichem zu erledigen)),
           könnte er in vielen Fällen nicht ausreichend sein. Dann sind notify, notify-reload oder dbus
           (Letzteres nur in dem Fall, in dem der Dienst eine D-Bus-Schnittstelle bereitstellt) die bevorzugten
           Optionen, da sie dem Dienstprogramm genau einzuplanen erlauben, wann der Dienst als erfolgreich
           gestartet betrachtet werden soll und wann mit den nachfolgenden Units fortgefahren werden soll. Die
           Dienstetypen notify/notify-reload benötigen explizite Unterstützung im Programmcode des Dienstes (da
           sd_notify() oder eine äquivalente API zum geeigneten Zeitpunkt durch den Dienst aufgerufen werden
           muss) — falls dies nicht unterstützt wird, ist forking eine Alternative: es unterstützt das
           schwergewichtige Startprotokoll traditioneller UNIX-Dienste. Beachten Sie, dass die Verwendung aller
           von simple verschiedenen Typen möglicherweise den Systemstartprozess verzögert, da der
           Diensteverwalter darauf warten muss, dass die Initialisierung für mindestens einige Dienste
           abgeschlossen ist. (Es wird im Allgemeinen auch nicht empfohlen, idle oder oneshot für langlaufende
           Dienste zu verwenden.)

           Beachten Sie, dass verschiedene Einstellungen (z.B. User=, Group= mittels Libc-NSS) beim Einsatz zu
           »versteckten« blockierenden IPC-Aufrufen von anderen Diensten führen könnte. Manchmal könnte es
           ratsam sein, den Dienstetyp simple zu verwenden, um sicherzustellen, dass die Transaktionslogik des
           Diensteverwalters nicht durch solche, möglicherweise langsamen Aktionen und versteckten
           Abhängigkeiten betroffen ist, da dies der einzige Dienstetyp ist, bei dem der Diensteverwalter nicht
           darauf warten wird, dass solche Dienste-Ausführungs-Einrichtungsaktionen abgeschlossen sind, bevor er
           fortfährt.

       ExitType=
           Legt fest, wann der Verwalter den Prozess als beendeet betrachten soll. Entweder main oder cgroup:

           •   Falls auf main gesetzt (die Vorgabe), wird der Diensteverwalter die Unit als gestoppt betrachten,
               wenn der Hauptprozess, der entsprechend Type= bestimmt wird, sich beendet. Konsequenterweise kann
               dies nicht mit Type=oneshot verwandt werden.

           •   Falls auf cgroup gesetzt, wird der Dienst als laufend betrachtet, solange mindestens ein Prozess
               in der Cgroup sich nicht beendet hat.

           Im allgemeinen wird empfohlen, ExitType=main zu verwenden, wenn ein Dienst ein bekanntes Modell zur
           Erzeugung von Prozessen mit Fork hat und ein Hauptprozess zuverlässig bestimmt werden kann. ExitType=
           cgroup ist für Anwendungen gedacht, deren Modell zur Erzeugung von Prozessen mit Fork vorab unbekannt
           ist und die keinen bestimmten Hauptprozess haben könnten. Es ist gut für flüchtige oder automatisch
           erstellte Dienste, wie graphische Anwendungen innerhalb einer Desktop-Umgebung, geeignet.

           Hinzugefügt in Version 250.

       RemainAfterExit=
           Akzeptiert einen logischen Wert, der angibt, ob der Dienst, selbst wenn sich alle seine Prozesse
           beendet haben, als aktiv betrachtet werden sollte. Standardmäßig no.

       GuessMainPID=
           Akzeptiert einen logischen Wert, der angibt, ob Systemd versuchen soll, die Haupt-PID eines Dienstes
           zu raten, falls es sie nicht zuverlässig bestimmen kann. Diese Option wird ignoriert, außer
           Type=forking ist gesetzt und PIDFile= ist nicht gesetzt, da für andere Typen oder mit einer explizit
           konfigurierten PID-Datei die Haupt-PID immer bekannt ist. Der Ratealgorithmus kann zu einem falschen
           Ergebnis kommen, falls der Daemon aus mehr als einem Prozess besteht. Falls die Haupt-PID nicht
           bestimmt werden kann, wird die Fehlschlagerkennung und der automatische Neustart eines Dienstes nicht
           zuverlässig funktionieren. Standardmäßig yes.

       PIDFile=
           Akzeptiert einen Pfad zur PID-Datei des Dienstes. Für Dienste, bei denen Type= auf forking gesetzt
           ist, wird die Verwendung dieser Option empfohlen. Der angegebene Pfad zeigt typischerweise auf eine
           Datei unterhalb von /run/. Falls ein relativer Pfad angegeben wird, wird ihm daher /run/
           vorangestellt. Der Diensteverwalter wird die PID des Hauptprozesses des Dienstes nach dem Starten des
           Dienstes aus dieser Datei auslesen. Der Diensteverwalter wird nicht in die hier konfigurierte Datei
           schreiben, allerdings wird er die Datei löschen, falls sie nach dem Beenden des Dienstes noch
           existiert. Die PID-Datei muss keinem privilegierten Benutzer gehören, falls sie aber einem
           unprivilegierten Benutzer gehört, werden zusätzliche Sicherheitsbeschränkungen durchgesetzt: die
           Datei darf kein Symlink auf eine Datei, die einem anderen Benutzer gehört, sein (weder direkt noch
           indirekt) und die PID-Datei muss sich auf einen Prozess beziehen, der bereits zum Dienst gehört.

           Beachten Sie, dass PID-Dateien in modernen Projekten vermieden werden sollten. Verwenden Sie, wo
           möglich, Type=notify, Type=notify-reload oder Type=simple, die keinen Einsatz von PID-Dateien
           benötigen, um den Hauptprozess des Dienstes zu bestimmen, und unnötige Aufrufe von Fork vermeiden.

       BusName=
           Akzeptiert einen D-Bus-Zielnamen, den dieser Dienst nutzen soll. Diese Option ist für Dienste
           verpflichtend, bei denen Type= auf dbus gesetzt ist. Es wird empfohlen, diese Eigenschaft immer zu
           setzen, falls sie bekannt ist, um es zu erleichtern, den Dienstenamen auf das D-Bus-Ziel abzubilden.
           Insbesondere die Unterbefehle von systemctl service-log-level/service-log-target verwenden dies.

       ExecStart=
           Befehle, die beim Starten dieses Dienstes ausgeführt werden.

           Es muss genau ein Befehl angegeben werden, außer Type= ist auf oneshot gesetzt. Wenn Type=oneshot
           verwandt wird, kann diese Einstellung mehrfach verwandt werden, um mehrere auszuführende Befehle zu
           definieren. Falls dieser Option die leere Zeichenketten zugewiesen wird, wird die Liste der zu
           startenden Befehle zurückgesetzt und vorhergehende Zuweisungen zu dieser Option haben keinen Effekt.
           Falls kein ExecStart= angegeben ist, dann muss der Dienst RemainAfterExit=yes und mindestens eine
           gesetzte ExecStop=-Zeile haben. (Dienste, denen sowohl ExecStart= als auch ExecStop= fehlt, sind
           nicht gültig.)

           Falls mehr als ein Befehl konfiguriert ist, werden die Befehle der Reihe nach in der Reihenfolge, in
           der sie in der Unit-Datei auftauchen, ausgeführt. Falls einer der Befehle fehlschlägt (und ihm kein
           »-« vorangestellt ist) werden die anderen Zeilen nicht ausgeführt und die Unit wird als
           fehlgeschlagen betrachtet.

           Außer falls Type=forking gesetzt ist, wird der über die Befehlszeile gestartete Prozess als
           Hauptprozess des Daemons betrachtet.

       ExecStartPre=, ExecStartPost=
           Zusätzliche Befehle, die vor bzw. nach dem Befehl in ExecStart= gestartet werden. Syntax ist
           identisch zu ExecStart=. Mehrere Befehlszeilen sind unabhängig vom Dienstetyp (d.h. Type=) erlaubt
           und die Befehle werden seriell einer nach dem anderen ausgeführt.

           Falls einer dieser Befehle (dem nicht »-« vorangestellt ist) fehlschlägt, wird der Rest nicht
           ausgeführt und die Unit als fehlgeschlagen betrachtet.

           ExecStart=-Befehle werden nur ausgeführt, nachdem alle ExecStartPre=-Befehle, denen kein »-«
           vorangestellt wurde, sich erfolgreich beendet haben.

           ExecStartPost=-Befehle werden nur ausgeführt, nachdem die in ExecStart= festgelegten Befehle
           erfolgreich gestartet wurden, wie durch Type= festgelegt (d.h. der Prozess wurde für Type=simple oder
           Type=idle gestartet, der letzte ExecStart=-Prozess hat sich erfolgreich für Type=oneshot beendet, der
           anfängliche Prozess hat sich für Type=forking erfolgreich beendet, »READY=1« ist für
           Type=notify/Type=notify-reload gesetzt oder der BusName= ist für Type=dbus genommen worden.

           Beachten Sie, dass ExecStartPre= nicht zum Starten von langlaufenden Prozessen verwandt werden darf.
           Alle von mittels ExecStartPre= aufgerufenen Prozesse mittels Fork gestarteten Prozesse werden
           getötet, bevor der nächste Diensteprozess ausgeführt wird.

           Beachten Sie, dass falls einer der in ExecStartPre=, ExecStart= oder ExecStartPost= festgelegten
           Prozesse fehlschlägt (und ihm kein »-« vorangestellt wurde, siehe oben) oder seine Zeit abgelaufen
           ist, bevor der Dienst vollständig hochgekommen ist, die Ausführung mit den in ExecStopPost=
           festgelegten Komponenten fortgefahren wird und die Befehle in ExecStop= übersprungen werden.

           Beachten Sie, dass die Ausführung von ExecStartPost= zum Zwecke der Before=/After=
           Ordnungsbeschränkungen berücksichtigt wird.

       ExecCondition=
           Optionale Befehle, die vor den Befehlen in ExecStartPre= gestartet werden. Syntax ist identisch zu
           ExecStart=. Mehrere Befehlszeilen sind unabhängig vom Dienstetyp (d.h. Type=) erlaubt und die Befehle
           werden seriell einer nach dem anderen ausgeführt.

           Das Verhalten ist wie ein ExecStartPre= und die Bedingungsprüfung erfolgt hybrid: wenn sich ein
           ExecCondition=-Befehl mit Exit-Code 1 bis 254 (einschließlich) beendet, werden die verbleibenden
           Befehle übersprungen und die Unit wird nicht als fehlgeschlagen markiert. Falls sich allerdings ein
           ExecCondition=-Befehl mit 255 oder unnormal (z.B. wegen einer Zeitüberschreitung, durch ein Signal
           getötet) beendet, wird die Unit als fehlgeschlagen betrachtet (und die verbliebenen Befehle
           übersprungen). Exit-Code 0 oder solche, die auf SuccessExitStatus= passen, führen zur Ausführung der
           nächsten Befehle.

           Die gleiche Empfehlung, keine langlaufenden Prozesse in ExecStartPre= auszuführen, gilt auch für
           ExecCondition=. ExecCondition= wird, falls eine Beendigung nicht Null oder unnormal erfolgt, beim
           Stoppen des Dienstes auch die in ExecStopPost= aufgeführten Befehle ausführen, wie die oben
           beschriebenen.

           Hinzugefügt in Version 243.

       ExecReload=
           Zu startende Befehle lösen ein Neuladen der Konfiguration in dem Dienst aus. Dieses Argument
           akzeptiert mehrere Befehlszeilen, die dem gleichen Schema wie oben für ExecStart= folgen. Die
           Verwendung dieser Einstellung ist optional. Kennzeichner- und Umgebungsvariablenersetzung wird hier
           mit dem gleichen Schema wie für ExecStart= unterstützt.

           Eine zusätzliche, besondere Umgebungsvariable wird gesetzt: falls bekannt, wird $MAINPID auf den
           Hauptprozess des Daemons gesetzt und kann für Befehlszeilen wie der folgenden benutzt werden:

               ExecReload=kill -HUP $MAINPID

           Beachten Sie, dass das Neuladen eines Daemons durch Einstellen eines Signals in die Warteschlange
           (wie in dem obigen Beispiel) normalerweise keine gute Wahl ist, da dies eine asynchrone Aktion und
           daher nicht dazu geeigent ist, das Neuladen von mehreren Diensten untereinander zu sortieren. Es wird
           daher nachdrücklich empfohlen, Type=notify-reload anstelle von ExecReload= zu verwenden oder
           ExecReload= auf einen Befehl zu setzen, der nicht nur das Neuladen des Daemons auslöst, sondern auch
           synchron darauf wartet, dass dies abgeschlossen wird. Beispielsweise verwendet dbus-broker(1)
           Folgendes:

               ExecReload=busctl call org.freedesktop.DBus \
                       /org/freedesktop/DBus org.freedesktop.DBus \
                       ReloadConfig

       ExecStop=
           Die zum Stoppen des mittels ExecStart= gestarteten Dienstes zu verwendenden Befehle. Dieses Argument
           akzeptiert mehrere Befehlszeilen, die dem gleichen Schema wie oben für ExecStart= beschrieben folgen.
           Die Verwendung dieser Einstellung ist optional. Nachdem die in dieser Option konfigurierten Befehle
           ausgeführt wurden, wird impliziert, dass der Dienst gestoppt ist und alle von ihm verbliebenen
           Prozesse werden gemäß der Einstellung KillMode= beendet (siehe systemd.kill(5)). Falls diese Option
           nicht angegeben ist, werden die Prozesse durch Senden des in KillSignal= oder RestartKillSignal=
           festgelegten Signals beendet, wenn das Beenden eines Dienstes angefragt wird. Kennzeichner- und
           Umgebungsvariablenersetzung wird unterstützt (einschließlich $MAINPID, siehe oben).

           Beachten Sie, dass es normalerweise nicht ausreicht, einen Befehl für diese Einstellung festzulegen,
           der nur um das Beenden des Dienstes bittet (beispielsweise durch Senden einer Art von Signal an es),
           aber dann nicht darauf wartet, dass es auch passiert. Da die verbleibenden Prozesse des Dienstes,
           direkt nachdem der Befehl sich beendet hat, gemäß den oben beschriebenen KillMode= und KillSignal=
           oder RestartKillSignal= getötet werden, kann dies zu einem unsauberen Stopp führen. Der angegebene
           Befehl sollte daher eine synchrone Aktion und nicht eine asynchrone sein.

           Beachten Sie, dass die in ExecStop= festgelegten Befehle nur ausgeführt werden, wenn der Dienst
           zuerst erfolgreich gestartet wird. Sie werden nicht aufgerufen, falls der Dienst überhaupt nie
           gestartet wurde oder im Falle, dass das Starten fehlschlug, beispielsweise weil einer der in
           ExecStart=, ExecStartPre= oder ExecStartPost= festgelegten Befehle fehlschlug (oder ihm kein »-«
           vorangestellt wurde, siehe oben) oder eine Zeitüberschreitung erfolgte. Verwenden Sie ExecStopPost=,
           um Befehle aufzurufen, wenn ein Dienst nicht korrekt startete und wieder heruntergefahren wird.
           Beachten Sie auch, dass die Stopp-Aktion immer durchgeführt wird, wenn der Dienst erfolgreich
           startete, selbst falls die Prozesse in dem Dienst sich von alleine beendeten oder getötet wurden. Der
           Stopp-Befehl muss für diesen Fall vorbereitet sein. $MAINPID wird nicht gesetzt sein, falls Systemd
           weiß, das sich der Hauptprozess zum Zeitpunkt des Aufrufs des Stopp-Befehls beendet hat.

           Diensteneustartanfragen sind als Stopp-Aktionen gefolgt von Start-Aktionen implementiert. Dies
           bedeutet, dass während einer Diensteneustartaktion ExecStop= und ExecStopPost= ausgeführt werden.

           Es wird empfohlen, diese Einstellung für Befehle zu verwenden, die mit dem Dienst kommunizieren, die
           das saubere Beenden erbitten. Für Post-mortem-Bereinigungsschritte verwenden Sie stattdessen
           ExecStopPost=.

       ExecStopPost=
           Zusätzliche Befehle, die ausgeführt werden, nachdem der Dienst beendet wurde. Dies schließt Fälle mit
           ein, bei denen die in ExecStop= konfigurierten Befehle verwandt wurden, bei denen der Dienst kein
           definiertes ExecStop= hat oder bei denen der Dienst unerwartet beendet wurde. Dieses Argument
           akzeptiert mehrere Befehlszeilen, die dem gleichen für ExecStart= definierten Schema folgen. Die
           Verwendung dieser Einstellungen ist optional. Kennzeichner- und Umgebungsvariablenersetzung wird
           unterstützt. Beachten Sie, dass Befehle, die mit dieser Einstellung festgelegt werden – anders als
           ExecStop= – aufgerufen werden, wenn ein Dienst nicht korrekt startet und wieder heruntergefahren
           wird.

           Es wird empfohlen, diese Einstellung für Aufräumaktionen zu verwenden, die ausgeführt werden sollen,
           selbst wenn das korrekte Starten des Dienstes fehlschlug. Befehle, die mit dieser Einstellung
           konfiguriert sind, müssen in der Lage sein, zu funktionieren, selbst falls der Dienst mitten im
           Starten fehlschlug und unvollständig initialisierte Daten hinterließ. Da sich die Prozesse des
           Dienstes wahrscheinlich bereits beendet haben, wenn die mit dieser Einstellung festgelegten Befehle
           ausgeführt werden, sollten sie nicht versuchen, mit ihnen zu kommunizieren.

           Beachten Sie, dass alle mit dieser Einstellung konfigurierten Befehle mit dem Ergebnis-Code des
           Dienstes sowie dem Exit-Code und -Status des Hauptprozesses, gesetzt auf die Umgebungsvariablen
           $SERVICE_RESULT, $EXIT_CODE und $EXIT_STATUS, aufgerufen werden, siehe systemd.exec(5) für Details.

           Beachten Sie, dass die Ausführung von ExecStopPost= zum Zwecke der Before=/After=
           Ordnungsbeschränkungen berücksichtigt wird.

       RestartSec=
           Konfiguriert die vor dem Neustart eines Dienstes zu schlafende Zeit (wie in Restart= konfiguriert).
           Akzeptiert einen einheitenfreien Wert in Sekunden oder einen Zeitdauerwert wie »5min 20s«.
           Standardmäßíg 100 ms.

       RestartSteps=
           Konfiguriert die Anzahl an zu durchlaufenden Schritten, um das Interval von Selbstneustarts von
           RestartSec= auf RestartMaxDelaySec= zu erhöhen. Akzeptiert eine positive Ganzzahl oder 0, um es zu
           deaktivieren. Standardmäßig 0.

           Diese Einstellung ist nur wirksam, falls auch RestartMaxDelaySec= gesetzt ist.

           Hinzugefügt in Version 254.

       RestartMaxDelaySec=
           Konfiguriert die vor dem Neustart eines Dienstes maximal zu schlafende Zeit während das Interval mit
           RestartSteps= erhöht wird. Akzeptiert einen Wert im gleichen Format wie RestartSec= oder »infinity«,
           um diese Einstellung zu deaktivieren. Standardmäßig »infinity«.

           Diese Einstellung ist nur wirksam, falls auch RestartSteps= gesetzt ist.

           Hinzugefügt in Version 254.

       TimeoutStartSec=
           Konfiguriert die Zeit, die auf das Starten gewartet werden soll. Falls ein Daemon-Dienst den
           Abschluss des Startens nicht innerhalb der konfigurierten Zeit signalisiert, wird der Dienst als
           fehlgeschlagen angesehen und wieder heruntergefahren. Die genaue Aktion hängt von der Option
           TimeoutStartFailureMode= ab. Akzeptiert einen einheitenfreien Wert in Sekunden oder einen
           Zeitdauerwert wie »5min 20s«. Übergeben Sie »infinity«, um die Zeitüberschreitungslogik zu
           deaktivieren. Standardmäßig das in dem Verwalter gesetzte DefaultTimeoutStartSec=, außer wenn
           Type=oneshot konfiguriert ist, dann wird die Zeitüberschreitung standardmäßig deaktiviert (siehe
           systemd-system.conf(5)).

           Falls ein Dienst vom Type=notify/Type=notify-reload »EXTEND_TIMEOUT_USEC=…« sendet, kann dies dazu
           führen, dass die Startzeit sich über TimeoutStartSec= hinauszieht. Der erste Empfang dieser Nachricht
           muss auftreten, bevor TimeoutStartSec= überschritten wird und sobald die Startzeit sich über
           TimeoutStartSec= hinausgezogen hat, wird der Diensteverwalter dem Dienst die Weiterführung des
           Startens erlauben, vorausgesetzt, der Dienst wiederholt »EXTEND_TIMEOUT_USEC=…« innerhalb des
           festgelegten Intervalls, bis der Dienstestart durch »READY=1« abgeschlossen ist (siehe sd_notify(3)).

           Beachten Sie, dass die Start-Zeitüberschreitung auch beim Neuladen von Diensten angewandt wird,
           unabhängig, ob dies mittels ExecReload= oder mittels der Type=notify-reload-Neuladelogik erfolgt.
           Falls das Neuladen nicht innerhalb der konfigurierten Zeit erfolgt, wird das Neuladen als
           fehlgeschlagen betrachtet und der Dienst wird mit der alten Konfiguration weiterlaufen. Dies wird den
           laufenden Dienst nicht betreffen, aber es wird protokolliert und führt dazu, dass beispielsweise
           systemctl reload fehlschlägt.

           Hinzugefügt in Version 188.

       TimeoutStopSec=
           Diese Option dient zwei Zwecken. Zuerst konfiguriert sie die Zeit, die für jeden ExecStop=-Befehl
           gewartet werden soll. Falls bei einem von ihnen eine Zeitüberschreitung auftritt, werden nachfolgende
           ExecStop=-Befehle übersprungen und der Dienst wird durch SIGTERM beendet. Falls keine
           ExecStop=-Befehle festgelegt sind, erhält der Dienst das SIGTERM sofort. Dieses Standardverhalten
           kann mit der Option TimeoutStopFailureMode= geändert werden. Zweitens konfiguriert sie die Zeit, die
           auf das Stoppen des Dienstes selbst gewartet werden soll. Falls der sich nicht innerhalb der
           festgelegten Zeit beendet, wird er zwangsweise durch SIGKILL (siehe KillMode= in systemd.kill(5))
           beendet. Akzeptiert einen einheitenfreien Wert in Sekunden oder einen Zeitdauerwert wie »5min 20s«.
           Übergeben Sie »infinity«, um die Zeitüberschreitungslogik zu deaktivieren. Standardmäßig
           DefaultTimeoutStopSec= aus der Verwalterkonfigurationsdatei (siehe systemd-system.conf(5)).

           Falls ein Dienst vom Type=notify/Type=notify-reload »EXTEND_TIMEOUT_USEC=…« sendet, kann dies dazu
           führen, dass die Stoppzeit sich über TimeoutStopSec= hinauszieht. Der erste Empfang dieser Nachricht
           muss auftreten, bevor TimeoutStopSec= überschritten wird und sobald die Stoppzeit sich über
           TimeoutStopSec= hinausgezogen hat, wird der Diensteverwalter dem Dienst die Weiterführung des
           Stoppens erlauben, vorausgesetzt, der Dienst wiederholt »EXTEND_TIMEOUT_USEC=…« innerhalb des
           festgelegten Intervalls oder beendet sich (siehe sd_notify(3)).

           Hinzugefügt in Version 188.

       TimeoutAbortSec=
           Diese Option konfiguriert die Zeit, die auf die Beendigung des Dienstes gewartet werden soll, wenn
           dieser aufgrund einer Watchdog-Zeitüberschreitung abgebrochen wird (siehe WatchdogSec=)). Falls der
           Dienst eine kleine TimeoutStopSec= hat, kann diese Option dem System mehr Zeit zum Schreiben eines
           Speicherauszuges des Dienstes geben. Nach Ablauf wird der Dienst zwangsweise mit SIGKILL (siehe
           KillMode= in systemd.kill(5)) beendet. In diesem Fall wird die Speicherauszugsdatei abgeschnitten.
           Verwenden Sie TimeoutAbortSec=, um eine vernünftige Zeitüberschreitung für das Erstellen von
           Speicherauszügen pro Dienst zu setzen, die groß genug ist, um alle erwarteten Daten zu schreiben aber
           gleichzeitg kurz genug ist, um den Fehlschlag des Dienstes in angemessener Zeit zu handhaben.

           Akzeptiert einen Wert ohne Einheit in Sekunden oder einen Zeitdauerwert wie »5min 20s«. Übergeben Sie
           einen leeren Wert, um die Handhabung der zugeordneten Watchdog-Zeitüberschreitung zu überspringen und
           auf TimeoutStopSec= zurückzufallen. Übergeben Sie »infinity«, um die Zeitüberschreitungslogik zu
           überspringen. Standardmäßig DefaultTimeoutAbortSec= aus der Verwalterkonfigurationsdatei (siehe
           systemd-system.conf(5)).

           Falls ein Dienst vom Type=notify/Type=notify-reload SIGABRT selber handhabt (statt sich auf den
           Kernel zum Schreiben eines Speicherauszuges zu verlassen), kann er »EXTEND_TIMEOUT_USEC=…« senden, um
           die Abbruchzeit über TimeoutAbortSec= hinaus zu verlängern. Der erste Empfang dieser Nachricht muss
           auftreten, bevor TimeoutAbortSec= überschritten wird und sobald die Abbruchzeit sich über
           TimeoutAbortSec= hinausgezogen hat, wird der Diensteverwalter dem Dienst die Weiterführung des
           Abbrechens erlauben, vorausgesetzt, der Dienst wiederholt »EXTEND_TIMEOUT_USEC=…« innerhalb des
           festgelegten Intervalls oder beendet sich (siehe sd_notify(3)).

           Hinzugefügt in Version 243.

       TimeoutSec=
           Eine Kurzform, um sowohl TimeoutStartSec= als auch TimeoutStopSec= auf den angegebenen Wert zu
           konfigurieren.

       TimeoutStartFailureMode=, TimeoutStopFailureMode=
           Diese Option konfiguriert die Aktion, die durchgeführt wird, falls ein Dameon-Dienst nicht das
           Hochfahren innerhalb von TimeoutStartSec= bzw. nicht das Beenden innerhalb von TimeoutStopSec=
           anzeigt. Akzeptiert entweder terminate, abort oder kill. Die Vorgabe für beide Optionen ist
           terminate.

           Falls terminate gesetzt ist, wird der Dienst sauber beendet, indem ihm das in KillSignal= festgelegte
           Signal (standardmäßig SIGTERM, siehe systemd.kill(5)) gesandt wird. Falls sich der Dienst nicht
           beendet, dann wird FinalKillSignal= nach TimeoutStopSec= gesendet. Falls abort gesetzt ist, wird
           stattdessen WatchdogSignal= gesandt und TimeoutAbortSec= gilt bevor FinalKillSignal= gesandt wird.
           Diese Einstellung kann zur Analyse von Diensten verwandt werden, die beim Hoch- oder Runterfahren
           zeitweilig fehlschlagen. Durch Verwendung von kill wird der Dienst sofort durch Senden von
           FinalKillSignal= beendet, ohne weitere Zeitüberschreitungen. Diese Einstellung kann zur
           Beschleunigung des Herunterfahrens von fehlgeschlagenen Diensten verwandt werden.

           Hinzugefügt in Version 246.

       RuntimeMaxSec=
           Konfiguriert eine maximale Laufzeit für den Dienst. Falls dies verwandt wird und der Dienst länger
           als die festgelegte Zeit gelaufen ist, wird er beendet und in einen Fehlschlagzustand versetzt.
           Beachten Sie, dass diese Einstellung keine Auswirkungen auf Type=oneshot-Dienste hat, da diese sofort
           beendet werden, nachdem ihre Aktivierung abgeschlossen ist (verwenden Sie TimeoutStartSec=, um ihre
           Aktivierung zu begrenzen). Übergeben Sie »infinity« (die Vorgabe), um keine Laufzeitbeschränkung zu
           konfigurieren.

           Falls ein Dienst vom Type=notify/Type=notify-reload »EXTEND_TIMEOUT_USEC=…« sendet, kann dies dazu
           führen, dass die Laufzeit sich über RuntimeMaxSec= hinauszieht. Der erste Empfang dieser Nachricht
           muss auftreten, bevor RuntimeMaxSec= überschritten wird und sobald die Laufzeit sich über
           RuntimeMaxSec= hinausgezogen hat, wird der Diensteverwalter dem Dienst die Weiterführung des Laufens
           erlauben, vorausgesetzt, der Dienst wiederholt »EXTEND_TIMEOUT_USEC=…« innerhalb des festgelegten
           Intervalls, bis das Herunterfahren durch »STOPPING=1« (oder die Beendigung) erreicht wird (siehe
           sd_notify(3)).

           Hinzugefügt in Version 229.

       RuntimeRandomizedExtraSec=
           Diese Option verändert RuntimeMaxSec= durch Erhöhung der maximalen Laufzeit mit einer
           gleichverteilten Dauer zwischen 0 und dem festgelegten Wert (in Sekunden). Falls RuntimeMaxSec= nicht
           festgelegt ist, wird diese Funktionalität deaktiviert.

           Hinzugefügt in Version 250.

       WatchdogSec=
           Konfiguriert die Watchdog-Zeitüberschreitung für einen Dienst. Der Watchdog wird aktiviert, wenn das
           Hochfahren abgeschlossen ist. Der Dienst muss regelmäßig sd_notify(3) mit »WATCHDOG=1« (d.h. dem
           »Totmannschalter«) aufrufen. Falls die Zeit zwischen zwei solcher Aufrufe größer als die
           konfigurierte Zeit ist, dann wird der Dienst in einen Fehlschlagzustand versetzt und mit SIGABRT
           (oder dem mit WatchdogSignal= festgelegten Signal) beendet. Durch Setzen von Restart= auf on-failure,
           on-watchdog, on-abnormal oder always wird der Dienst automatisch neu gestartet. Die hier
           konfigurierte Zeit wird in der Umgebungsvariablen WATCHDOG_USEC= an den ausgeführten Prozess
           übergeben. Dies ermöglicht es Daemons, die Totmannschaltlogik zu aktivieren, falls für den Dienst die
           Watchdog-Unterstützung aktiviert ist. Falls diese Option verwandt wird, sollte NotifyAccess= (siehe
           unten) auf offenen Zugriff auf das durch Systemd bereitgestellte Benachrichtigungs-Socket gesetzt
           werden. Falls NotifyAccess= nicht gesetzt ist, wird es implizit auf main gesetzt. Standardmäßig 0,
           wodurch diese Funktionalität deaktiviert wird. Der Dienst kann prüfen, ob der Diensteverwalter
           Watchdog-Lebenszeichenbenachrichtigungen erwartet. Siehe sd_watchdog_enabled(3) für Details.
           sd_event_set_watchdog(3) kann zur Aktivierung der automatischen
           Watchdog-Benachrichtigungsunterstützung verwandt werden.

       Restart=
           Konfiguriert, ob der Dienst neu gestartet werden soll, wenn der Diensteprozess sich beendet, getötet
           wird oder eine Zeitüberschreitung erreicht wird. Der Diensteprozess kann der Hauptdiensteprozess
           sein, aber er kann auch einer der mit ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost= oder
           ExecReload= festgelegten sein. Wenn der Tod des Prozesses das Ergebnis einer Systemd-Aktion ist (z.B.
           Dienste-Stopp oder -Neustart), wird der Dienst nicht neu gestartet. Zeitüberschreitungen schließen
           nicht eingehaltene Fristen für die Watchdog-»Totmannschaltung« und Zeitüberschreitungen für die
           Aktionen Dienste-Start, -Neuladen und -Stopp ein.

           Akzeptiert entweder no, on-success, on-failure, on-abnormal, on-watchdog, on-abort oder always. Falls
           auf no gesetzt (die Vorgabe), wird der Dienst nicht neu gestartet. Falls auf on-success gesetzt, wird
           er nur neu gestartet, wenn sich der Diensteprozess sauber beendet. In diesem Zusammenhang bedeutet
           ein sauberes Beenden folgendes:

           •   der Exit-Code ist 0

           •   für alle Typen außer Type=oneshot: eines der Signale SIGHUP, SIGINT, SIGTERM, SIGPIPE

           •   einer der in SuccessExitStatus= festgelegten Exit-Stati und -Signale

           Falls auf on-failure gesetzt, wird der Dienst neu gestartet, wenn der Prozess sich mit einem von Null
           verschiedenen Exit-Code beendet, durch ein Signal beendet wird (einschließlich eines
           Speicherauszuges, aber ausschließlich der vorher genannten Signale), wenn eine Aktion (wie das
           Neuladen eines Dienstes) in eine Zeitüberschreitung läuft und wenn die konfigurierte
           Watchdog-Zeitüberschreitung ausgelöst wird. Falls auf on-abnormal gesetzt, wird der Dienst neu
           gestartet, wenn der Prozess durch ein Signal beendet wird (einschließlich eines Speicherauszuges,
           aber ausschließlich der vorher genannten Signale), wenn eine Aktion in eine Zeitüberschreitung läuft
           und wenn die konfigurierte Watchdog-Zeitüberschreitung ausgelöst wird. Falls auf on-abort gesetzt,
           wird der Dienst nur neu gestartet, falls sich der Dienst aufgrund eines nicht abgefangenen Signals,
           das nicht als sauberer Exit-Status festgelegt ist, beendet hat. Falls auf on-watchdog gesetzt, wird
           der Dienst nur neu gestartet, wenn die Watchdog-Zeitüberschreitung für den Dienst abläuft. Falls auf
           always gesetzt, wird der Dienst neu gestartet, unabhängig davon, ob er sauber beendet wurde oder
           nicht, abnormal durch ein Signal beendet wurde oder in eine Zeitüberschreitung lief. Beachten Sie,
           dass Dienste mit Type=oneshot niemals bei einem sauberen Exit-Status neu gestartet werden, d.h.
           always und on-success für sie abgelehnt werden.

           Tabelle 1. Exit-Gründe und der Effekt der Einstellung Restart=
           ┌────────────────────────────────┬────┬────────┬────────────┬────────────┬─────────────┬──────────┬─────────────┐
           │Neustart-Einstellung/Exit-Grundnoalwayson-successon-failureon-abnormalon-aborton-watchdog │
           ├────────────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
           │Sauberer Exit-Code oder -Signal │    │ X      │ X          │            │             │          │             │
           ├────────────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
           │Unsauberer Exit-Code            │    │ X      │            │ X          │             │          │             │
           ├────────────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
           │Unsauberes Signal               │    │ X      │            │ X          │ X           │ X        │             │
           ├────────────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
           │Zeitüberschreitung              │    │ X      │            │ X          │ X           │          │             │
           ├────────────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
           │Watchdog                        │    │ X      │            │ X          │ X           │          │ X           │
           └────────────────────────────────┴────┴────────┴────────────┴────────────┴─────────────┴──────────┴─────────────┘
           Als Ausnahme zu den obigen Einstellungen wird der Dienst nicht neu gestartet, falls der Exit-Code
           oder das Exit-Signal in RestartPreventExitStatus= (siehe unten) festgelegt ist oder der Dienst mit
           systemctl stop oder einer äquivalenten Aktion gestoppt wird. Auch wird der Dienst immer neu
           gestartet, falls der Exit-Code oder das Exit-Signal in RestartForceExitStatus= (siehe unten)
           festgelegt ist.

           Beachten Sie, dass der Diensteneustart der mit StartLimitIntervalSec= und StartLimitBurst=
           konfigurierten Unit-Startratenbegrenzung unterliegt, siehe systemd.unit(5) für Details.

           Für langlaufende Dienste wird empfohlen, dies auf on-failure zu setzen, um die Zuverlässigkeit zu
           erhöhen, indem die automatische Wiederherstellung bei Fehlern versucht wird. Für Dienste, die sich
           nach eigenen Kriterien beenden (und sofortige Neustarts vermeiden) können, ist on-abnormal eine
           alternative Wahl.

       RestartMode=
           Akzeptiert einen Zeichenkettenwert, der festlegt, wie ein Dienst neu gestartet werden soll:

           •   Falls auf normal gesetzt (die Vorgabe), wird der Dienst neugestartet, indem er durch einen
               fehlgeschlagenen/inaktiven Zustand geht.

               Hinzugefügt in Version 254.

           •   Falls auf direct gesetzt, geht der Dienst während des automatischen Neustarts direkt in den
               aktivierenden Status über und überspringt den fehlgeschlagenen/inaktiven Zustand. ExecStopPost=
               wird weiterhin aufgerufen. OnSuccess= und OnFailure= werden übersprungen.

               Diese Option ist in den Fällen nützlich, bei denen eine Abhängigkeit vorübergehend fehlschlagen
               kann, aber es nicht gewünscht ist, dass diese temporären Fehlschläge zum Fehlschlagen der
               abhängigen Units führen. Abhängige Units werden nicht über diese temporären Fehlschläge
               informiert.

               Hinzugefügt in Version 254.

           •   Falls auf debug gesetzt, wird der Diensteverwalter Meldungen mit Bezug zu der Unit auf der Stufe
               »Debug« protokollieren, während automatisierte Neustarts versucht werden, bis entweder der Dienst
               die Ratenbegrenzung erreicht hat oder er erfolgreich ist. Auch wird die Umgebungsvariable
               $DEBUG_INVOCATION=1 für die Unit gesetzt. Dies ist nützlich, um zusätzliche Informationen zu
               erhalten, wenn ein Dienst beim Starten fehlschlägt, ohne proaktiv oder dauerhaft die
               Protokollierung in Systemd auf der Fehlersuchstufe zu aktivieren, da diese viele Meldungen
               produziert. Ansonsten ist dies zum Modus normal äquivalent.

               Hinzugefügt in Version 257.

           Hinzugefügt in Version 254.

       SuccessExitStatus=
           Akzeptiert eine Liste von Exit-Statusdefinitionen, die als erfolgreiche Beendigung betrachtet werden,
           wenn sie vom Hauptdiensteprozess zurückgeliefert werden, zusätzlich zu dem normalen Exit-Status 0
           und, außer für Type=oneshot, den Signalen SIGHUP, SIGINT, SIGTERM und SIGPIPE.
           Exit-Statusdefinitionen können numerische Exit-Stati, Beendigungs-Statusnamen oder
           Beendigungssignalnamen, getrennt durch Leerzeichen, sein. Siehe den Abschnitt »PROZESS-EXIT-CODES« in
           systemd.exec(5) für eine Liste von Beendigungs-Statusnamen (für diese Einstellung sollte nur der Teil
           ohne den »EXIT_« oder »EX_«-Anfang verwandt werden). Siehe signal(7) für eine Liste der Signalnamen.

           Beachten Sie, dass diese Einstellung nicht die Zuordnung zwischen numerischen Exit-Stati und ihren
           Namen ändert, d.h. unabhängig von der Verwendung dieser Einstellung wird 0 immer »SUCCESS« (und in
           der Ausgabe von Werkzeugen typischerweise als »0/SUCCESS« angezeigt) und 1 »FAILURE« zugeordnet (und
           daher typischerweise als »1/FAILURE« angezeigt) wird, und so weiter. Dies steuert nur, was als
           Auswirkung auf diese Exit-Stati passiert, und wie sie zum Zustand des Dienstes als Ganzes
           weitergeleitet wird.

           Falls diese Option mehr als einmal auftaucht, wird die Liste der erfolgreichen Exit-Stati
           zusammengeführt. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird diese Liste
           zurückgesetzt und alle vorherigen Zuweisungen zu dieser Option haben keinen Effekt.

           Beispiel 1. Ein Dienst mit der Einstellung SuccessExitStatus=

               SuccessExitStatus=TEMPFAIL 250 SIGKILL

           Exit-Status 75 (TEMPFAIL), 250 und das Beendigungssignal wird SIGKILL als saubere Dienstebeendigung
           betrachtet.

           Beachten Sie: systemd-analyze exit-codes kann zur Auflistung der Exit-Stati und zur Übersetzung
           zwischen numerischen Code-Werten und Namen verwandt werden.

           Hinzugefügt in Version 189.

       RestartPreventExitStatus=
           Akzeptiert eine Liste von Exit-Statusdefinitionen, die automatische Diensteneustarts verhindern, wenn
           sie von dem Hauptdienstprozess zurückgeliefert werden, unabhängig von der mit Restart= konfigurierten
           Neustarteinstellung. Exit-Statusdefinitionen können numerische Beendigungsstati,
           Beendigungstatusnamen oder Beendigungssignalnamen, getrennt durch Leerzeichen, sein. Standardmäßig
           ist dies die leere Liste, so dass standardmäßig kein Exit-Status von der konfigurierten Neustartlogik
           ausgeschlossen ist.

           Falls diese Option mehr als einmal auftaucht, wird die Liste der Neustart-verhindernden Stati
           zusammengeführt. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird diese Liste
           zurückgesetzt und alle vorherigen Zuweisungen zu dieser Option haben keinen Effekt.

           Beachten Sie, dass diese Einstellung keine Auswirkung auf mittels ExecStartPre=, ExecStartPost=,
           ExecStop=, ExecStopPost= oder ExecReload= konfigurierte Prozesse hat, sondern nur auf den
           Hauptdiensteprozess, d.h. entweder den mittels ExecStart= aufgerufenen oder (abhängig von Type=,
           PIDFile=, …) den anderweitig konfigurierten Hauptprozess.

           Hinzugefügt in Version 189.

       RestartForceExitStatus=
           Akzeptiert eine Liste von Exit-Statusdefinitionen, die automatische Diensteneustarts erzwingen, wenn
           sie von dem Hauptdienstprozess zurückgeliefert werden, unabhängig von der mit Restart= konfigurierten
           Neustarteinstellung. Das Argumentenformat ist ähnlich zu RestartPreventExitStatus=.

           Beachten Sie, dass für Dienste Type=oneshot ein erfolgreicher Exit-Status sie am automatischen
           Neustarten hindern wird, unabhängig davon, ob die entsprechenden Exit-Stati in dieser Option
           aufgeführt sind oder nicht.

           Hinzugefügt in Version 215.

       RootDirectoryStartOnly=
           Akzeptiert ein logisches Argument. Falls true, wird das Wurzelverzeichnis, das mit der Option
           RootDirectory= (siehe systemd.exec(5) für weitere Informationen) konfiguriert ist, nur für den mit
           ExecStart= gestarteten Prozess angewandt und nicht für die verschiedenen anderen Befehle
           ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop= und ExecStopPost=. Falls false, wird die
           Einstellung auf alle konfigurierten Befehle auf die gleiche Art angewandt. Standardmäßig false.

       NonBlocking=
           Setzt den Schalter O_NONBLOCK für alle über Socket-basierte-Aktivierung übergebenen
           Dateideskriptoren. Falls true, wird bei allen Dateideskriptoren >= 3 (d.h. allen außer Stdin, Stdout,
           Stderr), ausschließlich solcher, die über die Dateideskriptorspeicherlogik (siehe
           FileDescriptorStoreMax= für Details) übergeben wurden, der Schalter O_NONBLOCK gesetzt und diese sind
           daher im nicht blockierenden Modus. Diese Option ist wie in systemd.socket(5) beschrieben nur im
           Zusammenhang von Socket-Units nützlich und hat auf Dateideskriptoren, die beispielsweise früher in
           dem Dateideskriptorspeicher gespeichert wurden, keinen Effekt. Standardmäßig false.

           Falls die gleiche Socket-Unit so konfiguriert wurde, dass sie an mehrere Dienste-Unites übergeben
           wird (mittels des nachfolgend beschriebenen Sockets=) und diese Dienste verschiedene Konfigurationen
           NonBlocking= haben, dann beachten Sie, dass der genaue Zustand von O_NONBLOCK von der Reihenfolge, in
           der diese Dienste aufgerufen werden, abhängt und sich möglicherweise ändert, nachdem der Dienste-Code
           bereits Besitz von dem Socket-Dateideskriptor genommen hat, einfach deshalb, weil der Zustand
           O_NONBLOCK von allen Dateideskriptoren, die ihn referenzieren, gemeinsam benutzt wird. Daher ist es
           wesentlich, dass alle Dienste, die den gleichen Socket verwenden, die gleiche Konfiguration
           NonBlocking= verwenden und diesen Schalter auch nicht in dem Dienste-Code ändern.

       NotifyAccess=
           Steuert den Zugriff auf das Statusbenachrichtigungs-Socket, wie es über den Aufruf sd_notify(3)
           erreichbar ist. Akzeptiert none (die Vorgabe), main, exec oder all. Falls none, werden keine
           Daemon-Statusaktualisierungen vom Diensteprozess akzeptiert, alle Statusaktualisierungsnachrichten
           werden ignoriert. Falls main, werden nur vom Hauptprozess des Dienstes gesandte
           Diensteaktualisierungen akzeptiert. Falls exec, werden nur Diensteaktualisierungen, die von einem der
           Haupt- oder Steuerprozesse, die aus einem der Befehle Exec*= stammen, gesandt wurden, akzeptiert.
           Falls all, werden alle Diensteaktualisierungen aus allen Mitgliedern der Control-Gruppe des Dienstes
           akzeptiert. Diese Option sollte gesetzt werden, um Zugriff auf das Benachrichtigungs-Socket zu
           öffnen, wenn Type=notify/Type=notify-reload oder WatchdogSec= verwandt wird (siehe oben). Falls jene
           Optionen verwandt werden, aber NotifyAccess= nicht konfiguriert ist, werden sie implizit auf main
           gesetzt.

           Beachten Sie, dass sd_notify()-Benachrichtigungen nur Units korrekt zugeordnet werden können, falls
           entweder der sendende Prozess noch zu dem Zeitpunkt vorhanden ist, zu dem PID 1 die Nachricht
           verarbeitet oder falls der sendende Prozess explizit vom Diensteverwalter laufzeitverfolgt ist.
           Letzteres ist der Fall, falls der Diensteverwalter den Prozess ursprünglich mit fork erzeugte, d.h.
           bei allen Prozessen, die auf NotifyAccess=main oder NotifyAccess=exec passen. Umgekehrt, falls ein
           Hilfsprozess einer Unit eine sd_notify()-Nachricht sendet und sich sofort beendet, könnte der
           Diensteverwalter nicht in der Lage sein, die Nachricht korrekt der Unit zuzuordnen und wird sie daher
           ignorieren, selbst falls NotifyAccess=all für sie gesetzt ist.

           Um daher alle Ressourcenwettläufe, die mit Nachschlagen von Units des Clients verknüpft sind, zu
           beseitigen und Benachrichtigungen Units richtig zuzuordnen, kann sd_notify_barrier() verwandt werden.
           Dieser Aufruf dient als Synchronisationspunkt und stellt sicher, dass alle Benachrichtigungen
           gesendete werden, bevor dieser Aufruf vom Diensteverwalter aufgenommen wird, wenn er erfolgreich
           zurückkehrt. Die Verwendung von sd_notify_barrier() wird für Clients benötigt, die nicht durch den
           Diensteverwalter aufgerufen werden, andernfalls ist dieser Synchronisationsmechanismus zur Zuordnung
           von Benachrichtigungen zu Units unnötig.

       Sockets=
           Gibt den Namen der Socket-Unit an, von der dieser Dienst Socket-Dateideskriptoren erben soll, wenn
           der Dienst gestartet wird. Normalerweise sollte es nicht notwendig sein, diese Einstellung zu
           verwenden, da alle Socket-Dateideskriptoren, deren Unit den gleichen Namen wie der Dienst benutzt
           (vorbehaltlich natürlich der verschiedenen Unit-Namensendungen), an den aufgerufenen Prozess
           übergeben werden.

           Beachten Sie, dass der gleiche Socket-Dateideskriptor simultan an mehrere Prozesse übergeben werden
           kann. Beachten Sie auch, dass ein anderer Dienst auf eingehenden Socket-Verkehr aktiviert werden kann
           als derjenige, der schließlich konfiguriert ist, den Socket-Dateideskriptor zu erben. Oder mit
           anderen Worten: Die Einstellung Service= von .socket-Units muss nicht auf das Inverse der Einstellung
           Sockets= von .service, auf die es sich bezieht, passen.

           Falls diese Option mehr als einmal auftaucht, wird die Liste der Socket-Units zusammengeführt.
           Beachten Sie, dass das Bereinigen der Liste (beispielsweise durch Zuweisung der leeren Zeichenkette
           zu dieser Option) nicht unterstützt wird, sobald die Option einmal gesetzt wurde.

       FileDescriptorStoreMax=
           Konfiguriert, wie viele Dateideskriptoren in dem Diensteverwalter für den Dienst mittels
           »FDSTORE=1«-Nachrichten von sd_pid_notify_with_fds(3) gespeichert werden können. Dies ist zur
           Implementierung von Diensten nützlich, die sich nach einer expliziten Anfrage oder einem Absturz ohne
           Zustandsverlust neu starten können. Alle offenen Sockets und andere Dateideskriptoren, die während
           des Neustarts nicht geschlossen werden sollen, können auf diese Art gespeichert werden. Der
           Anwendungszustand kann entweder in eine Datei in RuntimeDirectory= serialisiert oder in einem
           memfd_create(2)-Speicherdateideskriptor gespeichert werden. Standardmäßig 0, d.h. kein
           Dateideskriptor kann im Diensteverwalter gespeichert werden. Alle dem Diensteverwalter von einem
           bestimmten Dienst übergebenen Dateideskriptoren werden beim nächsten Neustart des Dienstes an den
           Hauptprozess des Dienstes zurückgegeben (siehe sd_listen_fds(3) für Details über das genaue verwandte
           Protokoll und die Reihenfolge, in der Dateideskriptoren übergeben werden). Alle an den
           Diensteverwalter übergebenen Dateideskriptoren werden automatisch geschlossen, wenn POLLHUP oder
           POLLERR auf ihnen gesehen wird oder wenn der Dienst vollständig gestoppt wird und kein Auftrag in der
           Warteschlange ist oder für ihn ausgeführt wird (letzteres kann mit FileDescriptorStorePreserve=
           angepasst werden, siehe unten). Falls diese Option verwandt wird, sollte NotifyAccess= (siehe oben)
           gesetzt werden, um Zugriff auf den von Systemd bereitgestellten Benachrichtigungs-Socket zu öffnen.
           Falls NotifyAccess= nicht gesetzt ist, wird es implizit auf main gesetzt.

           Der Befehl fdstore von systemd-analyze(1) kann zur Auflistung des aktuellen Inhalts des
           Dateideskriptorspeichers eines Dienstes verwandt werden.

           Beachten Sie, dass der Diensteverwalter die in dem Dateideskriptorspeicher gespeicherten
           Dateieskriptoren nur an Prozesse des eigenen Dienstes weitergeben wird, niemals an andere Clients
           mittels IPC oder ähnlichem. Allerdings erlaubt er nicht privilegierten Clients, die Liste der aktuell
           offenen Dateideskriptoren eines Dienstes abzufragen. Innerhalb der referenzierten Datein können daher
           sensible Daten platziert werden, sie sollten aber nicht an die Metadaten der gespeicherten
           Dateideskriptoren angehängt werden (z.B. Teil des Dateinamens sein).

           Falls diese Option auf einen von Null verschiedenen Wert gesetzt wird, dann wird die
           Umgebungsvariable $FDSTORE für von diesem Dienst aufgerufene Prozesse gesetzt. Siehe systemd.exec(5)
           zu Details.

           Für weitere Informationen über den Dateideskriptorspeicher siehe den Überblick über den
           Dateideskriptorspeicher[1].

           Hinzugefügt in Version 219.

       FileDescriptorStorePreserve=
           Akzeptiert entweder no, yes oder restart und steuert, wann der Dateideskriptorspeicher des Dienstes
           freigegeben werden soll (d.h. wann die enthaltenen Dateideskriptoren geschlossen werden sollen, falls
           vorhanden). Falls auf no gesetzt, wird der Dateideskriptorspeicher automatisch freigegeben, wenn der
           Dienst gestoppt wird; bei (der Vorgabe) restart wird er solange vorgehalten, wie die Unit weder
           inaktiv noch fehlgeschlagen ist oder ein Auftrag für den Dienst in der Warteschlange steht oder es
           erwartet wird, dass der Dienst neu gestartet wird. Falls yes, wird der Dateideskriptorspeicher
           vorgehalten, bis die Unit aus dem Speicher entfernt wird (d.h. nicht mehr referenziert wird und
           inaktiv ist). Letzteres ist nützlich, um Einträge in dem Dateideskriptorspeicher anzuheften, bis sich
           der Diensteverwalter beendet.

           Verwenden Sie systemctl clean --what=fdstore , um den Dateideskriptorspeicher explizit freizugeben.

           Hinzugefügt in Version 254.

       USBFunctionDescriptors=
           Konfiguriert den Ort einer Datei, die Deskriptoren für USB FunctionFS[2], für die Implementierung von
           USB-Gadget-Funktionen, enthält. Dies wird nur in Zusammenhang mit einer Socket-Unit mit
           konfiguriertem ListenUSBFunction= verwandt. Der Inhalt dieser Datei wird nach deren Öffnen in die
           Datei ep0 geschrieben.

           Hinzugefügt in Version 227.

       USBFunctionStrings=
           Konfiguriert den Ort einer Datei, die USB-FunctionFS-Zeichenketten enthält. Das Verhalten ist zu
           obiger USBFunctionDescriptors= ähnlich.

           Hinzugefügt in Version 227.

       OOMPolicy=
           Konfiguriert die Richtlinie für die Speichererschöpfungs- (OOM-)Beendigung für den Kernel und den
           OOM-Klller im Anwendungsraum systemd-oomd.service(8). Wenn unter Linux der Speicher so knapp wird,
           dass der Kernel Schwierigkeiten bekommt, Speicher für sich selbst zu reservieren, dann kann er sich
           entscheiden, laufende Prozesse zu beenden, um Speicher freizugeben und den Speicherdruck zu
           reduzieren. Beachten Sie, dass systemd-oomd.service(8) eine flexiblere Lösung ist, die zu verhindern
           versucht, dass Speichererschöpfungssituationen im Anwendungsraum auftreten, nicht nur im Kernel,
           indem versucht wird, Dienste früher zu beenden, bevor der Kernel agieren müsste.

           Diese Einstellung akzeptiert entweder continue, stop oder kill. Falls auf continue gesetzt und ein
           Prozess in der Unit vom OOM-Killer beendet wird, wird dies protokolliert aber die Unit läuft weiter.
           Falls auf stop gesetzt, wird das Ereignis protokolliert, aber die Unit wird sauber durch den
           Diensteverwalter beendet. Falls auf kill gesetzt und einer der Prozesse der Unit wird durch den
           OOM-Killer beendet, wird der Kernel angewiesen, auch alle verbleibenden Prozesse der Unit durch
           Setzen des Attributes memory.oom.group auf 1 durch den OOM-Killer zu beenden; siehe auch die
           Kernelseite Control-Gruppe v2[3].

           Standardmäßig der Wert, auf den die Einstellung DefaultOOMPolicy= in systemd-system.conf(5) gesetzt
           ist, außer bei Units, bei denen Delegate= eingeschaltet ist, wo die Vorgabe continue ist.

           Verwenden Sie die Einstellung OOMScoreAdjust=, um zu konfigurieren, ob Prozesse der Unit als
           bevorzugte oder weniger bevorzugte Kandidaten für Prozessbeendigungen durch die Logik des OOM-Killers
           von Linux betrachtet werden sollen. Siehe systemd.exec(5) für Details.

           Diese Einstellung gilt auch für systemd-oomd.service(8). Ähnlich wie beim vom Kernel durchgeführten
           Kernel-OOM-Tötungen bestimmt diese Einstellung den Zustand der Unit, nachdem systemd-oomd(8) eine ihr
           zugeordnete Cgroup beendet hat.

           Hinzugefügt in Version 243.

       OpenFile=
           Akzeptiert ein Argument der Form »Pfad[:dd-Name:Optionen], wobei:

           •   »Pfad« ein Pfad zu einer Datei oder einem AF_UNIX-Socket im Dateisystem ist;

           •   »dd-Name« ein Name ist, der dem Dateideskriptor zugeordnet wird; der Name darf ASCII-Zeichen
               enthalten, aber keine Steuerzeichen und »:« und darf höchsten 256 Zeichen lang sein; er ist
               optional und standardmäßig der Dateiname, falls nicht angegeben;

           •   »Optionen« ist eine Kommata-getrennte Liste von Zugriffsoptionen; mögliche Werte sind
               »read-only«, »append«, »truncate«, »graceful«; falls nicht festgelegt, werden Dateien im Modus rw
               geöffnet; falls »graceful« festgelegt ist, werden Fehler während des Öffnens von Dateien/Sockets
               ignoriert. Die mehrfache Angabe der gleichen Option wird als Fehler behandelt.

           Die Datei oder der Socket wird durch den Diensteverwalter geöffnet und der Dateideskriptor wird an
           den Dienst weitergegeben. Falls der Pfad ein Socket ist, wird connect() mit ihm aufgerufen. Siehe
           sd_listen_fds(3) für weitere Details, wie diese Dateideskriptoren erlangt werden.

           Diese Einstellung ist nützlich, um Diensten den Zugriff auf Dateien/Sockets zu erlauben, auf die sie
           selbst keinen Zugriff haben (da sie in einem anderen Einhängenamensraum laufen, über keine
           Privilegien verfügen …).

           Diese Einstellung kann mehrfach angegeben werden. In diesem Fall werden alle festgelegten Pfade
           geöffnet und die Dateideskriptoren an den Dienst übergeben. Falls die leere Zeichenkette zugewiesen
           wird, wird die gesamte vorher definierte Liste offener Dateien zurückgesetzt.

           Hinzugefügt in Version 253.

       ReloadSignal=
           Konfiguriert das UNIX-Prozessignal, das an den Hauptprozess des Dienstes gesandt werden soll, wenn
           dieser zum Neuladen seiner Konfiguration gebeten werden soll. Standardmäßig SIGHUP. Diese Option hat
           nur eine Auswirkung, wenn auch Type=notify-reload verwandt wird, siehe oben.

           Hinzugefügt in Version 253.

       Lesen Sie systemd.unit(5), systemd.exec(5) und systemd.kill(5) für weitere Einstellungen.

BEFEHLSZEILEN

       Dieser Abschnitt beschreibt die Auswertung der Befehlszeile und Variablen- und Kennzeichnerersetzung für
       die Optionen ExecStart=, ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop= ExecStopPost= und
       ExecCondition=.

       Durch mehrfache Verwendung der relevanten Einstellungen können mehrere Befehlszeilen angegeben werden.

       Der Schutz jeder Befehlszeile wird gemäß der im Abschnitt »Quoting« in systemd.syntax(7) beschriebenen
       Regeln entfernt. Der erste Eintrag wird der auszuführende Befehl und nachfolgende Einträge die Argumente.

       Diese Syntax ist von der Shell-Syntax inspiriert, aber nur die in den nachfolgenden Absätzen
       beschriebenen Metazeichen und Erweiterungen werden verstanden und die Expansion von Variablen
       unterscheidet sich. Insbesondere werden Umleitungen mittels »<«, »<<«, »>« und »>>«, Pipes mittels »|«,
       das Ausführen von Programmen im Hintergrund und andere Elemente der Shell-Syntax nicht unterstützt.

       Der auszuführende Befehl darf Leerzeichen enthalten, aber Steuerzeichen sind nicht erlaubt.

       Jedem Befehl kann eine Reihe von besonderen Zeichen vorangestellt werden:

       Tabelle 2. Besondere Präfixe für Programme
       ┌───────┬───────────────────────────────────────┐
       │PräfixEffekt                                │
       ├───────┼───────────────────────────────────────┤
       │"@"    │ Falls dem Programmpfad ein »@«        │
       │       │ vorangestellt wird, wird der zweite   │
       │       │ angegebene Parameter als argv[0]      │
       │       │ (statt des tatsächlichen Dateinamens) │
       │       │ an den ausgeführten Prozess           │
       │       │ übergeben, gefolgt von den weiteren   │
       │       │ angegebenen Argumenten.               │
       ├───────┼───────────────────────────────────────┤
       │"-"    │ Falls dem Programmpfad ein »-«        │
       │       │ vorangestellt ist, wird ein           │
       │       │ Exit-Code, der normalerweise als      │
       │       │ Fehlschlag betrachtet wird (d.h. ein  │
       │       │ von Null verschiedener Exit-Status    │
       │       │ oder ein abweichender Exit aufgrund   │
       │       │ eines Signals), aufgezeichnet, hat    │
       │       │ aber weiter keine Wirkung und wird    │
       │       │ äquivalent zum Erfolg betrachtet.     │
       ├───────┼───────────────────────────────────────┤
       │":"    │ Falls dem Programmpfad ein »:«        │
       │       │ vorangestellt ist, erfolgt keine      │
       │       │ Umgebungsvariablenersetzung (wie      │
       │       │ unterhalb dieser Tabelle              │
       │       │ beschrieben).                         │
       ├───────┼───────────────────────────────────────┤
       │"+"    │ Falls dem Programmpfad ein »+«        │
       │       │ vorangestellt ist, wird der Prozess   │
       │       │ mit vollen Privilegien ausgeführt. In │
       │       │ diesem Modus werden die mit User=,    │
       │       │ Group=, CapabilityBoundingSet= oder   │
       │       │ den verschiedenen                     │
       │       │ Dateisystemnamensraumoptionen (wie    │
       │       │ PrivateDevices=, PrivateTmp=)         │
       │       │ konfigurierten                        │
       │       │ Privilegienbeschränkungen für die     │
       │       │ aufgerufene Befehlszeile nicht        │
       │       │ angewandt (betreffen aber weiterhin   │
       │       │ jede andere ExecStart=-, ExecStop=-,  │
       │       │ … -Zeilen). Beachten Sie allerdings,  │
       │       │ dass dies nicht die Optionen umgehen  │
       │       │ wird, die auf die gesamte             │
       │       │ Control-Gruppe wirken, wie            │
       │       │ DevicePolicy=, siehe                  │
       │       │ systemd.resource-control(5) für die   │
       │       │ vollständige Liste.                   │
       ├───────┼───────────────────────────────────────┤
       │"!"    │ Ähnlich zum oben besprochenen Zeichen │
       │       │ »+« ermöglicht dieser den Aufruf von  │
       │       │ Befehlszeilen mit erweiterten         │
       │       │ Privilegien. Anders als »+« ändert    │
       │       │ das Zeichen »!« exklusiv den Effekt   │
       │       │ von User=, Group= und                 │
       │       │ SupplementaryGroups=, d.h. nur die    │
       │       │ Absätze, die Benutzer- und            │
       │       │ Gruppenberechtigungen betreffen.      │
       │       │ Beachten Sie, dass diese Einstellung  │
       │       │ mit DynamicUser= kombiniert werden    │
       │       │ darf, womit ein dynamisches           │
       │       │ Benutzer-/Gruppenpaar vor dem Aufruf  │
       │       │ des Befehls reserviert wird, aber die │
       │       │ Änderung der Berechtigungen dem       │
       │       │ ausgeführten Prozess selbst           │
       │       │ überlassen bleibt.                    │
       ├───────┼───────────────────────────────────────┤
       │"!!"   │ Dies ist sehr ähnlich zum             │
       │       │ Voranstellen von »!«, es wirkt        │
       │       │ allerdings nur auf Systemen, denen    │
       │       │ die Unterstützung für                 │
       │       │ Umgebungsprozess-Capabilities fehlt,  │
       │       │ d.h. ohne Unterstützung für           │
       │       │ AmbientCapabilities=. Es ist für      │
       │       │ Unit-Dateien gedacht, die von         │
       │       │ Umgebungs-Capabilities profitieren,   │
       │       │ um wann immer möglich Prozesse mit    │
       │       │ minimalen Privilegien auszuführen,    │
       │       │ und gleichzeitig kompatibel zu        │
       │       │ Systemen bleiben sollen, denen die    │
       │       │ Unterstützung für                     │
       │       │ Umgebungs-Capabilities fehlt.         │
       │       │ Beachten Sie, dass alle               │
       │       │ konfigurierten Absätze                │
       │       │ SystemCallFilter= und                 │
       │       │ CapabilityBoundingSet= implizit       │
       │       │ modifiziert werden, wenn »!!«         │
       │       │ verwandt wird und erkannt wird, dass  │
       │       │ dem System die Unterstützung für      │
       │       │ Umgebungs-Capabilities fehlt, um zu   │
       │       │ erlauben, dass erzeugte Prozesse      │
       │       │ Berechtigungen und Capabilities       │
       │       │ selbst abgeben können, selbst falls   │
       │       │ konfiguriert wurde, dass dies nicht   │
       │       │ erlaubt ist. Desweiteren wird         │
       │       │ AmbientCapabilities= übersprungen und │
       │       │ nicht angewandt, falls dies           │
       │       │ vorangestellt ist und ein System      │
       │       │ erkannt wird, dem die Unterstützung   │
       │       │ für Umgebungs-Capabilities fehlt. Auf │
       │       │ Systemen, die Umgebungs-Capabilities  │
       │       │ unterstützen, hat »!!« keinen Effekt  │
       │       │ und ist redundant.                    │
       └───────┴───────────────────────────────────────┘

       »@«, »-«, »:« und eines aus »+«/»!«/»!!« können zusammen verwandt werden und in jeder Reihenfolge
       auftauchen. Allerdings darf nur einer von »+«, »!«, »!!« gleichzeitig benutzt werden.

       Für jeden Befehl muss das erste Argument entweder ein absoluter Pfad zu einem Programm oder ein einfacher
       Dateiname ohne Schrägstriche sein. Falls der Befehl kein kompletter (absoluter) Pfad ist, wird er mittels
       eines festen, zum Zeitpunkt der Kompilierung bestimmten Suchpfades zu einem kompletten Pfad aufgelöst.
       Suchverzeichnisse sind unter anderem /usr/local/bin/, /usr/bin/ und ihre sbin/-Gegenstücke (nur auf
       Systemen, die getrennte bin/ und sbin/ verwenden). Es ist daher sicher, nur den Programmnamen zu
       verwenden, falls das Programm sich in einem der »Standard«-Verzeichnisse befindet. Für andere Fälle muss
       ein absoluter Pfad verwandt werden. Tipp: Dieser Suchpfad kann mit systemd-path search-binaries-default
       abgefragt werden.

       Die Befehlszeile akzeptiert wie in systemd.unit(5) beschrieben »%s«-Kennzeichner.

       Ein Argument, das nur aus »;« besteht, muss maskiert werden, d.h. als »\;« angegeben werden.

       Grundlegende Umgebungsvariablenersetzung wird unterstützt. Verwenden Sie auf der Befehlszeile »${FOO}«
       als Teil des Worts oder als einzelnes Wort, das dann gelöscht und genau durch den Wert der
       Umgebungsvariablen (falls vorhanden), einschließlich sämtlichen darin enthaltenen Leerraums, ersetzt und
       immer genau zu einem einzelnen Argument wird. Verwenden Sie »$FOO« als ein separates Wort auf der
       Befehlszeile, das durch den Wert der Umgebungsvariablen, getrennt an den Leerraumzeichen, ersetzt wird
       und zu Null oder mehr Argumenten führt. Für diese Art von Expansion werden Anführungszeichen beim Trennen
       in Wörter berücksichtigt und anschließend entfernt.

       Beispiel:

           Environment="EINS=eins" 'ZWEI=zwei zwei'
           ExecStart=echo $EINS $ZWEI ${ZWEI}

       Dies führt /bin/echo mit vier Argumenten aus: »eins«, »zwei«, »zwei« und »zwei zwei«.

       Beispiel:

           Environment=EINS='eins' "ZWEI='zwei zwei' auch" DREI=
           ExecStart=/bin/echo ${EINS} ${ZWEI} ${DREI}
           ExecStart=/bin/echo $EINS $ZWEI $DREI

       Dies führt dazu, dass /bin/echo zweimal aufgerufen wird, das erste Mal mit den Argumenten »'eins'«,
       »'zwei zwei' auch« »« und das zweite Mal mit den Argumenten »eins«, »zwei zwei«, »auch«.

       Um ein wörtliches Dollarzeichen zu übergeben, verwenden Sie »$$«. Variablen, deren Wert zum
       Expansionszeitpunkt nicht bekannt ist, werden als leere Zeichenkette behandelt. Beachten Sie, dass das
       erste Argument (d.h. das auszuführende Programm) keine Variable sein darf.

       Variablen, die auf diese Art verwandt werden, können mittels Environment= und EnvironmentFile= definiert
       werden. Zusätzlich können Variablen, die im Abschnitt »Umgebungsvariablen in erzeugten Prozessen« in
       systemd.exec(5), die als »statische Konfiguration« betrachtet werden, verwandt werden (dies schließt
       beispielsweise $USER, aber nicht $TERM ein).

       Beachten Sie, dass Shell-Befehlszeilen nicht direkt unterstützt werden. Falls Shell-Befehlszeilen
       verwandt werden sollen, müssen sie explizit an eine Art von Shell-Implementierung übergeben werden.
       Beispiel:

           ExecStart=sh -c 'dmesg | tac'

       Beispiel:

           ExecStart=echo Eins
           ExecStart=echo "Zwei Zwei"

       Dies wird echo zwei Mal ausführen, jedes Mal mit einem Argument: »eins« bzw. »zwei zwei«. Da zwei Befehle
       angegeben sind, muss Type=oneshot verwandt werden.

       Beispiel:

           Type=oneshot
           ExecStart=:echo $USER
           ExecStart=-false
           ExecStart=+:@true $TEST

       Dies wird /usr/bin/echo mit dem wörtlichen Argument »$USER« (»:« verhindert die Variablenexpansion) und
       /usr/bin/false (der Rückgabewert wird ignoriert, da »-« das Prüfen des Rückgabewerts unterdrücken wird)
       und /usr/bin/true (mit erhöhten Privilegien, mit »$TEST« als argv[0]) ausführen.

       Beispiel:

           ExecStart=echo / >/dev/null & \; \
           ls

       Dies wird echo mit fünf Argumenten ausführen: »/«, »>/dev/null«, »&«, »;« und »ls«.

BEISPIELE

       Beispiel 3. Einfacher Dienst

       Die folgende Unit-Datei erstellt einen Dienst, der /usr/sbin/foo-daemon ausführt. Da kein Type= angegeben
       ist, wird die Vorgabe Type=simple angenommen. Systemd wird annehmen, dass die Unit sofort nach Beginn der
       Ausführung des Programmes gestartet werden soll.

           [Unit]
           Description=Foo

           [Service]
           ExecStart=/usr/sbin/foo-daemon

           [Install]
           WantedBy=multi-user.target

       Beachten Sie, dass Systemd hier annimmt, dass der durch Systemd gestartete Prozess läuft, bis der Dienst
       beendet wird. Falls das Programm sich selbst zum Daemon macht (d.h. Fork ausführt), verwenden Sie bitte
       stattdessen Type=forking.

       Da kein ExecStop= angegeben wurde, wird Systemd SIGTERM an alle von diesem Dienst gestarteten Prozesse
       senden und nach einer Zeitüberschreitung auch SIGKILL. Dieses Verhalten kann verändert werden, siehe
       systemd.kill(5) für Details.

       Beachten Sie, dass dieser Unit-Typ keine Art von Benachrichtigung, wenn der Dienst seine Initialisierung
       abgeschlossen hat, enthält. Dafür sollten Sie andere Unit-Typen, wie Type=notify/Type=notify-reload,
       falls der Dienst das Benachrichtigungsprotokoll von Systemd versteht, Type=forking, falls der Dienst sich
       selbst in den Hintergrund bringen kann oder Type=dbus, falls der Dienst einen DBus-Namen erlangt, sobald
       die Initialisierung abgeschlossen ist, in Betracht ziehen. Siehe unten.

       Beispiel 4. Oneshot-Dienst

       Manchmal sollen Units einfach eine Aktion ausführen, ohne aktive Prozesse zu behalten, wie beispielsweise
       eine Dateisystemüberprüfung oder eine Aufräumaktion beim Systemstart. Dafür existiert Type=oneshot. Units
       dieser Art werden warten, bis der festgelegte Prozess sich beendet hat und dann auf einen inaktiven
       Status zurückfallen. Die folgende Unit wird eine Aufräumaktion durchführen:

           [Unit]
           Description=Bereinigung alter Foo-Daten

           [Service]
           Type=oneshot
           ExecStart=/usr/sbin/foo-cleanup

           [Install]
           WantedBy=multi-user.target

       Beachten Sie, dass Systemd die Unit im Status »starting« betrachten wird, bis sich das Programm beendet
       hat, daher werden Ordnungsabhängigkeiten auf die Beendigung des Programms warten, bevor sie sich selbst
       starten. Die Unit wird zum Zustand »inactive« nach dem Abschluss der Ausführung zurückkehren und niemals
       den Zustand »active« erreichen. Das bedeutet, dass eine weitere Anfrage, die Unit zu starten, die Aktion
       erneut ausführen wird.

       Nur Units mit Type=oneshot dürfen mehr als ein ExecStart= festgelegt haben. Für Units mit mehreren
       Befehlen (Type=oneshot) werden alle Befehle erneut ausgeführt.

       Für Type=oneshot sind Restart=always und Restart=on-success nicht erlaubt.

       Beispiel 5. Beendbarer Oneshot-Dienst

       Ähnlich zum Oneshot-Dienst gibt es manchmal Units, die ein Programm ausführen müssen, um etwas
       einzurichten, und dann ein anderes, um es herunterzufahren, aber es bleibt kein Prozess aktiv, während
       diese als »started« betrachtet werden. Netzwerkkonfiguration kann manchmal in diese Kategorie fallen. Ein
       anderer Anwendungsfall ist, falls ein Oneshot-Dienst nicht jedesmal, wenn er als Abhängigkeit
       hereingezogen wird, ausgeführt werden soll, sondern nur beim ersten Mal.

       Dafür kennt Systemd die Einstellung RemainAfterExit=yes, die dazu führt, dass Systemd die Unit als aktiv
       betrachtet, falls die Startaktion sich erfolgreich beendet hat. Diese Anweisung kann mit allen Typen
       verwandt werden, ist aber mit Type=oneshot und Type=simple am nützlichsten. Mit Type=oneshot wird Systemd
       warten, bis die Startaktion abgeschlossen ist, bevor es die Unit als aktiv betrachtet, daher starten
       Abhängigkeiten erst nachdem die Startaktion erfolgreich war. Mit Type=simple werden die Abhängigkeiten
       sofort nach dem Absetzen der Startaktion gestartet. Die nachfolgende Unit stellt ein Beispiel für eine
       einfache statische Firewall bereit.

           [Unit]
           Description=Einfache Firewall

           [Service]
           Type=oneshot
           RemainAfterExit=yes
           ExecStart=/usr/local/sbin/simple-firewall-start
           ExecStop=/usr/local/sbin/simple-firewall-stop

           [Install]
           WantedBy=multi-user.target

       Da die Unit als laufend betrachtet wird, nachdem sich die Start-Aktion beendet hat, wird der Aufruf von
       systemctl start auf dieser Unit zu keiner Aktion führen.

       Beispiel 6. Traditioneller forkender Dienst

       Viele traditionelle Daemons/Dienste bringen sich selbst in den Hintergrund (d.h. forken, daemonisieren
       sich), wenn sie starten. Setzen Sie Type=forking in der Unit-Datei des Dienstes, um diesen Betriebsmodus
       zu unterstützen. Systemd wird den Dienst im Prozess der Initialisierung betrachten, während das
       ursprüngliche Programm noch läuft. Sobald es sich erfolgreich beendet und mindestens ein Prozess
       verbleibt (und RemainAfterExit=no), wird der Dienst als gestartet betrachtet.

       Oft besteht ein traditioneller Daemon nur aus einem Prozess. Daher wird Systemd diesen Prozess als den
       Hauptprozess des Dienstes betrachten, falls nur ein Prozess nach Beendigung des ursprünglichen Prozesses
       verbleibt. In diesem Fall wird die Variable $MAINPID in ExecReload=, ExecStop= usw. verfügbar sein.

       Falls mehr als ein Prozess verbleibt, wird Systemd nicht in der Lage sein, den Hauptprozess zu bestimmen
       und wird daher annehmen, dass es keinen gibt. In diesem Fall wird $MAINPID nicht auf etwas expandiert.
       Falls allerdings der Prozess entscheidet, eine traditionelle PID-Datei zu schreiben, wird Systemd in der
       Lage sein, die Haupt-PID von dort zu bestimmen. Bitte setzen Sie PIDFile= entsprechend. Beachten Sie,
       dass der Daemon diese Datei schreiben sollte, bevor er seine Initialisierung abschließt. Andernfalls
       könnte Systemd versuchen, die Datei zu lesen, bevor sie existiert.

       Das folgende Beispiel zeigt einen einfachen Daemon, der forkt und einfach einen Prozess im Hintergrund
       startet:

           [Unit]
           Description=Ein einfacher Daemon

           [Service]
           Type=forking
           ExecStart=/usr/sbin/my-simple-daemon -d

           [Install]
           WantedBy=multi-user.target

       Bitte lesen Sie systemd.kill(5) für Details, wie Sie die Art, wie Systemd die Dienste beendet,
       beeinflussen können.

       Beispiel 7. DBus-Dienste

       Für Dienste, die einen Namen auf dem DBus-Systembus erlangen, verwenden Sie Type=dbus und setzen BusName=
       entsprechend. Der Dienste sollte nicht forken (daemonisieren). Systemd wird den Dienst als initialisiert
       betrachten, sobald der Name auf dem Systembus erlangt wurde. Das folgende Beispiel zeigt einen typischen
       DBus-Dienst:

           [Unit]
           Description=Einfacher DBus-Dienst

           [Service]
           Type=dbus
           BusName=org.example.simple-dbus-service
           ExecStart=/usr/sbin/simple-dbus-service

           [Install]
           WantedBy=multi-user.target

       Für Bus-aktivierbare Dienste nehmen Sie keinen Abschnitt »[Install]« in der Systemd-Dienstedatei auf,
       sondern verwenden die Option SystemdService= in der entsprechenden DBus-Dienstedatei, beispielsweise
       (/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service):

           [D-BUS Service]
           Name=org.example.simple-dbus-service
           Exec=/usr/sbin/simple-dbus-service
           User=root
           SystemdService=simple-dbus-service.service

       Bitte lesen Sie systemd.kill(5) für Details, wie Sie die Art, wie Systemd die Dienste beendet,
       beeinflussen können.

       Beispiel 8. Dienste, die Systemd über ihre Initialisierung benachrichtigen

       Type=simple-Dienste sind wirklich einfach zu schreiben, haben aber den großen Nachteil, dass Systemd
       nicht feststellen kann, wann die Initialisierung des gegebenen Dienstes abgeschlossen ist. Aus diesem
       Grund unterstützt Systemd ein einfaches Benachrichtigungsprotokoll, das es Daemons erlaubt, Systemd
       darüber in Kenntnis zu setzen, dass sie initialisiert sind. Verwenden Sie dafür Type=notify oder
       Type=notify-reload. Eine typische Dienste-Datei für solch einen Daemon sähe wie folgt aus:

           [Unit]
           Description=Einfacher Benachrichtigungsdienst

           [Service]
           Type=notify-reload
           ExecStart=/usr/sbin/simple-notifying-service

           [Install]
           WantedBy=multi-user.target

       Beachten Sie, dass der Daemon das Benachrichtigungsprotokoll von Systemd unterstützen muss, da ansonsten
       Systemd glauben wird, dass der Dienst noch nicht gestartet wurde und ihn nach einer Zeitüberschreitung
       töten wird. Für ein Beispiel, wie transparent ein Daemon aktualisiert wird, um dieses Protokoll zu
       unterstützen, schauen Sie in sd_notify(3). Systemd wird die Unit im Zustand »starting« betrachten, bis
       eine Bereitschaftsbenachrichtigung angekommen ist.

       Bitte lesen Sie systemd.kill(5) für Details, wie Sie die Art, wie Systemd die Dienste beendet,
       beeinflussen können.

       Um Code-Duplizierung zu vermeiden, sollte wenn möglich vorzugsweise sd_notify(3) verwandt werden,
       insbesondere wenn auch andere durch libsystemd(3) bereitgestellte APIs verwandt werden. Beachten Sie
       aber, dass das Benachrichtigungsprotokoll sehr einfach und gemäß dem Schnittstellen-Portabilitäts- und
       -Stabilitätsversprechen[4] garantiert stabil ist, so dass es durch Dienste ohne externe Abhängigkeiten
       reimplementiert werden kann. Für ein in sich geschlossenes Beispiel siehe sd_notify(3).

SIEHE AUCH

       systemd(1), systemctl(1), systemd-system.conf(5), systemd.unit(5), systemd.exec(5),
       systemd.resource-control(5), systemd.kill(5), systemd.directives(7), systemd-run(1)

ANMERKUNGEN

        1. Dateideskriptorspeicher
           https://systemd.io/FILE_DESCRIPTOR_STORE

        2. USB FunctionFS
           https://docs.kernel.org/usb/functionfs.html

        3. Control-Gruppe v2
           https://docs.kernel.org/admin-guide/cgroup-v2.html

        4. Schnittstellenportabilitäts- und -stabilitätszusage
           https://systemd.io/PORTABILITY_AND_STABILITY/

Ü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 Copyright-Bedingungen. Es wird KEINE
       HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die
       Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.