BEZEICHNUNG
systemd.service - Dienste-Unit-KonfigurationÜBERSICHT
Dienst.serviceBESCHREIBUNG
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 [email protected] 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:
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=
•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.
Legt fest, wann der Verwalter den Prozess als
beendeet betrachten soll. Entweder main oder cgroup:
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=
•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.
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
»@«, »-«, »:« 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=
| Präfix | Effekt |
| "@" | 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. |
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 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 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:
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:
ExecStop=
ExecReload=kill -HUP $MAINPID
ExecReload=busctl call org.freedesktop.DBus \
/org/freedesktop/DBus org.freedesktop.DBus \
ReloadConfig
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:
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=
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=
•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
| 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 |
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=
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=
SuccessExitStatus=TEMPFAIL 250 SIGKILL
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:
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=
RestartPreventExitStatus=1 6 SIGABRT
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 für den
Speichererschöpfungs- (OOM-)Killer. Beachten Sie, dass der OOM-Killer
im Anwendungsraum systemd-oomd.service(8) eine flexiblere Lösung
ist, die zu verhindern versucht, dass Speichererschöpfungssituationen
im Anwendungsraum auftreten, nicht nur im Kernel.
Wenn unter Linux der Speicher so knapp wird, dass der Kernel Schwierigkeiten
bekommt, Speicher für sich selbst zu reservieren, dann kann er sich
entscheiden, laufende Prozesse zu beenden, um Speicher freizugeben und den
Speicherdruck zu reduzieren. Diese Einstellung akzeptiert entweder
continue, stop oder kill. Falls auf continue
gesetzt und ein Prozess des Dienstes vom OOM-Killer beendet wird, wird dies
protokolliert aber die Unit läuft weiter. Falls auf stop
gesetzt, wird das Ereignis protokolliert, aber die Unit wird sauber durch den
Diensteverwalter beendet. Falls auf kill gesetzt und einer der Prozesse
der Unit wird durch den OOM-Killer beendet, wird der Kernel angewiesen, auch
alle verbleibenden Prozesse der Unit durch Setzen des Attributes
memory.oom.group auf 1 durch den OOM-Killer zu beenden; siehe auch die
Kerneldokumentation[2].
Standardmäßig der Wert, auf den die Einstellung
DefaultOOMPolicy= in systemd-system.conf(5) gesetzt ist,
außer bei Units, bei denen Delegate= eingeschaltet ist, wo die
Vorgabe continue ist.
Verwenden Sie die Einstellung OOMScoreAdjust=, um zu konfigurieren, ob
Prozesse der Unit als bevorzugte oder weniger bevorzugte Kandidaten für
Prozessbeendigungen durch die Logik des OOM-Killers von Linux betrachtet
werden sollen. Siehe systemd.exec(5) für Details.
Diese Einstellung gilt auch für systemd-oomd(8). Ähnlich
wie beim Kernel-OOM-Killer bestimmt diese Einstellung den Zustand der Unit,
nachdem systemd-oomd(8) eine ihr zugeordnete Cgroup beendet hat.
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}
Environment=EINS='eins' "ZWEI='zwei zwei' auch" DREI=
ExecStart=/bin/echo ${EINS} ${ZWEI} ${DREI}
ExecStart=/bin/echo $EINS $ZWEI $DREI
ExecStart=sh -c 'dmesg | tac'
ExecStart=echo eins ; echo "zwei zwei"
ExecStart=echo / >/dev/null & \; \ 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
[Unit] Description=Bereinigung alter Foo-Daten [Service] Type=oneshot ExecStart=/usr/sbin/foo-cleanup [Install] WantedBy=multi-user.target
[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
[Unit] Description=Ein einfacher Daemon [Service] Type=forking ExecStart=/usr/sbin/my-simple-daemon -d [Install] WantedBy=multi-user.target
[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
[D-BUS Service] Name=org.example.simple-dbus-service Exec=/usr/sbin/simple-dbus-service User=root SystemdService=simple-dbus-service.service
[Unit] Description=Einfacher Benachrichtigungsdienst [Service] Type=notify ExecStart=/usr/sbin/simple-notifying-service [Install] WantedBy=multi-user.target
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
- 2.
- Kernel-Dokumentation
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <[email protected]> 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 die Mailingliste der Übersetzer| systemd 252 |