SYSTEMD.SERVICE(5) systemd.service SYSTEMD.SERVICE(5) BEZEICHNUNG systemd.service - Dienste-Unit-Konfiguration UBERSICHT Dienst.service BESCHREIBUNG Eine Unit-Konfigurationsdatei, deren Name in >>.service<< endet, kodiert Informationen uber einen von Systemd gesteuerten und uberwachten Prozess. Diese Handbuchseite listet die fur diesen Unit-Typ spezifischen Konfigurationsoptionen auf. Siehe systemd.unit(5) fur 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. Zusatzliche Optionen sind in systemd.exec(5), das die Ausfuhrungsumgebung, in der die Befehle ausgefuhrt 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 fur die Prozesse des Dienstes konfiguriert, aufgefuhrt. Der Befehl erlaubt das dynamische und fluchtige Erstellen von >>.service<<- und >>.scope<<-Units auf der Befehlszeile. DIENSTEVORLAGEN systemd-Dienste konnen ein einzelnes Argument uber die Syntax >>Dienst@Argument.service<< akzeptieren. Solche Dienste heissen >>instanziierte<< Dienste, wahrend die Unit-Definition ohne den Parameter Argument >>Vorlage<< genannt wird. Eine Beispiel konnte 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) fur Details. AUTOMATISCHE ABHANGIGKEITEN Implizite Abhangigkeiten Die folgenden Abhangigkeiten werden implizit hinzugefugt: o Dienste mit Type=dbus erlangen automatisch Abhangigkeiten des Typs Requires= und After= von dbus.socket. o Socket-aktivierte Dienste werden automatisch nach ihren aktivierenden .socket-Units mittels einer automatischen After=-Abhangigkeit sortiert. Dienste ziehen auch alle in Sockets= aufgefuhrten .socket-Units mittels automatischer Wants=- und After=-Abhangigkeiten herein. Zusatzliche implizite Abhangigkeiten als Ergebnis der Ausfuhrung und der gemass systemd.exec(5) und systemd.resource-control(5) dokumentierten Ressourcen-Steuerungsparameter konnen hinzugefugt werden. Standardabhangigkeiten Die folgenden Abhangigkeiten werden hinzugefugt, es sei denn, DefaultDependencies=no ist gesetzt: o Dienste-Units werden Abhangigkeiten des Typs Requires= und After= von sysinit.target, eine Abhangigkeit des Typs After= on basic.target sowie Abhangigkeiten 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 fruhen Systemstartphase oder beim Herunterfahren des Systems beteiligt sind, sollten diese Option deaktivieren. o Instanziierten Dienste-Units (d.h. Dienste-Units mit einem >>@<< in ihrem Namen) wird standardmassig eine vorlagenbezogene Scheiben-Unit zugewiesen (siehe systemd.slice(5)), die nach der Vorlagen-Unit benannt wird und alle Instanzen der festgelegten Vorlage enthalt. Diese Scheibe wird normalerweise beim Herunterfahren zusammen mit allen Vorlageninstanzen gestoppt. Falls dies nicht gewunscht 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 konnen Abschnitte [Unit] und [Install] enthalten, die in systemd.unit(5) beschrieben sind. Dienste-Unit-Dateien mussen einen Abschnitt >>[Service]<< enthalten, der Informationen uber den Dienst und den Prozess, den er uberwacht, zusammentragt. Eine Reihe von Optionen, die in diesem Abschnitt genutzt werden konnen, werden mit anderen Unit-Typen gemeinsam benutzt. Diese Optionen sind in systemd.exec(5), systemd.kill(5) und systemd.resource-control(5) beschrieben. Die fur den Abschnitt >>[Service]<< von Dienste-Units spezifischen Optionen sind: Type= Konfiguriert den Mechanismus, uber den der Dienst den Verwalter informiert, dass der Startvorgang des Dienstes abgeschlossen ist. Einer aus simple, exec, forking, oneshot, dbus, notify, notify-reload oder idle: o Falls auf simple gesetzt ist (die Vorgabe, falls ExecStart= angegeben ist, aber weder Type= noch BusName= gesetzt sind und keine Zugangsberechtigungen verwandt werden), wird der Diensteverwalter die Unit als gestartet betrachten, sobald der Hauptdiensteprozess mittels >>fork<< erzeugt wurde (d.h. direkt nach fork() und bevor verschiedene Prozessarttribute konfiguriert wurden und insbesondere bevor der neue Prozess execve() aufgerufen hat, um das eigentliche Diensteprogramm zu starten). Typischerweise ist Type=exec die bessere Wahl, siehe unten. Es wird erwartet, dass der mit ExecStart= konfigurierte Prozess der Hauptprozess des Dienstes ist. In diesem Modus sollte der Kommunikationskanal vor dem Starten des Dienstes installiert sein (d.h. die Sockets von Systemd mittels Socket-Aktivierung eingerichtet sein), da der Diensteverwalter sofort mit dem Starten von nachfolgenden Units beginnt, direkt nachdem der Hauptdiensteprozess erstellt und bevor das Programm des Dienstes ausgefuhrt wurde. Beachten Sie, dass dies bedeutet, dass Befehlszeilen systemctl start fur simple-Dienste Erfolg melden werden, selbst wenn das Programm des Dienstes nicht erfolgreich aufgerufen werden kann (beispielsweise weil der ausgewahlte User= nicht existiert oder das Programm des Dienstes fehlt). o Der Typ exec ist ahnlich zu simple, aber der Diensteverwalter wird die Unit sofort nach der Ausfuhrung des Hauptdiensteprogramms als gestartet betrachten. Der Diensteverwalter wird das Starten nachfolgender Units bis zu diesem Zeitpunkt verzogern. (Oder in anderen Worten: simple fahrt einfach mit weiteren Auftragen fort, direkt nachdem fork() zuruckkehrt, wahrend exec nicht fortfahren wird, bevor sowohl fork() als auch execve() im Diensteprozess erfolgreich waren.) Beachten Sie, dass dies bedeutet, dass die Befehlszeile systemctl start fur exec-Dienste einen Fehlschlag melden wird, wenn das Programm des Dienstes nicht erfolgreich aufgerufen werden kann (beispielsweise weil der ausgewahlte User= nicht existiert oder das Dienstprogramm fehlt). Dieser Typ wird impliziert, falls Zugangsberechtigungen verwandt werden (lesen Sie LoadCredential= in systemd.exec(5) zu Details). o Falls auf forking gesetzt, wird der Verwalter die Unit sofort als gestartet betrachten, nachdem sich das vom Verwalter mittels Fork gestartete Programm beendet. Von der Verwendung dieses Typs wird abgeraten, verwenden Sie stattdessen notify, notify-reload oder dbus. Es wird erwartet, dass der mit ExecStart= konfigurierte Prozess fork() als Teil seines Hochfahrens aufrufen wird. Es wird erwartet, dass der Elternprozess sich nach dem Hochfahren und der Einrichtung aller Kommunikationskanale beendet. Der Kindprozess lauft 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 zuverlassig den Hauptprozess des Dienstes identifizieren kann. Der Verwalter wird mit dem Starten von nachfolgenden Units fortfahren, nachdem sich der Elternprozess beendet. o Das Verhalten von oneshot ist ahnlich zu exec, allerdings wird der Diensteverwalter die Unit als hochgebracht betrachten, nachdem sich der Hauptprozess beendet hat. Er wird dann nachfolgende Units starten. RemainAfterExit= ist fur diesen Dienstetyp besonders nutzlich. 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<< ubergehen wird, da kein Prozess zum dauerhaften Betrieb konfiguriert ist. Insbesondere bedeutet dies, dass nach der Ausfuhrung eines Dienstes dieser Art (und der RemainAfterExit= nicht gesetzt hat), dieser danach nicht als gestartet sondern als tot angezeigt wird. o Verhalten von dbus ist ahnlich zu simple; allerdings muss fur Units dieses Typ der BusName= festgelegt werden und der Diensteverwalter wird die Unit als >>oben<< betrachten, wenn der festgelegte Busname erlangt wurde. Dieser Typ ist die Vorgabe, falls BusName= angegeben ist. Dienste-Units, bei denen diese Option konfiguriert ist, erlangen implizit eine Abhangigkeit von der Unit dbus.socket. Eine Dienste-Unit von diesem Typ wird im aktivierenden Zustand betrachtet, bis der angegebene Busname erlangt wurde. Sie wird als aktiviert angesehen, solange der Bus-Name belegt ist. Sobald der Busname freigegeben ist, wird der Dienst nicht mehr als funktional betrachtet. Dies hat die Auswirkung, dass der Diensteverwalter versucht, alle verbliebenen Prozesse, die zu dem Dienst gehoren, 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. o Das Verhalten von notify ist ahnlich zu exec, allerdings wird erwartet, dass der Dienst mittels sd_notify(3) oder einem Aquivalent eine >>READY=1<<-Benachrichtigung sendet, wenn er mit dem Hochfahren fertig ist. Systemd wird mit dem Starten nachfolgender Units fortfahren, nachdem diese Benachrichtigung gesandt wurde. Falls diese Option verwandt wird, sollte NotifyAccess= (siehe unten) auf offenen Zugriff auf den von Systemd bereitgestellten Benachrichtigungs-Socket gesetzt werden. Falls NotifyAccess= fehlt oder auf none gesetzt ist, wird er zwangsweise auf main gesetzt. Falls der Dienst das Neuladen unterstutzt und ein Signal zum Starten des Neuladens benutzt, wird stattdessen notify-reload empfohlen. o Das Verhalten von notify-reload ist ahnlich zu notify mit einem Unterschied: das UNIX-Prozessignal SIGHUP wird an den Hauptprozess des Dienstes gesandt, wenn der Dienst um einen Neuladen gebeten wird und der Verwalter wird auf eine Benachrichtigung, dass das Neuladen abgeschlossen ist, warten. Wenn der Neuladeprozess initiiert wird, wird erwartet, dass der Dienst mit einer Benachrichtigungsmeldung uber sd_notify(3) antwortet, die das Feld >>RELOADING=1<< in Kombination mit >>MONOTONIC_USEC=<<, gesetzt auf die aktuelle monotone Zeit, enthalt (d.h. CLOCK_MONOTONIC in clock_gettime(2)) in s, formatiert als dezimale Zeichenkette.) Sobald das Neuladen abgeschlossen ist, muss eine weitere Benachrichtigungsmeldung, die >>READY=1<< enthalt, gesandt werden. Verwendung dieses Dienstetyps und Implementierung dieses Neuladeprotokolls ist eine effiziene Alternative zur Bereitstellung des Befehls ExecReload= zum Neuladen der Konfiguration des Dienstes. Das zu sendende Signal kann mittels ReloadSignal= angepasst werden, siehe unten. o Das Verhalten von idle ist sehr ahnlich zu simple; allerdings wird die tatsachliche Ausfuhrung des Dienstprogramms verzogert, bis alle aktiven Auftrage 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 nutzlich ist, er ist nicht als allgemeines Werkzeug zum Sortieren von Units nutzlich und der Effekt dieses Dienstetyps unterliegt einer Zeituberschreitung von 5 s, nach der das Dienstprogramm auf jeden Fall ausgefuhrt wird. Es wird empfohlen, Type=exec fur langlaufende Dienste zu verwenden, da es sicherstellt, dass Prozess-Einrichtungsfehler (z.B. Fehler wie ein fehlendes Diensteprogramm oder fehlende Benutzer) korrekt nachverfolgt werden. Da dieser Dienstetyp allerdings Fehler im eigenen Einrichtungscode nicht weiterleitet (im Gegensatz zu Fehlern in den vorbereitenden Schritten, die der Diensteverwalter vor execve() ausfuhrt) und keine Ordnung von anderen Units nach Abschluss der Initialisierung des Dienste-Codes selbst erlaubt (was beispielsweise fur 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 ahnlichem zu erledigen)), konnte er in vielen Fallen nicht ausreichend sein. Dann sind notify, notify-reload oder dbus (Letzteres nur in dem Fall, in dem der Dienst eine D-Bus-Schnittstelle bereitstellt) die bevorzugten Optionen, da sie dem Dienstprogramm genau einzuplanen erlauben, wann der Dienst als erfolgreich gestartet betrachtet werden soll und wann mit den nachfolgenden Units fortgefahren werden soll. Die Dienstetypen notify/notify-reload benotigen explizite Unterstutzung im Programmcode des Dienstes (da sd_notify() oder eine aquivalente API zum geeigneten Zeitpunkt durch den Dienst aufgerufen werden muss) -- falls dies nicht unterstutzt wird, ist forking eine Alternative: es unterstutzt das schwergewichtige Startprotokoll traditioneller UNIX-Dienste. Beachten Sie, dass die Verwendung aller von simple verschiedenen Typen moglicherweise den Systemstartprozess verzogert, da der Diensteverwalter darauf warten muss, dass die Initialisierung fur mindestens einige Dienste abgeschlossen ist. (Es wird im Allgemeinen auch nicht empfohlen, idle oder oneshot fur langlaufende Dienste zu verwenden.) Beachten Sie, dass verschiedene Einstellungen (z.B. User=, Group= mittels Libc-NSS) beim Einsatz zu >>versteckten<< blockierenden IPC-Aufrufen von anderen Diensten fuhren konnte. Manchmal konnte es ratsam sein, den Dienstetyp simple zu verwenden, um sicherzustellen, dass die Transaktionslogik des Diensteverwalters nicht durch solche, moglicherweise langsamen Aktionen und versteckten Abhangigkeiten betroffen ist, da dies der einzige Dienstetyp ist, bei dem der Diensteverwalter nicht darauf warten wird, dass solche Dienste-Ausfuhrungs-Einrichtungsaktionen abgeschlossen sind, bevor er fortfahrt. ExitType= Legt fest, wann der Verwalter den Prozess als beendeet betrachten soll. Entweder main oder cgroup: o 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. o Falls auf cgroup gesetzt, wird der Dienst als laufend betrachtet, solange mindestens ein Prozess in der Cgroup sich nicht beendet hat. Im allgemeinen wird empfohlen, ExitType=main zu verwenden, wenn ein Dienst ein bekanntes Modell zur Erzeugung von Prozessen mit Fork hat und ein Hauptprozess zuverlassig bestimmt werden kann. ExitType= cgroup ist fur Anwendungen gedacht, deren Modell zur Erzeugung von Prozessen mit Fork vorab unbekannt ist und die keinen bestimmten Hauptprozess haben konnten. Es ist gut fur fluchtige oder automatisch erstellte Dienste, wie graphische Anwendungen innerhalb einer Desktop-Umgebung, geeignet. Hinzugefugt in Version 250. RemainAfterExit= Akzeptiert einen logischen Wert, der angibt, ob der Dienst, selbst wenn sich alle seine Prozesse beendet haben, als aktiv betrachtet werden sollte. Standardmassig no. GuessMainPID= Akzeptiert einen logischen Wert, der angibt, ob Systemd versuchen soll, die Haupt-PID eines Dienstes zu raten, falls es sie nicht zuverlassig bestimmen kann. Diese Option wird ignoriert, ausser Type=forking ist gesetzt und PIDFile= ist nicht gesetzt, da fur 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 zuverlassig funktionieren. Standardmassig yes. PIDFile= Akzeptiert einen Pfad zur PID-Datei des Dienstes. Fur 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 fur den Diensteverwalter angegeben wird, wird ihm daher /run/ vorangestellt und ihm wird $XDG_RUNTIME_DIR vorangestellt, falls er in einem Benutzerdienst festgelegt ist. 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 loschen, falls sie nach dem Beenden des Dienstes noch existiert. Die PID-Datei muss keinem privilegierten Benutzer gehoren, falls sie aber einem unprivilegierten Benutzer gehort, werden zusatzliche Sicherheitsbeschrankungen durchgesetzt: die Datei darf kein Symlink auf eine Datei, die einem anderen Benutzer gehort, sein (weder direkt noch indirekt) und die PID-Datei muss sich auf einen Prozess beziehen, der bereits zum Dienst gehort. Beachten Sie, dass PID-Dateien in modernen Projekten vermieden werden sollten. Verwenden Sie, wo moglich, Type=notify, Type=notify-reload oder Type=simple, die keinen Einsatz von PID-Dateien benotigen, um den Hauptprozess des Dienstes zu bestimmen, und unnotige Aufrufe von Fork vermeiden. BusName= Akzeptiert einen D-Bus-Zielnamen, den dieser Dienst nutzen soll. Diese Option ist fur Dienste verpflichtend, bei denen Type= auf dbus gesetzt ist. Es wird empfohlen, diese Eigenschaft immer zu setzen, falls sie bekannt ist, um es zu erleichtern, den Dienstenamen auf das D-Bus-Ziel abzubilden. Insbesondere die Unterbefehle von systemctl service-log-level/service-log-target verwenden dies. ExecStart= Befehle, die beim Starten dieses Dienstes ausgefuhrt werden. Es muss genau ein Befehl angegeben werden, ausser Type= ist auf oneshot gesetzt. Wenn Type=oneshot verwandt wird, kann diese Einstellung mehrfach verwandt werden, um mehrere auszufuhrende Befehle zu definieren. Falls dieser Option die leere Zeichenketten zugewiesen wird, wird die Liste der zu startenden Befehle zuruckgesetzt 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 gultig.) Falls mehr als ein Befehl konfiguriert ist, werden die Befehle der Reihe nach in der Reihenfolge, in der sie in der Unit-Datei auftauchen, ausgefuhrt. Falls einer der Befehle fehlschlagt (und ihm kein >>-<< vorangestellt ist) werden die anderen Zeilen nicht ausgefuhrt und die Unit wird als fehlgeschlagen betrachtet. Ausser falls Type=forking gesetzt ist, wird der uber die Befehlszeile gestartete Prozess als Hauptprozess des Daemons betrachtet. ExecStartPre=, ExecStartPost= Zusatzliche Befehle, die vor bzw. nach dem Befehl in ExecStart= gestartet werden. Syntax ist identisch zu ExecStart=. Mehrere Befehlszeilen sind unabhangig vom Dienstetyp (d.h. Type=) erlaubt und die Befehle werden seriell einer nach dem anderen ausgefuhrt. Falls einer dieser Befehle (dem nicht >>-<< vorangestellt ist) fehlschlagt, wird der Rest nicht ausgefuhrt und die Unit als fehlgeschlagen betrachtet. ExecStart=-Befehle werden nur ausgefuhrt, nachdem alle ExecStartPre=-Befehle, denen kein >>-<< vorangestellt wurde, sich erfolgreich beendet haben. ExecStartPost=-Befehle werden nur ausgefuhrt, nachdem die in ExecStart= festgelegten Befehle erfolgreich gestartet wurden, wie durch Type= festgelegt (d.h. der Prozess wurde fur Type=simple oder Type=idle gestartet, der letzte ExecStart=-Prozess hat sich erfolgreich fur Type=oneshot beendet, der anfangliche Prozess hat sich fur Type=forking erfolgreich beendet, >>READY=1<< ist fur Type=notify/Type=notify-reload gesetzt oder der BusName= ist fur 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 getotet, bevor der nachste Diensteprozess ausgefuhrt wird. Beachten Sie, dass falls einer der in ExecStartPre=, ExecStart= oder ExecStartPost= festgelegten Prozesse fehlschlagt (und ihm kein >>-<< vorangestellt wurde, siehe oben) oder seine Zeit abgelaufen ist, bevor der Dienst vollstandig hochgekommen ist, die Ausfuhrung mit den in ExecStopPost= festgelegten Komponenten fortgefahren wird und die Befehle in ExecStop= ubersprungen werden. Beachten Sie, dass die Ausfuhrung von ExecStartPost= zum Zwecke der Before=/After= Ordnungsbeschrankungen berucksichtigt wird. ExecCondition= Optionale Befehle, die vor den Befehlen in ExecStartPre= gestartet werden. Syntax ist identisch zu ExecStart=. Mehrere Befehlszeilen sind unabhangig vom Dienstetyp (d.h. Type=) erlaubt und die Befehle werden seriell einer nach dem anderen ausgefuhrt. Das Verhalten ist wie ein ExecStartPre= und die Bedingungsprufung erfolgt hybrid: wenn sich ein ExecCondition=-Befehl mit Exit-Code 1 bis 254 (einschliesslich) beendet, werden die verbleibenden Befehle ubersprungen und die Unit wird nicht als fehlgeschlagen markiert. Falls sich allerdings ein ExecCondition=-Befehl mit 255 oder unnormal (z.B. wegen einer Zeituberschreitung, durch ein Signal getotet) beendet, wird die Unit als fehlgeschlagen betrachtet (und die verbliebenen Befehle ubersprungen). Exit-Code 0 oder solche, die auf SuccessExitStatus= passen, fuhren zur Ausfuhrung der nachsten Befehle. Die gleiche Empfehlung, keine langlaufenden Prozesse in ExecStartPre= auszufuhren, gilt auch fur ExecCondition=. ExecCondition= wird, falls eine Beendigung nicht Null oder unnormal erfolgt, beim Stoppen des Dienstes auch die in ExecStopPost= aufgefuhrten Befehle ausfuhren, wie die oben beschriebenen. Hinzugefugt in Version 243. ExecReload= Zu startende Befehle losen ein Neuladen der Konfiguration in dem Dienst aus. Diese Einstellung kann mehrere Befehlszeilen akzeptieren, die dem gleichen Schema wie oben fur ExecStart= folgen. Die Verwendung dieser Einstellung ist optional. Kennzeichner- und Umgebungsvariablenersetzung wird hier mit dem gleichen Schema wie fur ExecStart= unterstutzt. Eine zusatzliche, besondere Umgebungsvariable wird gesetzt: falls bekannt, wird $MAINPID auf den Hauptprozess des Daemons gesetzt und kann fur Befehlszeilen wie der folgenden benutzt werden: ExecReload=kill -HUP $MAINPID Beachten Sie, dass das Neuladen eines Daemons durch Einstellen eines Signals in die Warteschlange ohne Abschluss der Benachrichtigung (wie in dem obigen Beispiel der Fall ist) normalerweise keine gute Wahl ist, da dies eine asynchrone Aktion und daher nicht dazu geeignet ist, das Neuladen von mehreren Diensten untereinander zu sortieren. Es wird daher nachdrucklich empfohlen, Type=notify-reload oder ExecReload= auf einen Befehl zu setzen, der nicht nur das Neuladen des Daemons auslost, sondern auch synchron darauf wartet, dass dies abgeschlossen wird. Beispielsweise verwendet dbus-broker(1) Folgendes: ExecReload=busctl call org.freedesktop.DBus \ /org/freedesktop/DBus org.freedesktop.DBus \ ReloadConfig Diese Einstellung kann mit Type=notify-reload kombiniert werden. In diesem Fall wird dem Hauptprozess signalisiert, nachdem alle festgelegten Befehlszeilen ihre Ausfuhrung beendet haben. Insbesondere wird die Signalisierung ubersprungen und der Diensteverwalter startet sofort mit dem Warten auf >>READY=1<<-Meldungen, falls die Benachrichtigung >>RELOADING=1<< empfangen wird, bevor ExecReload= abgeschlossen ist. ExecReloadPost= Befehle, die nach einer erfolgreichen Neuladeaktion ausgefuhrt werden. Die Syntax fur diese Einstellung ist exakt identisch zu der von ExecReload=. Hinzugefugt in Version 259. ExecStop= Die zum Stoppen des mittels ExecStart= gestarteten Dienstes zu verwendenden Befehle. Dieses Argument akzeptiert mehrere Befehlszeilen, die dem gleichen Schema wie oben fur ExecStart= beschrieben folgen. Die Verwendung dieser Einstellung ist optional. Nachdem die in dieser Option konfigurierten Befehle ausgefuhrt wurden, wird impliziert, dass der Dienst gestoppt ist und alle von ihm verbliebenen Prozesse werden gemass 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 unterstutzt (einschliesslich $MAINPID, siehe oben). Beachten Sie, dass es normalerweise nicht ausreicht, einen Befehl fur 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, gemass den oben beschriebenen KillMode= und KillSignal= oder RestartKillSignal= getotet werden, kann dies zu einem unsauberen Stopp fuhren. Der angegebene Befehl sollte daher eine synchrone Aktion und nicht eine asynchrone sein. Beachten Sie, dass die in ExecStop= festgelegten Befehle nur ausgefuhrt werden, wenn der Dienst zuerst erfolgreich gestartet wird. Sie werden nicht aufgerufen, falls der Dienst uberhaupt 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 Zeituberschreitung 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 durchgefuhrt wird, wenn der Dienst erfolgreich startete, selbst falls die Prozesse in dem Dienst sich von alleine beendeten oder getotet wurden. Der Stopp-Befehl muss fur diesen Fall vorbereitet sein. $MAINPID wird nicht gesetzt sein, falls Systemd weiss, 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 wahrend einer Diensteneustartaktion ExecStop= und ExecStopPost= ausgefuhrt werden. Es wird empfohlen, diese Einstellung fur Befehle zu verwenden, die mit dem Dienst kommunizieren, die das saubere Beenden erbitten. Fur Post-mortem-Bereinigungsschritte verwenden Sie stattdessen ExecStopPost=. ExecStopPost= Zusatzliche Befehle, die ausgefuhrt werden, nachdem der Dienst beendet wurde. Dies schliesst Falle 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 fur ExecStart= definierten Schema folgen. Die Verwendung dieser Einstellungen ist optional. Kennzeichner- und Umgebungsvariablenersetzung wird unterstutzt. 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 fur Aufraumaktionen zu verwenden, die ausgefuhrt werden sollen, selbst wenn das korrekte Starten des Dienstes fehlschlug. Befehle, die mit dieser Einstellung konfiguriert sind, mussen in der Lage sein, zu funktionieren, selbst falls der Dienst mitten im Starten fehlschlug und unvollstandig initialisierte Daten hinterliess. Da sich die Prozesse des Dienstes wahrscheinlich bereits beendet haben, wenn die mit dieser Einstellung festgelegten Befehle ausgefuhrt 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) fur Details. Beachten Sie, dass die Ausfuhrung von ExecStopPost= zum Zwecke der Before=/After= Ordnungsbeschrankungen berucksichtigt 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<<. Standardmassig 100 ms. RestartSteps= Konfiguriert die Anzahl an exponentiell zu durchlaufenden Schritten, um das Interval von Selbstneustarts von RestartSec= auf RestartMaxDelaySec= zu erhohen. Akzeptiert eine positive Ganzzahl oder 0, um es zu deaktivieren. Standardmassig 0. Tipp: Werte zwischen 3 und 5 sind eine gute Wahl, wenn exponentielles Rucksetzen gewunscht wird. Beispiel: RestartSec=10s RestartSteps=4 RestartMaxDelaySec=160s Dies erzeugt die folgenden Neustartintervalle: 10s, 20s, 40s, 80s, 160s, 160s, 160s, usw. Beachten Sie die geometrische Interpolation und das daraus entstehende konstante Verhaltnis zwischen Intervallen: hier lautet es 2. Die Formel fur Verhaltnis is (RestartMaxDelaySec / RestartSec)^(1 / RestartSteps). Eine (wiederholte) Verzogerung gleich RestartMaxDelaySec= wird immer nach RestartSteps + 1 Schritten erreicht. Diese Einstellung ist nur wirksam, falls auch RestartMaxDelaySec= gesetzt und RestartSec= nicht Null ist. Hinzugefugt in Version 254. RestartMaxDelaySec= Konfiguriert die vor dem Neustart eines Dienstes maximal zu schlafende Zeit wahrend das Interval mit RestartSteps= erhoht wird. Akzeptiert einen Wert im gleichen Format wie RestartSec= oder >>infinity<<, um diese Einstellung zu deaktivieren. Standardmassig >>infinity<<. Diese Einstellung ist nur wirksam, falls auch RestartSteps= gesetzt und RestartSec= nicht Null ist. Hinzugefugt in Version 254. TimeoutStartSec= Konfiguriert die Zeit, die auf das Starten gewartet werden soll. Falls ein Daemon-Dienst den Abschluss des Startens nicht innerhalb der konfigurierten Zeit signalisiert, wird der Dienst als fehlgeschlagen angesehen und wieder heruntergefahren. Die genaue Aktion hangt von der Option TimeoutStartFailureMode= ab. Akzeptiert einen einheitenfreien Wert in Sekunden oder einen Zeitdauerwert wie >>5min 20s<<. Ubergeben Sie >>infinity<<, um die Zeituberschreitungslogik zu deaktivieren. Standardmassig das in dem Verwalter gesetzte DefaultTimeoutStartSec=, ausser wenn Type=oneshot konfiguriert ist, dann wird die Zeituberschreitung standardmassig deaktiviert (siehe systemd-system.conf(5)). Falls ein Dienst vom Type=notify/Type=notify-reload >>EXTEND_TIMEOUT_USEC=<< sendet, kann dies dazu fuhren, dass die Startzeit sich uber TimeoutStartSec= hinauszieht. Der erste Empfang dieser Nachricht muss auftreten, bevor TimeoutStartSec= uberschritten wird und sobald die Startzeit sich uber TimeoutStartSec= hinausgezogen hat, wird der Diensteverwalter dem Dienst die Weiterfuhrung des Startens erlauben, vorausgesetzt, der Dienst wiederholt >>EXTEND_TIMEOUT_USEC=<< innerhalb des festgelegten Intervalls, bis der Dienstestart durch >>READY=1<< abgeschlossen ist (siehe sd_notify(3)). Beachten Sie, dass die Start-Zeituberschreitung auch beim Neuladen von Diensten angewandt wird, unabhangig davon, ob dies mittels ExecReload= oder mittels der Type=notify-reload-Neuladelogik erfolgt. Falls das Neuladen nicht innerhalb der konfigurierten Zeit erfolgt, wird das Neuladen als fehlgeschlagen betrachtet und der Dienst wird mit der alten Konfiguration weiterlaufen. Dies wird den laufenden Dienst nicht betreffen, aber es wird protokolliert und fuhrt dazu, dass beispielsweise systemctl reload fehlschlagt. Hinzugefugt in Version 188. TimeoutStopSec= Diese Option dient zwei Zwecken. Zuerst konfiguriert sie die Zeit, die fur jeden ExecStop=-Befehl gewartet werden soll. Falls bei einem von ihnen eine Zeituberschreitung auftritt, werden nachfolgende ExecStop=-Befehle ubersprungen und der Dienst wird durch SIGTERM beendet. Falls keine ExecStop=-Befehle festgelegt sind, erhalt der Dienst das SIGTERM sofort. Dieses Standardverhalten kann mit der Option TimeoutStopFailureMode= geandert 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<<. Ubergeben Sie >>infinity<<, um die Zeituberschreitungslogik zu deaktivieren. Standardmassig DefaultTimeoutStopSec= aus der Verwalterkonfigurationsdatei (siehe systemd-system.conf(5)). Falls ein Dienst vom Type=notify/Type=notify-reload >>EXTEND_TIMEOUT_USEC=<< sendet, kann dies dazu fuhren, dass die Stoppzeit sich uber TimeoutStopSec= hinauszieht. Der erste Empfang dieser Nachricht muss auftreten, bevor TimeoutStopSec= uberschritten wird und sobald die Stoppzeit sich uber TimeoutStopSec= hinausgezogen hat, wird der Diensteverwalter dem Dienst die Weiterfuhrung des Stoppens erlauben, vorausgesetzt, der Dienst wiederholt >>EXTEND_TIMEOUT_USEC=<< innerhalb des festgelegten Intervalls oder beendet sich (siehe sd_notify(3)). Hinzugefugt in Version 188. TimeoutAbortSec= Diese Option konfiguriert die Zeit, die auf die Beendigung des Dienstes gewartet werden soll, wenn dieser aufgrund einer Watchdog-Zeituberschreitung 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 vernunftige Zeituberschreitung fur das Erstellen von Speicherauszugen pro Dienst zu setzen, die gross 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<<. Ubergeben Sie einen leeren Wert, um die Handhabung der zugeordneten Watchdog-Zeituberschreitung zu uberspringen und auf TimeoutStopSec= zuruckzufallen. Ubergeben Sie >>infinity<<, um die Zeituberschreitungslogik zu uberspringen. Standardmassig DefaultTimeoutAbortSec= aus der Verwalterkonfigurationsdatei (siehe systemd-system.conf(5)). Falls ein Dienst vom Type=notify/Type=notify-reload SIGABRT selber handhabt (statt sich auf den Kernel zum Schreiben eines Speicherauszuges zu verlassen), kann er >>EXTEND_TIMEOUT_USEC=<< senden, um die Abbruchzeit uber TimeoutAbortSec= hinaus zu verlangern. Der erste Empfang dieser Nachricht muss auftreten, bevor TimeoutAbortSec= uberschritten wird und sobald die Abbruchzeit sich uber TimeoutAbortSec= hinausgezogen hat, wird der Diensteverwalter dem Dienst die Weiterfuhrung des Abbrechens erlauben, vorausgesetzt, der Dienst wiederholt >>EXTEND_TIMEOUT_USEC=<< innerhalb des festgelegten Intervalls oder beendet sich (siehe sd_notify(3)). Hinzugefugt in Version 243. TimeoutSec= Eine Kurzform, um sowohl TimeoutStartSec= als auch TimeoutStopSec= auf den angegebenen Wert zu konfigurieren. TimeoutStartFailureMode=, TimeoutStopFailureMode= Diese Option konfiguriert die Aktion, die durchgefuhrt 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 fur beide Optionen ist terminate. Falls terminate gesetzt ist, wird der Dienst sauber beendet, indem ihm das in KillSignal= festgelegte Signal (standardmassig 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 Zeituberschreitungen. Diese Einstellung kann zur Beschleunigung des Herunterfahrens von fehlgeschlagenen Diensten verwandt werden. Hinzugefugt in Version 246. RuntimeMaxSec= Konfiguriert eine maximale Laufzeit fur den Dienst. Falls dies verwandt wird und der Dienst langer als die festgelegte Zeit gelaufen ist, wird er beendet und in einen Fehlschlagzustand versetzt. Beachten Sie, dass diese Einstellung keine Auswirkungen auf Type=oneshot-Dienste hat, da diese sofort beendet werden, nachdem ihre Aktivierung abgeschlossen ist (verwenden Sie TimeoutStartSec=, um ihre Aktivierung zu begrenzen). Ubergeben Sie >>infinity<< (die Vorgabe), um keine Laufzeitbeschrankung zu konfigurieren. Falls ein Dienst vom Type=notify/Type=notify-reload >>EXTEND_TIMEOUT_USEC=<< sendet, kann dies dazu fuhren, dass die Laufzeit sich uber RuntimeMaxSec= hinauszieht. Der erste Empfang dieser Nachricht muss auftreten, bevor RuntimeMaxSec= uberschritten wird und sobald die Laufzeit sich uber RuntimeMaxSec= hinausgezogen hat, wird der Diensteverwalter dem Dienst die Weiterfuhrung 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)). Hinzugefugt in Version 229. RuntimeRandomizedExtraSec= Diese Option verandert RuntimeMaxSec= durch Erhohung der maximalen Laufzeit mit einer gleichverteilten Dauer zwischen 0 und dem festgelegten Wert (in Sekunden). Falls RuntimeMaxSec= nicht festgelegt ist, wird diese Funktionalitat deaktiviert. Hinzugefugt in Version 250. WatchdogSec= Konfiguriert die Watchdog-Zeituberschreitung fur einen Dienst. Der Watchdog wird aktiviert, wenn das Hochfahren abgeschlossen ist. Der Dienst muss regelmassig sd_notify(3) mit >>WATCHDOG=1<< (d.h. dem >>Totmannschalter<<) aufrufen. Falls die Zeit zwischen zwei solcher Aufrufe grosser 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 ausgefuhrten Prozess ubergeben. Dies ermoglicht es Daemons, die Totmannschaltlogik zu aktivieren, falls fur den Dienst die Watchdog-Unterstutzung 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. Standardmassig 0, wodurch diese Funktionalitat deaktiviert wird. Der Dienst kann prufen, ob der Diensteverwalter Watchdog-Lebenszeichenbenachrichtigungen erwartet. Siehe sd_watchdog_enabled(3) fur Details. sd_event_set_watchdog(3) kann zur Aktivierung der automatischen Watchdog-Benachrichtigungsunterstutzung verwandt werden. Restart= Konfiguriert, ob der Dienst neu gestartet werden soll, wenn der Diensteprozess sich beendet, getotet wird oder eine Zeituberschreitung 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. Zeituberschreitungen schliessen nicht eingehaltene Fristen fur die Watchdog->>Totmannschaltung<< und Zeituberschreitungen fur 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: o der Exit-Code ist 0 o fur alle Typen ausser Type=oneshot: eines der Signale SIGHUP, SIGINT, SIGTERM, SIGPIPE o einer der in SuccessExitStatus= festgelegten Exit-Stati und -Signale Falls auf on-failure gesetzt, wird der Dienst neu gestartet, wenn der Prozess sich mit einem von Null verschiedenen Exit-Code beendet, durch ein Signal beendet wird (einschliesslich eines Speicherauszuges, aber ausschliesslich der vorher genannten Signale), wenn eine Aktion (wie das Neuladen eines Dienstes) in eine Zeituberschreitung lauft und wenn die konfigurierte Watchdog-Zeituberschreitung ausgelost wird. Falls auf on-abnormal gesetzt, wird der Dienst neu gestartet, wenn der Prozess durch ein Signal beendet wird (einschliesslich eines Speicherauszuges, aber ausschliesslich der vorher genannten Signale), wenn eine Aktion in eine Zeituberschreitung lauft und wenn die konfigurierte Watchdog-Zeituberschreitung ausgelost 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-Zeituberschreitung fur den Dienst ablauft. Falls auf always gesetzt, wird der Dienst neu gestartet, unabhangig davon, ob er sauber beendet wurde oder nicht, abnormal durch ein Signal beendet wurde oder in eine Zeituberschreitung lief. Beachten Sie, dass Dienste mit Type=oneshot niemals bei einem sauberen Exit-Status neu gestartet werden, d.h. always und on-success fur sie abgelehnt werden. Tabelle 1. Exit-Grunde und der Effekt der Einstellung Restart= +--------------------------------+----+--------+------------+------------+-------------+----------+-------------+ |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 | | +--------------------------------+----+--------+------------+------------+-------------+----------+-------------+ |Zeituberschreitung | | X | | X | X | | | +--------------------------------+----+--------+------------+------------+-------------+----------+-------------+ |Watchdog | | X | | X | X | | X | +--------------------------------+----+--------+------------+------------+-------------+----------+-------------+ |Beendigung aufgrund von OOM | | 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 aquivalenten 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) fur Details. Fur langlaufende Dienste wird empfohlen, dies auf on-failure zu setzen, um die Zuverlassigkeit zu erhohen, indem die automatische Wiederherstellung bei Fehlern versucht wird. Fur Dienste, die sich nach eigenen Kriterien beenden (und sofortige Neustarts vermeiden) konnen, ist on-abnormal eine alternative Wahl. RestartMode= Akzeptiert einen Zeichenkettenwert, der festlegt, wie ein Dienst neu gestartet werden soll: o Falls auf normal gesetzt (die Vorgabe), wird der Dienst neugestartet, indem er durch einen fehlgeschlagenen/inaktiven Zustand geht. Hinzugefugt in Version 254. o Falls auf direct gesetzt, geht der Dienst wahrend des automatischen Neustarts direkt in den aktivierenden Status uber und uberspringt den fehlgeschlagenen/inaktiven Zustand. ExecStopPost= wird weiterhin aufgerufen. OnSuccess= und OnFailure= werden ubersprungen. Diese Option ist in den Fallen nutzlich, bei denen eine Abhangigkeit vorubergehend fehlschlagen kann, aber es nicht gewunscht ist, dass diese temporaren Fehlschlage zum Fehlschlagen der abhangigen Units fuhren. Abhangige Units werden nicht uber diese temporaren Fehlschlage informiert. Hinzugefugt in Version 254. o Falls auf debug gesetzt, wird der Diensteverwalter Meldungen mit Bezug zu der Unit auf der Stufe >>Debug<< protokollieren, wahrend automatisierte Neustarts versucht werden, bis entweder der Dienst die Ratenbegrenzung erreicht hat oder er erfolgreich ist. Auch wird die Umgebungsvariable $DEBUG_INVOCATION=1 fur die Unit gesetzt. Dies ist nutzlich, um zusatzliche Informationen zu erhalten, wenn ein Dienst beim Starten fehlschlagt, ohne proaktiv oder dauerhaft die Protokollierung in Systemd auf der Fehlersuchstufe zu aktivieren, da diese viele Meldungen produziert. Ansonsten ist dies zum Modus normal aquivalent. Hinzugefugt in Version 257. Hinzugefugt in Version 254. SuccessExitStatus= Akzeptiert eine Liste von Exit-Statusdefinitionen, die als erfolgreiche Beendigung betrachtet werden, wenn sie vom Hauptdiensteprozess zuruckgeliefert werden, zusatzlich zu dem normalen Exit-Status 0 und, ausser fur Type=oneshot, den Signalen SIGHUP, SIGINT, SIGTERM und SIGPIPE. Exit-Statusdefinitionen konnen numerische Exit-Stati, Beendigungs-Statusnamen oder Beendigungssignalnamen, getrennt durch Leerzeichen, sein. Siehe den Abschnitt >>PROZESS-EXIT-CODES<< in systemd.exec(5) fur eine Liste von Beendigungs-Statusnamen (fur diese Einstellung sollte nur der Teil ohne den >>EXIT_<< oder >>EX_<<-Anfang verwandt werden). Siehe signal(7) fur eine Liste der Signalnamen. Beachten Sie, dass diese Einstellung nicht die Zuordnung zwischen numerischen Exit-Stati und ihren Namen andert, d.h. unabhangig 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 zusammengefuhrt. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird diese Liste zuruckgesetzt und alle vorherigen Zuweisungen zu dieser Option haben keinen Effekt. Beispiel 1. Ein Dienst mit der Einstellung SuccessExitStatus= SuccessExitStatus=TEMPFAIL 250 SIGKILL Exit-Status 75 (TEMPFAIL), 250 und das Beendigungssignal wird SIGKILL als saubere Dienstebeendigung betrachtet. Beachten Sie: systemd-analyze exit-codes kann zur Auflistung der Exit-Stati und zur Ubersetzung zwischen numerischen Code-Werten und Namen verwandt werden. Hinzugefugt in Version 189. RestartPreventExitStatus= Akzeptiert eine Liste von Exit-Statusdefinitionen, die automatische Diensteneustarts verhindern, wenn sie von dem Hauptdienstprozess zuruckgeliefert werden, unabhangig von der mit Restart= konfigurierten Neustarteinstellung. Exit-Statusdefinitionen konnen numerische Beendigungsstati, Beendigungstatusnamen oder Beendigungssignalnamen, getrennt durch Leerzeichen, sein. Standardmassig ist dies die leere Liste, so dass standardmassig kein Exit-Status von der konfigurierten Neustartlogik ausgeschlossen ist. Falls diese Option mehr als einmal auftaucht, wird die Liste der Neustart-verhindernden Stati zusammengefuhrt. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird diese Liste zuruckgesetzt 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 (abhangig von Type=, PIDFile=, ) den anderweitig konfigurierten Hauptprozess. Hinzugefugt in Version 189. RestartForceExitStatus= Akzeptiert eine Liste von Exit-Statusdefinitionen, die automatische Diensteneustarts erzwingen, wenn sie von dem Hauptdienstprozess zuruckgeliefert werden, unabhangig von der mit Restart= konfigurierten Neustarteinstellung. Das Argumentenformat ist ahnlich zu RestartPreventExitStatus=. Beachten Sie, dass fur Dienste Type=oneshot ein erfolgreicher Exit-Status sie am automatischen Neustarten hindern wird, unabhangig davon, ob die entsprechenden Exit-Stati in dieser Option aufgefuhrt sind oder nicht. Hinzugefugt in Version 215. RootDirectoryStartOnly= Akzeptiert ein logisches Argument. Falls true, wird das Wurzelverzeichnis, das mit der Option RootDirectory= (siehe systemd.exec(5) fur weitere Informationen) konfiguriert ist, nur fur den mit ExecStart= gestarteten Prozess angewandt und nicht fur die verschiedenen anderen Befehle ExecStartPre=, ExecStartPost=, ExecReload=, ExecReloadPost=, ExecStop= und ExecStopPost=. Falls false, wird die Einstellung auf alle konfigurierten Befehle auf die gleiche Art angewandt. Standardmassig false. NonBlocking= Setzt den Schalter O_NONBLOCK fur alle uber Socket-basierte-Aktivierung ubergebenen Dateideskriptoren. Falls true, wird bei allen Dateideskriptoren >= 3 (d.h. allen ausser Stdin, Stdout, Stderr), ausschliesslich solcher, die uber die Dateideskriptorspeicherlogik (siehe FileDescriptorStoreMax= fur Details) ubergeben 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 nutzlich und hat auf Dateideskriptoren, die beispielsweise fruher in dem Dateideskriptorspeicher gespeichert wurden, keinen Effekt. Standardmassig false. Falls die gleiche Socket-Unit so konfiguriert wurde, dass sie an mehrere Dienste-Unites ubergeben wird (mittels des nachfolgend beschriebenen Sockets=) und diese Dienste verschiedene Konfigurationen NonBlocking= haben, dann beachten Sie, dass der genaue Zustand von O_NONBLOCK von der Reihenfolge, in der diese Dienste aufgerufen werden, abhangt und sich moglicherweise andert, nachdem der Dienste-Code bereits Besitz von dem Socket-Dateideskriptor genommen hat, einfach deshalb, weil der Zustand O_NONBLOCK von allen Dateideskriptoren, die ihn referenzieren, gemeinsam benutzt wird. Daher ist es wesentlich, dass alle Dienste, die den gleichen Socket verwenden, die gleiche Konfiguration NonBlocking= verwenden und diesen Schalter auch nicht in dem Dienste-Code andern. NotifyAccess= Steuert den Zugriff auf das Statusbenachrichtigungs-Socket, wie es uber 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 offnen, wenn Type=notify/Type=notify-reload oder WatchdogSec= verwandt wird (siehe oben). Falls jene Optionen verwandt werden, aber NotifyAccess= nicht konfiguriert ist, werden sie implizit auf main gesetzt. Beachten Sie, dass sd_notify()-Benachrichtigungen nur Units korrekt zugeordnet werden konnen, 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 ursprunglich 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, konnte der Diensteverwalter nicht in der Lage sein, die Nachricht korrekt der Unit zuzuordnen und wird sie daher ignorieren, selbst falls NotifyAccess=all fur sie gesetzt ist. Um daher alle Ressourcenwettlaufe, die mit Nachschlagen von Units des Clients verknupft 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 zuruckkehrt. Die Verwendung von sd_notify_barrier() wird fur Clients benotigt, die nicht durch den Diensteverwalter aufgerufen werden, andernfalls ist dieser Synchronisationsmechanismus zur Zuordnung von Benachrichtigungen zu Units unnotig. 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 naturlich der verschiedenen Unit-Namensendungen), an den aufgerufenen Prozess ubergeben werden. Beachten Sie, dass der gleiche Socket-Dateideskriptor simultan an mehrere Prozesse ubergeben werden kann. Beachten Sie auch, dass ein anderer Dienst auf eingehenden Socket-Verkehr aktiviert werden kann als derjenige, der schliesslich 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 zusammengefuhrt. Beachten Sie, dass das Bereinigen der Liste (beispielsweise durch Zuweisung der leeren Zeichenkette zu dieser Option) nicht unterstutzt wird, sobald die Option einmal gesetzt wurde. FileDescriptorStoreMax= Konfiguriert, wie viele Dateideskriptoren in dem Diensteverwalter fur den Dienst mittels >>FDSTORE=1<<-Nachrichten von sd_pid_notify_with_fds(3) gespeichert werden konnen. Dies ist zur Implementierung von Diensten nutzlich, die sich nach einer expliziten Anfrage oder einem Absturz ohne Zustandsverlust neu starten konnen. Alle offenen Sockets und andere Dateideskriptoren, die wahrend des Neustarts nicht geschlossen werden sollen, konnen auf diese Art gespeichert werden. Der Anwendungszustand kann entweder in eine Datei in RuntimeDirectory= serialisiert oder in einem memfd_create(2)-Speicherdateideskriptor gespeichert werden. Standardmassig 0, d.h. kein Dateideskriptor kann im Diensteverwalter gespeichert werden. Alle dem Diensteverwalter von einem bestimmten Dienst ubergebenen Dateideskriptoren werden beim nachsten Neustart des Dienstes an den Hauptprozess des Dienstes zuruckgegeben (siehe sd_listen_fds(3) fur Details uber das genaue verwandte Protokoll und die Reihenfolge, in der Dateideskriptoren ubergeben werden). Alle an den Diensteverwalter ubergebenen Dateideskriptoren werden automatisch geschlossen, wenn POLLHUP oder POLLERR auf ihnen gesehen wird oder wenn der Dienst vollstandig gestoppt wird und kein Auftrag in der Warteschlange ist oder fur ihn ausgefuhrt wird (letzteres kann mit FileDescriptorStorePreserve= angepasst werden, siehe unten). Falls diese Option verwandt wird, sollte NotifyAccess= (siehe oben) gesetzt werden, um Zugriff auf den von Systemd bereitgestellten Benachrichtigungs-Socket zu offnen. Falls NotifyAccess= nicht gesetzt ist, wird es implizit auf main gesetzt. Der Befehl fdstore von systemd-analyze(1) kann zur Auflistung des aktuellen Inhalts des Dateideskriptorspeichers eines Dienstes verwandt werden. Beachten Sie, dass der Diensteverwalter die in dem Dateideskriptorspeicher gespeicherten Dateieskriptoren nur an Prozesse des eigenen Dienstes weitergeben wird, niemals an andere Clients mittels IPC oder ahnlichem. Allerdings erlaubt er nicht privilegierten Clients, die Liste der aktuell offenen Dateideskriptoren eines Dienstes abzufragen. Innerhalb der referenzierten Dateien konnen daher sensible Daten platziert werden, sie sollten aber nicht an die Metadaten der gespeicherten Dateideskriptoren angehangt werden (z.B. Teil des Dateinamens sein). Falls diese Option auf einen von Null verschiedenen Wert gesetzt wird, dann wird die Umgebungsvariable $FDSTORE fur von diesem Dienst aufgerufene Prozesse gesetzt. Siehe systemd.exec(5) zu Details. Fur weitere Informationen uber den Dateideskriptorspeicher siehe den Uberblick uber den Dateideskriptorspeicher[1]. Hinzugefugt in Version 219. FileDescriptorStorePreserve= Akzeptiert entweder no, yes oder restart und steuert, wann der Dateideskriptorspeicher des Dienstes freigegeben werden soll (d.h. wann die enthaltenen Dateideskriptoren geschlossen werden sollen, falls vorhanden). Falls auf no gesetzt, wird der Dateideskriptorspeicher automatisch freigegeben, wenn der Dienst gestoppt wird; bei (der Vorgabe) restart wird er solange vorgehalten, wie die Unit weder inaktiv noch fehlgeschlagen ist oder ein Auftrag fur den Dienst in der Warteschlange steht oder es erwartet wird, dass der Dienst neu gestartet wird. Falls yes, wird der Dateideskriptorspeicher vorgehalten und die Garbage Collection der Unit wird deaktiviert. Letzteres ist nutzlich, um Eintrage in dem Dateideskriptorspeicher anzuheften, bis die Unit entfernt wird, sich der Diensteverwalter beendet oder der Dateideskriptor EPOLLHUP oder EPOLLERR erhalt. Verwenden Sie systemctl clean --what=fdstore , um den Dateideskriptorspeicher explizit freizugeben. Hinzugefugt in Version 254. USBFunctionDescriptors= Konfiguriert den Ort einer Datei, die Deskriptoren fur USB FunctionFS[2], fur die Implementierung von USB-Gadget-Funktionen, enthalt. Dies wird nur in Zusammenhang mit einer Socket-Unit mit konfiguriertem ListenUSBFunction= verwandt. Der Inhalt dieser Datei wird nach deren Offnen in die Datei ep0 geschrieben. Hinzugefugt in Version 227. USBFunctionStrings= Konfiguriert den Ort einer Datei, die USB-FunctionFS-Zeichenketten enthalt. Das Verhalten ist zu obiger USBFunctionDescriptors= ahnlich. Hinzugefugt in Version 227. OOMPolicy= Konfiguriert die Richtlinie fur die Speichererschopfungs- (OOM-)Beendigung fur den Kernel und den OOM-Klller im Anwendungsraum systemd-oomd.service(8). Wenn unter Linux der Speicher so knapp wird, dass der Kernel Schwierigkeiten bekommt, Speicher fur sich selbst zu reservieren, dann kann er sich entscheiden, laufende Prozesse zu beenden, um Speicher freizugeben und den Speicherdruck zu reduzieren. Beachten Sie, dass systemd-oomd.service(8) eine flexiblere Losung ist, die zu verhindern versucht, dass Speichererschopfungssituationen im Anwendungsraum auftreten, nicht nur im Kernel, indem versucht wird, Dienste fruher zu beenden, bevor der Kernel agieren musste. Diese Einstellung akzeptiert entweder continue, stop oder kill. Falls auf continue gesetzt und ein Prozess in der Unit vom OOM-Killer beendet wird, wird dies protokolliert aber die Unit lauft weiter. Falls auf stop gesetzt, wird das Ereignis protokolliert, und die Prozesse der Unit werden sauber durch den Diensteverwalter beendet. Falls auf kill gesetzt und einer der Prozesse der Unit wird durch den OOM-Killer beendet, wird der Kernel angewiesen, auch alle verbleibenden Prozesse der Unit durch Setzen des Attributes memory.oom.group auf 1 durch den OOM-Killer zu beenden; siehe auch die Kernelseite Control-Gruppe v2[3]. Im Falle von sowohl stop als auch kill endet der Diensteverwalter letztendlich im Fehlschlagzustand oom-kill, nachdem ein Restart= notwendig sein konnte. Standardmassig der Wert, auf den die Einstellung DefaultOOMPolicy= in systemd-system.conf(5) gesetzt ist, ausser 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 fur Prozessbeendigungen durch die Logik des OOM-Killers von Linux betrachtet werden sollen. Siehe systemd.exec(5) fur Details. Diese Einstellung gilt auch fur systemd-oomd.service(8). Ahnlich wie beim vom Kernel durchgefuhrten Kernel-OOM-Totungen bestimmt diese Einstellung den Zustand der Unit, nachdem systemd-oomd(8) eine ihr zugeordnete Cgroup beendet hat. Hinzugefugt in Version 243. OpenFile= Akzeptiert ein Argument der Form >>Pfad[:dd-Name:Optionen], wobei: o >>Pfad<< ein Pfad zu einer Datei oder einem AF_UNIX-Socket im Dateisystem ist; o >>dd-Name<< ein Name ist, der dem Dateideskriptor zugeordnet wird; der Name darf ASCII-Zeichen enthalten, aber keine Steuerzeichen und >>:<< und darf hochsten 256 Zeichen lang sein; er ist optional und standardmassig der Dateiname, falls nicht angegeben; o >>Optionen<< ist eine Kommata-getrennte Liste von Zugriffsoptionen; mogliche Werte sind >>read-only<<, >>append<<, >>truncate<<, >>graceful<<; falls nicht festgelegt, werden Dateien im Modus rw geoffnet; falls >>graceful<< festgelegt ist, werden Fehler wahrend des Offnens von Dateien/Sockets ignoriert. Die mehrfache Angabe der gleichen Option wird als Fehler behandelt. Die Datei oder der Socket wird durch den Diensteverwalter geoffnet und der Dateideskriptor wird an den Dienst weitergegeben. Falls der Pfad ein Socket ist, wird connect() mit ihm aufgerufen. Siehe sd_listen_fds(3) fur weitere Details, wie diese Dateideskriptoren erlangt werden. Diese Einstellung ist nutzlich, um Diensten den Zugriff auf Dateien/Sockets zu erlauben, auf die sie selbst keinen Zugriff haben (da sie in einem anderen Einhangenamensraum laufen, uber keine Privilegien verfugen ). Diese Einstellung kann mehrfach angegeben werden. In diesem Fall werden alle festgelegten Pfade geoffnet und die Dateideskriptoren an den Dienst ubergeben. Falls die leere Zeichenkette zugewiesen wird, wird die gesamte vorher definierte Liste offener Dateien zuruckgesetzt. Hinzugefugt in Version 253. ReloadSignal= Konfiguriert das UNIX-Prozessignal, das an den Hauptprozess des Dienstes gesandt werden soll, wenn dieser zum Neuladen seiner Konfiguration gebeten werden soll. Standardmassig SIGHUP. Diese Option hat nur eine Auswirkung, wenn auch Type=notify-reload verwandt wird, siehe oben. Hinzugefugt in Version 253. RefreshOnReload= Akzeptiert ein logisches Argument oder eine Liste von in systemd.exec(5) definierten Ressourcen. Mogliche Werte sind extensions und credentials, getrennt durch Leerzeichen. Wird der Liste ein einzelnes Tildezeichen (>>~<<) vorangestellt, wird die Auswirkung invertiert. Standardmassig extensions. Eine leere Zuweisung setzt die Liste auf die Vorgabe zuruck. Falls aktiviert, werden die entsprechenden Ressourcen (ExtensionImages=/ExtensionDirectories= fur extensions und LoadCredential=/ImportCredential=/ SetCredential= (zusammen mit ihren Encrypted-Gegenstucken) fur credentials) beim Neuladen des Dienstes aufgefrischt. Falls yes, werden alle oben aufgefuhrten Resourcen, die vom Dienst verwandt werden, aufgefrischt. Falls diese Option explizit gesetzt ist und die entsprechenden Ressourcen verwandt werden, kann der Dienst insbesondere ohne einen tatsachlichen Neulademechanismus (ExecReload= oder Type=notify-reload) neugeladen werden, um den Hauptprozess zu benachrichtigen. In diesem Fall wird das Neuladen sofort nach der Auffrischung als abgeschlossen betrachtet. Hinzugefugt in Version 260. Lesen Sie systemd.unit(5), systemd.exec(5) und systemd.kill(5) fur weitere Einstellungen. BEFEHLSZEILEN Dieser Abschnitt beschreibt die Auswertung der Befehlszeile und Variablen- und Kennzeichnerersetzung fur die Optionen ExecStart=, ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop= ExecStopPost= und ExecCondition=. Durch mehrfache Verwendung der relevanten Einstellungen konnen mehrere Befehlszeilen angegeben werden. Der Schutz jeder Befehlszeile wird gemass der im Abschnitt >>Quoting<< in systemd.syntax(7) beschriebenen Regeln entfernt. Der erste Eintrag wird der auszufuhrende Befehl und nachfolgende Eintrage die Argumente. Diese Syntax ist von der Shell-Syntax inspiriert, aber nur die in den nachfolgenden Absatzen beschriebenen Metazeichen und Erweiterungen werden verstanden und die Expansion von Variablen unterscheidet sich. Insbesondere werden Umleitungen mittels >><<<, >><<<<, >>><< und >>>><<, Pipes mittels >>|<<, das Ausfuhren von Programmen im Hintergrund und andere Elemente der Shell-Syntax nicht unterstutzt. Der auszufuhrende Befehl darf Leerzeichen enthalten, aber Steuerzeichen sind nicht erlaubt. Jedem Befehl kann eine Reihe von besonderen Zeichen vorangestellt werden: Tabelle 2. Besondere Prafixe fur Programme +---------+-------------------------------+ |Prafix | Effekt | +---------+-------------------------------+ |"@" | Falls dem Programmpfad ein | | | >>@<< vorangestellt wird, | | | wird der zweite angegebene | | | Parameter als argv[0] (statt | | | des tatsachlichen | | | Dateinamens) an den | | | ausgefuhrten Prozess | | | ubergeben, gefolgt von den | | | weiteren angegebenen | | | Argumenten, ausser es wurde | | | auch >>|<< festgelegt, dann | | | wird eine | | | Anmelde-Shell-Semantik fur | | | die gestartete Shell | | | aktiviert, indem >>-<< | | | argv[0] vorangestellt wird. | +---------+-------------------------------+ |"-" | 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 | | | aquivalent zum Erfolg | | | betrachtet. | +---------+-------------------------------+ |":" | Falls dem Programmpfad ein | | | >>:<< vorangestellt ist, | | | erfolgt keine | | | Umgebungsvariablenersetzung | | | (wie unterhalb dieser Tabelle | | | beschrieben). | +---------+-------------------------------+ |"+" | Falls dem Programmpfad ein | | | >>+<< vorangestellt ist, wird | | | der Prozess mit vollen | | | Privilegien ausgefuhrt. In | | | diesem Modus werden die mit | | | User=, Group=, | | | CapabilityBoundingSet= oder | | | den verschiedenen | | | Dateisystemnamensraumoptionen | | | (wie PrivateDevices=, | | | PrivateTmp=) konfigurierten | | | Privilegienbeschrankungen fur | | | die aufgerufene Befehlszeile | | | nicht angewandt (betreffen | | | aber weiterhin jede andere | | | ExecStart=-, ExecStop=-, | | | -Zeilen). Beachten Sie | | | allerdings, dass dies nicht | | | die Optionen umgehen wird, | | | die auf die gesamte | | | Control-Gruppe wirken, wie | | | DevicePolicy=, siehe | | | systemd.resource-control(5) | | | fur die vollstandige Liste. | +---------+-------------------------------+ |"!" | Ahnlich zum oben besprochenen | | | Zeichen >>+<< ermoglicht | | | dieser den Aufruf von | | | Befehlszeilen mit erweiterten | | | Privilegien. Anders als >>+<< | | | andert das Zeichen >>!<< | | | exklusiv den Effekt von | | | User=, Group= und | | | SupplementaryGroups=, d.h. | | | nur die Absatze, 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 Anderung der | | | Berechtigungen dem | | | ausgefuhrten Prozess selbst | | | uberlassen bleibt. | +---------+-------------------------------+ |"|" | Falls >>|<< alleine als | | | ausfuhrbarer Pfad festgelegt | | | ist, wird die Standard-Shell | | | von User= aufgerufen. Falls | | | es als Prafix angegeben wird, | | | wird die Shell (>>-c<<) | | | verwandt, um das Programm | | | auszufuhren. Wird >>@<< damit | | | in Verbindung benutzt, wird | | | argv[0] der Shell >>-<< | | | vorangestellt, um die | | | Semantiken einer | | | Anmelde-Shell zu aktivieren. | +---------+-------------------------------+ >>@<<, >>|<<, >>-<<, >>:<< und eines aus >>+<>!<< konnen zusammen verwandt werden und in jeder Reihenfolge auftauchen. Allerdings durfen >>+<< und >>!<< nicht gleichzeitig zusammen festgelegt werden. Fur jeden Befehl muss das erste Argument entweder ein absoluter Pfad zu einem Programm oder ein einfacher Dateiname ohne Schragstriche sein. Falls der Befehl kein kompletter (absoluter) Pfad ist, wird er mittels eines festen, zum Zeitpunkt der Kompilierung bestimmten Suchpfades zu einem kompletten Pfad aufgelost. Suchverzeichnisse sind unter anderem /usr/local/bin/, /usr/bin/ und ihre sbin/-Gegenstucke (nur auf Systemen, die getrennte bin/ und sbin/ verwenden). Es ist daher sicher, nur den Programmnamen zu verwenden, falls das Programm sich in einem der >>Standard<<-Verzeichnisse befindet. Fur andere Falle muss ein absoluter Pfad verwandt werden. Tipp: Dieser Suchpfad kann mit systemd-path search-binaries-default abgefragt werden. Die Befehlszeile akzeptiert wie in systemd.unit(5) beschrieben >>%s<<-Kennzeichner. Ein Argument, das nur aus >>;<< besteht, muss maskiert werden, d.h. als >>\;<< angegeben werden. Grundlegende Umgebungsvariablenersetzung wird unterstutzt. Verwenden Sie auf der Befehlszeile >>${FOO}<< als Teil des Worts oder als einzelnes Wort, das dann geloscht und genau durch den Wert der Umgebungsvariablen (falls vorhanden), einschliesslich samtlichen 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 fuhrt. Fur diese Art von Expansion werden Anfuhrungszeichen beim Trennen in Worter berucksichtigt und anschliessend entfernt. Beispiel: Environment="EINS=eins" 'ZWEI=zwei zwei' ExecStart=echo $EINS $ZWEI ${ZWEI} Dies fuhrt /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 fuhrt 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<<. Ausser fur Befehle mit dem besonderen Prafix >>:<< vor dem Programm: Um ein wortliches Dollarzeichen zu ubergeben, verwenden Sie >>$$<<. Variablen, deren Wert zum Expansionszeitpunkt nicht bekannt ist, werden als leere Zeichenkette behandelt. Beachten Sie, dass das erste Argument (d.h. das auszufuhrende Programm) keine Variable sein darf. Variablen, die auf diese Art verwandt werden, konnen mittels Environment= und EnvironmentFile= definiert werden. Zusatzlich konnen Variablen, die im Abschnitt >>Umgebungsvariablen in erzeugten Prozessen<< in systemd.exec(5), die als >>statische Konfiguration<< betrachtet werden, verwandt werden (dies schliesst beispielsweise $USER, aber nicht $TERM ein). Beachten Sie, dass Shell-Befehlszeilen nicht direkt unterstutzt werden und >>|<< die Standard-Shell des Benutzers aufruft, was nicht deterministisch ist. Es wird empfohlen, die Shell-Implementierung explizit anzugeben, falls Portabilitat gewunscht ist. Beispiel: ExecStart=sh -c 'dmesg | tac' Beispiel: ExecStart=echo Eins ExecStart=echo "Zwei Zwei" Dies wird echo zwei Mal ausfuhren, jedes Mal mit einem Argument: >>eins<< bzw. >>zwei zwei<<. Da zwei Befehle angegeben sind, muss Type=oneshot verwandt werden. Beispiel: Type=oneshot ExecStart=:echo $USER ExecStart=-false ExecStart=+:@true $TEST Dies wird /usr/bin/echo mit dem wortlichen Argument >>$USER<< (>>:<< verhindert die Variablenexpansion) und /usr/bin/false (der Ruckgabewert wird ignoriert, da >>-<< das Prufen des Ruckgabewerts unterdrucken wird) und /usr/bin/true (mit erhohten Privilegien, mit >>$TEST<< als argv[0]) ausfuhren. Beispiel: ExecStart=echo / >/dev/null & \; \ ls Dies wird echo mit funf Argumenten ausfuhren: >>/<<, >>>/dev/null<<, >>&<<, >>;<< und >>ls<<. BEISPIELE Beispiel 3. Einfacher Dienst Die folgende Unit-Datei erstellt einen Dienst, der /usr/sbin/foo-daemon ausfuhrt. Da kein Type= angegeben ist, wird die Vorgabe Type=simple angenommen. Systemd wird annehmen, dass die Unit sofort nach Beginn der Ausfuhrung 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 lauft, bis der Dienst beendet wird. Falls das Programm sich selbst zum Daemon macht (d.h. Fork ausfuhrt), verwenden Sie bitte stattdessen Type=forking. Da kein ExecStop= angegeben wurde, wird Systemd SIGTERM an alle von diesem Dienst gestarteten Prozesse senden und nach einer Zeituberschreitung auch SIGKILL. Dieses Verhalten kann verandert werden, siehe systemd.kill(5) fur Details. Beachten Sie, dass dieser Unit-Typ keine Art von Benachrichtigung, wenn der Dienst seine Initialisierung abgeschlossen hat, enthalt. Dafur sollten Sie andere Unit-Typen, wie Type=notify/Type=notify-reload, falls der Dienst das Benachrichtigungsprotokoll von Systemd versteht, Type=forking, falls der Dienst sich selbst in den Hintergrund bringen kann oder Type=dbus, falls der Dienst einen DBus-Namen erlangt, sobald die Initialisierung abgeschlossen ist, in Betracht ziehen. Siehe unten. Beispiel 4. Oneshot-Dienst Manchmal sollen Units einfach eine Aktion ausfuhren, ohne aktive Prozesse zu behalten, wie beispielsweise eine Dateisystemuberprufung oder eine Aufraumaktion beim Systemstart. Dafur existiert Type=oneshot. Units dieser Art werden warten, bis der festgelegte Prozess sich beendet hat und dann auf einen inaktiven Status zuruckfallen. Die folgende Unit wird eine Aufraumaktion durchfuhren: [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 Ordnungsabhangigkeiten auf die Beendigung des Programms warten, bevor sie sich selbst starten. Die Unit wird zum Zustand >>inactive<< nach dem Abschluss der Ausfuhrung zuruckkehren und niemals den Zustand >>active<< erreichen. Das bedeutet, dass eine weitere Anfrage, die Unit zu starten, die Aktion erneut ausfuhren wird. Nur Units mit Type=oneshot durfen mehr als ein ExecStart= festgelegt haben. Fur Units mit mehreren Befehlen (Type=oneshot) werden alle Befehle erneut ausgefuhrt. Fur Type=oneshot sind Restart=always und Restart=on-success nicht erlaubt. Beispiel 5. Beendbarer Oneshot-Dienst Ahnlich zum Oneshot-Dienst gibt es manchmal Units, die ein Programm ausfuhren mussen, um etwas einzurichten, und dann ein anderes, um es herunterzufahren, aber es bleibt kein Prozess aktiv, wahrend 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 Abhangigkeit hereingezogen wird, ausgefuhrt werden soll, sondern nur beim ersten Mal. Dafur kennt Systemd die Einstellung RemainAfterExit=yes, die dazu fuhrt, 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 nutzlichsten. Mit Type=oneshot wird Systemd warten, bis die Startaktion abgeschlossen ist, bevor es die Unit als aktiv betrachtet, daher starten Abhangigkeiten erst nachdem die Startaktion erfolgreich war. Mit Type=simple werden die Abhangigkeiten sofort nach dem Absetzen der Startaktion gestartet. Die nachfolgende Unit stellt ein Beispiel fur 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 fuhren. Beispiel 6. Traditioneller forkender Dienst Viele traditionelle Daemons/Dienste bringen sich selbst in den Hintergrund (d.h. forken, daemonisieren sich), wenn sie starten. Setzen Sie Type=forking in der Unit-Datei des Dienstes, um diesen Betriebsmodus zu unterstutzen. Systemd wird den Dienst im Prozess der Initialisierung betrachten, wahrend das ursprungliche Programm noch lauft. 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 ursprunglichen Prozesses verbleibt. In diesem Fall wird die Variable $MAINPID in ExecReload=, ExecStop= usw. verfugbar 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 abschliesst. Andernfalls konnte 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=Mein einfacher Daemon [Service] Type=forking ExecStart=/usr/sbin/my-simple-daemon -d [Install] WantedBy=multi-user.target Bitte lesen Sie systemd.kill(5) fur Details, wie Sie die Art, wie Systemd die Dienste beendet, beeinflussen konnen. Beispiel 7. DBus-Dienste Fur 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 Fur 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) fur Details, wie Sie die Art, wie Systemd die Dienste beendet, beeinflussen konnen. Beispiel 8. Dienste, die Systemd uber ihre Initialisierung benachrichtigen Type=simple-Dienste sind wirklich einfach zu schreiben, haben aber den grossen Nachteil, dass Systemd nicht feststellen kann, wann die Initialisierung des gegebenen Dienstes abgeschlossen ist. Aus diesem Grund unterstutzt Systemd ein einfaches Benachrichtigungsprotokoll, das es Daemons erlaubt, Systemd daruber in Kenntnis zu setzen, dass sie initialisiert sind. Verwenden Sie dafur Type=notify oder Type=notify-reload. Eine typische Dienste-Datei fur solch einen Daemon sahe wie folgt aus: [Unit] Description=Einfacher Benachrichtigungsdienst [Service] Type=notify-reload ExecStart=/usr/sbin/simple-notifying-service [Install] WantedBy=multi-user.target Beachten Sie, dass der Daemon das Benachrichtigungsprotokoll von Systemd unterstutzen muss, da ansonsten Systemd glauben wird, dass der Dienst noch nicht gestartet wurde und ihn nach einer Zeituberschreitung toten wird. Fur ein Beispiel, wie transparent ein Daemon aktualisiert wird, um dieses Protokoll zu unterstutzen, 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) fur Details, wie Sie die Art, wie Systemd die Dienste beendet, beeinflussen konnen. Um Code-Duplizierung zu vermeiden, sollte wenn moglich vorzugsweise sd_notify(3) verwandt werden, insbesondere wenn auch andere durch libsystemd(3) bereitgestellte APIs verwandt werden. Beachten Sie aber, dass das Benachrichtigungsprotokoll sehr einfach und gemass dem Schnittstellen-Portabilitats- und -Stabilitatsversprechen[4] garantiert stabil ist, so dass es durch Dienste ohne externe Abhangigkeiten reimplementiert werden kann. Fur ein in sich geschlossenes Beispiel siehe sd_notify(3). SIEHE AUCH systemd(1), systemctl(1), systemd-system.conf(5), systemd.unit(5), systemd.exec(5), systemd.resource-control(5), systemd.kill(5), systemd.directives(7), systemd-run(1) ANMERKUNGEN 1. Dateideskriptorspeicher https://systemd.io/FILE_DESCRIPTOR_STORE 2. USB FunctionFS https://docs.kernel.org/usb/functionfs.html 3. Control-Gruppe v2 https://docs.kernel.org/admin-guide/cgroup-v2.html 4. Schnittstellenportabilitats- und -stabilitatszusage https://systemd.io/PORTABILITY_AND_STABILITY/ UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 260.2 SYSTEMD.SERVICE(5)