systemd.service

SYSTEMD.SERVICE(5)               systemd.service              SYSTEMD.SERVICE(5)



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 ein Dienst unter einem bestimmten Namen angefordert wird, aber
       keine Unit-Konfigurationsdatei gefunden wird, schaut Systemd nach einem
       SysV-Init-Skript mit dem gleichen Namen (ohne die Endung .service) und
       erstellt dynamisch eine Dienste-Unit aus diesem Skript. Dies ist zur
       Kompatibilität mit SysV nützlich. Beachten Sie, dass diese Kompatibilität
       recht umfangreich, aber nicht 100% ist. Für Details über die
       Inkompatibilitäten, siehe das Dokument Inkompatibilitäten mit SysV[1].

       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
       Dienstedateien 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 Prozessstarttyp für diese Dienste-Unit. Einer aus
           simple, exec, forking, oneshot, dbus, notify oder idle:

           •   Falls auf simple gesetzt ist (die Vorgabe, falls ExecStart=
               festgelegt ist, aber weder Type= noch BusName= gesetzt sind),
               wird der Diensteverwalter die Unit als gestartet betrachten,
               sobald der Hauptdiensteprozess mittels »fork« erzeugt wurde. 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 Diensteprogramm fehlt).

           •   Falls auf forking gesetzt, 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. Systemd wird mit dem Starten von
               nachfolgenden Units fortfahren, sobald 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= festgelegt 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.

           •   Das Verhalten von dbus ist ähnlich zu simple, allerdings wird
               erwartet, dass der Dienst einen Namen auf dem D-Bus-Bus erlangt,
               wie dies durch BusName= konfiguriert ist. Systemd wird mit dem
               Starten nachfolgender Units fortfahren, nachdem der D-Bus-Busname
               erlangt wurde. Dienste-Units, bei denen diese Option konfiguriert
               ist, erhalten implizit eine Abhängigkeit auf die Unit
               dbus.socket. Dieser Typ ist die Vorgabe, falls BusName=
               festgelegt ist.

           •   Das Verhalten von notify ist ähnlich zu exec, allerdings wird
               erwartet, dass der Dienst mittels sd_notify(3) oder einem
               Äquivalent eine 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.

           •   Das Verhalten von idle ist sehr ähnlich zu simple; allerdings
               wird die tatsächliche Ausführung des Diensteprogramms 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 Diensteprogramm auf
               jeden Fall ausgeführt wird.

           Es wird im Allgemeinen empfohlen, Type=simple wann immer möglich für
           langlaufende Dienste zu verwenden, da es die einfachste und
           schnellste Option ist. Da dieser Dienstetyp allerdings Fehler beim
           Starten nicht weiterleitet und keine Ordnung von anderen Units nach
           Abschluss der Initialisierung des Dienstes 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 oder dbus (Letzteres
           nur in dem Fall, in dem der Dienst eine D-Bus-Schnittstelle
           bereitstellt) die bevorzugten Optionen, da sie dem Diensteprogramm
           genau einzuplanen erlauben, wann der Dienst als erfolgreich gestartet
           betrachtet werden soll und wann mit den nachfolgenden Units
           fortgefahren werden soll. Der Dienstetyp notify benötigt 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 Startprotokoll traditioneller
           UNIX-Dienste. Schließlich kann exec eine Option für die Fälle sein,
           in denen es ausreicht, sicherzustellen, dass das Diensteprogramm
           aufgerufen wurde und in denen das Diensteprogramm selbst keine oder
           nur sehr geringe Initialisierungen durchführt (und diese
           höchstwahrscheinlich erfolgreich sind). Beachten Sie, dass die
           Verwendung aller von simple verschiedenen Typen möglicherweise den
           Systemstartprozess verzögert, da der Diensteverwalter darauf warten
           muss, dass die Diensteinitialisierung abgeschlossen ist. Es wird
           daher empfohlen, nicht unnötigerweise von simple verschiedene Typen
           zu verwenden. (Es wird im Allgemeinen auch nicht empfohlen, idle oder
           oneshot für langlaufende Dienste zu verwenden.)

       RemainAfterExit=
           Akzeptiert einen logischen Wert, der festlegt, 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 festlegt, 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 festgelegte 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.

       BusName=
           Akzeptiert einen D-Bus-Busnamen, unter dem dieser Dienst erreichbar
           ist. Die Option ist für Dienste, bei denen Type= auf dbus gesetzt
           ist, verpflichtend.

       ExecStart=
           Befehle mit ihren Argumenten, die ausgeführt werden, wenn dieser
           Dienst gestartet wird. Der Wert wird gemäß den unten beschriebenen
           Regeln in Null oder mehrere Befehlszeilen aufgeteilt (siehe Abschnitt
           »Befehlszeilen« unten).

           Es muss genau ein Befehl angegeben werden, außer Type= ist auf
           oneshot gesetzt. Wenn Type=oneshot verwandt wird, dürfen Null oder
           mehr Befehle festgelegt werden. Befehle können durch Angabe mehrerer
           Befehlszeilen in der gleichen Anweisung angegeben werden oder
           alternativ kann diese Anweisung mehr als einmal mit der gleichen
           Wirkung festgelegt werden. 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= festgelegt 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.)

           Für jeden der festgelegten Befehle muss das erste Argument entweder
           ein absoluter Pfad zu einem Programm oder ein einfacher Dateiname
           ohne Schrägstriche sein. Optional kann dem Dateinamen eine Reihe von
           besonderen Zeichen vorangestellt werden:

           Tabelle 1. Besondere Präfixe für Programme
           ┌───────┬───────────────────────────────┐
           │Präfix Effekt                        │
           ├───────┼───────────────────────────────┤
           │"@"    │ Falls dem Programmpfad ein    │
           │       │ »@« vorangestellt wird,       │
           │       │ wird der zweite festgelegte   │
           │       │ Parameter als »argv[0]«       │
           │       │ (statt des tatsächlichen      │
           │       │ Dateinamens) an den           │
           │       │ ausgeführten Prozess          │
           │       │ übergeben, gefolgt von den    │
           │       │ weiteren festgelegten         │
           │       │ 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 in dem nachfolgenden     │
           │       │ Abschnitt »Befehlszeilen«     │
           │       │ 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).                     │
           ├───────┼───────────────────────────────┤
           │"!"    │ Ä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. Beachten Sie, dass
           diese Zeichen auch den anderen Befehlzeileneinstellungen
           vorangestellt werden dürfen, d.h. ExecStartPre=, ExecStartPost=,
           ExecReload=, ExecStop= und ExecStopPost=.

           Falls mehr als ein Befehl festgelegt 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=, außer dass
           mehrere Befehlszeilen erlaubt sind und die Befehle seriell einer nach
           dem anderen ausgeführt werden.

           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 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 dem Befehl/den Befehlen in ExecStartPre=
           gestartet werden. Syntax ist identisch zu ExecStart=, außer dass
           mehrere Befehlszeilen erlaubt sind und die Befehle seriell einer nach
           dem anderen ausgeführt werden.

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

       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. Festlegungs- 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 Senden eines
           Signals (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 nachdrücklich empfohlen, 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 festgelegt
           ist, werden die Prozesse durch Senden des in KillSignal= oder
           RestartKillSignal= festgelegten Signals beendet, wenn das Beenden
           eines Dienstes angefragt wird. Festlegungs- 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.
           Festlegungs- 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 alle Prozesse des Dienstes
           bereits beendet wurden, 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.

       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 DefaultTimeoutStartSec= aus der
           Verwalterkonfigurationsdatei, 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 »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)).

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

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

       TimeoutSec=
           Eine Kurzform, um sowohl TimeoutStartSec= als auch TimeoutStopSec=
           auf den festgelegten 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.

       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. Übergeben Sie »infinity« (die
           Vorgabe), um keine Laufzeitbeschränkung zu konfigurieren.

           Falls ein Dienst vom Type=notify »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)).

       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 no, on-success, on-failure, on-abnormal, on-watchdog,
           on-abort oder always. Falls auf no (die Vorgabe) gesetzt, wird der
           Dienst nicht neu gestartet. Falls auf on-success gesetzt, wird er nur
           neu gestartet, wenn sich der Diensteprozess sauber beendet. In diesem
           Kontext bedeutet das saubere Beenden einen Exit-Code 0 oder eines der
           Signale SIGHUP, SIGINT, SIGTERM oder SIGPIPE und zusätzlich in
           SuccessExitStatus= festgelegte 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.

           Tabelle 2. Exit-Gründe und der Effekt der Einstellung Restart=
           darauf

           ┌────────────────────────────────┬────┬────────┬────────────┬────────────┬─────────────┬──────────┬─────────────┐
           │Neustart-Einstellung/Exit-Grund no always on-success on-failure on-abnormal on-abort on-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. Ein neugestarteter
           Dienst tritt in den Fehlerzustand nur ein, nachdem die
           Startratenbegrenzungen erreicht wurden.

           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.

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

       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
           entweder numerische Exit-Codes 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. Beispiel:

               RestartPreventExitStatus=1 6 SIGABRT

           Dies stellt sicher, dass die Exit-Codes 1 und 6 und das
           Beendigungssignal SIGABRT nicht zu einem automatischen
           Diensteneustart führen. Wenn diese Option mehr als einmal auftaucht,
           werden die Neustart-verhindernden Status 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.

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

       RootDirectoryStartOnly=
           Akzeptiert ein logisches Argument. Falls wahr, 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 falsch, wird die
           Einstellung auf alle konfigurierten Befehle auf die gleiche Art
           angewandt. Standardmäßig falsch.

       NonBlocking=
           Setzt den Schalter O_NONBLOCK für alle über
           Socket-basierte-Aktivierung übergebenen Dateideskriptoren. Falls
           wahr, 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 falsch.

       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 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=
           Legt den Namen der Socket-Unit fest, 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 /run serialisiert werden oder besser 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. 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.

       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.

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

       OOMPolicy=
           Configure the Out-Of-Memory (OOM) killer policy. On Linux, when
           memory becomes scarce the kernel might decide to kill a running
           process in order to free up memory and reduce memory pressure. This
           setting takes one of continue, stop or kill. If set to continue and a
           process of the service is killed by the kernel's OOM killer this is
           logged but the service continues running. If set to stop the event is
           logged but the service is terminated cleanly by the service manager.
           If set to kill and one of the service's processes is killed by the
           OOM killer the kernel is instructed to kill all remaining processes
           of the service, too. Defaults to the setting DefaultOOMPolicy= in
           systemd-system.conf(5)  is set to, except for services where
           Delegate= is turned on, where it defaults to continue.

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

       Lesen Sie 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= und ExecStopPost=.

       Mehrere Befehlszeilen können in eine einzelne Anweisung zusammengefasst
       werden, indem sie mit Semikola (die als separate Wörter übergeben werden
       müssen) getrennt werden. Einzelne Semikola können als »\;« maskiert
       werden.

       Jede Befehlszeile wird bei Leerraumzeichen aufgeteilt, wobei das erste
       Objekt der auszuführende Befehl und die nachfolgenden Objekte dessen
       Argumente sind. Doppelte ("…") und einfache Anführungszeichen ('…')
       können zum Einhüllen eines ganzen Objekts verwandt werden (das öffnende
       Anführungszeichen darf nur am Anfang oder nach Leerraumzeichen, die nicht
       in Anführungszeichen sind, erscheinen und dem schließenden
       Anführungszeichen muss Leerraumzeichen oder das Zeilenende folgen), dabei
       wird alles bis zum nächsten passenden Anführungszeichen Teil des gleichen
       Arguments. Die Anführungszeichen selbst werden entfernt. C-artige
       Maskierungen werden auch unterstützt. Die nachfolgende Tabelle enthält
       die Liste der bekannten Maskiermuster. Nur Maskiermuster, die auf die
       Syntax in der Tabelle passen, sind erlaubt; andere Muster können in der
       Zukunft hinzugefügt werden und unbekannte Muster führen zu einer Warnung.
       Insbesondere sollten alle Rückwärtsschrägstriche verdoppelt werden.
       Schließlich kann ein abschließender Rückwärtsschrägstrich (»\«) zum
       Zusammenführen von Zeilen verwandt werden.

       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.

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

       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.

       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/, /bin/ auf Systemen, die getrennte
       Verzeichnisse /usr/bin/ und /bin/ verwenden, und ihre sbin/-Gegenstücke
       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. Es wird empfohlen, einen absoluten Pfad
       zu verwenden, um Mehrdeutigkeiten zu vermeiden. Tipp: Dieser Suchpfad
       kann mit systemd-path search-binaries-default abgefragt werden.

       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 ; echo "zwei zwei"

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

       Beispiel:

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

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

       Tabelle 3. In Befehlszeilen und Umgebungsvariablen unterstützte
       C-Maskierungen

       ┌─────────┬─────────────────────────────┐
       │Wortsinn Tatsächlicher Wert          │
       ├─────────┼─────────────────────────────┤
       │"\a"     Glockenton                  │
       ├─────────┼─────────────────────────────┤
       │"\b"     Rückschritt (»backspace«)   │
       ├─────────┼─────────────────────────────┤
       │"\f"     Seitenvorschub              │
       ├─────────┼─────────────────────────────┤
       │"\n"     Zeilenumbruch               │
       ├─────────┼─────────────────────────────┤
       │"\r"     Wagenrücklauf               │
       ├─────────┼─────────────────────────────┤
       │"\t"     Tabulator                   │
       ├─────────┼─────────────────────────────┤
       │"\v"     Vertikaler Tabulator        │
       ├─────────┼─────────────────────────────┤
       │"\\"     Rückschrägstrich            │
       │         │ (»backslash«)               │
       ├─────────┼─────────────────────────────┤
       │"\""     doppeltes Anführungszeichen │
       ├─────────┼─────────────────────────────┤
       │"\'"     einfaches Anführungszeichen │
       ├─────────┼─────────────────────────────┤
       │"\s"     Leerzeichen                 │
       ├─────────┼─────────────────────────────┤
       │"\xxx"   Zeichen Nummer xx in        │
       │         │ hexadezimaler Kodierung     │
       ├─────────┼─────────────────────────────┤
       │"\nnn"   Zeichen Nummer nnn in       │
       │         │ oktaler Kodierung           │
       └─────────┴─────────────────────────────┘

BEISPIELE
       Beispiel 2. Einfacher Dienst

       Die folgende Unit-Datei erstellt einen Dienst, der /usr/sbin/foo-daemon
       ausführt. Da kein Type= festgelegt 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= festgelegt 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, 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 3. 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 4. 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 5. 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 6. 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 7. 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. Eine typische
       Dienste-Datei für solch einen Daemon sähe wie folgt aus:

           [Unit]
           Description=Einfacher Benachrichtigungsdienst

           [Service]
           Type=notify
           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.

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. Inkompatibilitäten mit SysV
           https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities

        2. USB FunctionFS
           https://www.kernel.org/doc/Documentation/usb/functionfs.txt


ÜBERSETZUNG
       Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
       <debian@helgefjell.de> erstellt.

       Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General
       Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen.
       Es wird KEINE HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken
       Sie bitte eine E-Mail an <debian-l10n-german@lists.debian.org>.



systemd 246                                                   SYSTEMD.SERVICE(5)