Provided by: manpages-de_4.15.0-9_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 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= angegeben 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 Dienstprogramm 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= 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 wird erwartet, dass der
               Dienst einen Namen auf dem D-Bus-Bus erlangt, wie dies in 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, erlangen implizit eine Abhängigkeit von der Unit dbus.socket. Dieser Typ ist
               die Vorgabe, falls BusName= angegeben ist. 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 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 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 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 Dienstprogramm 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 Dienstprogramm aufgerufen wurde und in
           denen das Dienstprogramm 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.)

       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.

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

           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ä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 │
           │       │ 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 angegeben 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. 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 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
           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 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 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.

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

       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.

       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.

           Tabelle 2. 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. 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, 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.

       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=
           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 /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[1], 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=
           Konfiguriert die Richtlinie des Speicherknappheits- (OOM-)Killers. Beachten Sie, dass
           der OOM-Killer systemd-oomd.service(8) im Benutzerraum eine flexiblere Lösung ist, die
           darauf abzielt, Speicherknappheitssituationen für den Anwendungsraum zu vermeiden,
           nicht nur für den Kernel.

           Wenn unter Linux der Speicher soweit knapp wird, dass der Kernel Probleme bekommt,
           Speicher für sich zu reservieren, kann er sich entscheiden, einen laufenden Prozess zu
           beenden, um Speicher freizugeben und den Speicherdruck zu reduzieren. Diese
           Einstellung akzeptiert entweder continue, stop oder kill. Falls auf continue gesetzt
           und ein Prozess des Dienstes wird vom OOM-Killer des Kernels beendet, dann wird dies
           protokolliert, aber der Dienst läuft weiter. Falls auf stop gesetzt, wird das Ereignis
           protokolliert, aber der Dienst wird sauber durch den Diensteverwalter beendet. Falls
           auf kill gesetzt und einer der Prozesse des Dienstes wird vom OOM-Killer getötet, wird
           der Kernel angewiesen, alle verbliebenen Prozesse des Dienstes auch zu beenden, indem
           das Attribut memory.oom.group auf 1 gesetzt wird; siehe auch die
           Kerneldokumentation[2].

           Standardmäßig folgt dies der Einstellunng DefaultOOMPolicy= in systemd-system.conf(5),
           außer für Dienste, bei denen Delegate= eingeschaltet ist, wo es dann standardmäßig
           continue ist.

           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-Killer-Logik betrachtet werden sollen. Siehe systemd.exec(5) für Details.

           Diese Einstellung gilt auch für systemd-oomd, ähnlich wie der Kernel bei
           Speicherknappheit (OOM) tötet bestimmt diese Einstellung den Dienstezustand, nachdem
           systemd-oomd eine einem Dienst zugeordnete Cgroup tötet.

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

       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.

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

BEISPIELE

       Beispiel 2. 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, 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. USB FunctionFS
           https://www.kernel.org/doc/Documentation/usb/functionfs.txt

        2. Kernel-Dokumentation
           https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

ÜBERSETZUNG

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

       Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
       Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der 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⟩.