Ubuntu Manpage: systemd.service - Dienste-Unit-Konfiguration

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. Beachten Sie, dass derzeit Type=notify nicht funktioniert, falls sie in Kombination mit
PrivateNetwork=yes verwandt wird.

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

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:

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

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= 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 Einstellen einer Art von Signal
dafür in die Warteschlange), 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= 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.

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

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-Code 0 und
den Signalen SIGHUP, SIGINT, SIGTERM und SIGPIPE. Exit-Statusdefinitionen können numerische
Exit-Codes, Beendigungs-Code-Namen oder Beendigungssignalnamen, getrennt durch Leerzeichen, sein.
Siehe den Abschnitt »PROZESS-EXIT-CODES« in systemd.exec(5) für eine Liste von Beendigungs-Code-Namen
(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.

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 SIGUSR1

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

Beachten Sie: systemd-analyze exit-codes kann zur Auflistung der Exit-Codes 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.

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. 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 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 durch den Wert der Umgebungsvariablen,
       einschließlich des darin enthaltenen Leerraums, ersetzt und 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. Sie werden der Reihe nach
ausgeführt, bis sie alle erfolgreich waren oder einer fehlschlug.

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 243                                                                                   SYSTEMD.SERVICE(5)