.\" -*- coding: UTF-8 -*- '\" t .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH SYSTEMD\&.SERVICE 5 "" "systemd 247" systemd.service .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH BEZEICHNUNG systemd.service \- Dienste\-Unit\-Konfiguration .SH ÜBERSICHT .PP \fIDienst\fP\&.service .SH BESCHREIBUNG .PP Eine Unit\-Konfigurationsdatei, deren Name in »\&.service« endet, kodiert Informationen über einen von Systemd gesteuerten und überwachten Prozess\&. .PP Diese Handbuchseite listet die für diesen Unit\-Typ spezifischen Konfigurationsoptionen auf\&. Siehe \fBsystemd.unit\fP(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\&. .PP Zusätzliche Optionen sind in \fBsystemd.exec\fP(5), das die Ausführungsumgebung, in der die Befehle ausgeführt werden und in \fBsystemd.kill\fP(5), das die Art der Beendigung der Prozesse des Dienstes definiert und in \fBsystemd.resource\-control\fP(5), das die Ressourcensteuerungseinstellungen für die Prozesse des Dienstes konfiguriert, aufgeführt\&. .PP Falls ein Dienst unter einem bestimmten Namen angefordert wird, aber keine Unit\-Konfigurationsdatei gefunden wird, schaut Systemd nach einem SysV\-Init\-Skript mit dem gleichen Namen (ohne die Endung \&.service) und erstellt dynamisch eine Dienste\-Unit aus diesem Skript\&. Dies ist zur Kompatibilität mit SysV nützlich\&. Beachten Sie, dass diese Kompatibilität recht umfangreich, aber nicht 100% ist\&. Für Details über die Inkompatibilitäten, siehe das Dokument \m[blue]\fBInkompatibilitäten mit SysV\fP\m[]\&\s-2\u[1]\d\s+2\&. .PP Der Befehl erlaubt das dynamische und flüchtige Erstellen von »\&.service«\- und »\&.scope«\-Units auf der Befehlszeile\&. .SH DIENSTEVORLAGEN .PP \fBsystemd\fP\-Dienste können ein einzelnes Argument über die Syntax »\fIDienst\fP@\fIArgument\fP\&.service« akzeptieren\&. Solche Dienste heißen »instanziierte« Dienste, während die Unit\-Definition ohne den Parameter \fIArgument\fP »Vorlage« genannt wird\&. Eine Beispiel könnte die Dienstevorlage dhcpcd@\&.service sein, die eine Netzwerkschnittstelle als Parameter akzeptiert, um einen instanziierten Dienst zu formen\&. Innerhalb dieser Dienstedatei kann auf diesen Parameter oder den »Instanzennamen« mit Kennzeichnern »%« zugegriffen werden\&. Siehe \fBsystemd.unit\fP(5) für Details\&. .SH "AUTOMATISCHE ABHÄNGIGKEITEN" .SS "Implizite Abhängigkeiten" .PP Die folgenden Abhängigkeiten werden implizit hinzugefügt: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Dienste mit \fIType=dbus\fP erlangen automatisch Abhängigkeiten des Typs \fIRequires=\fP und \fIAfter=\fP von dbus\&.socket\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Socket\-aktivierte Dienste werden automatisch nach ihren aktivierenden \&.socket\-Units mittels einer automatischen \fIAfter=\fP\-Abhängigkeit sortiert\&. Dienste ziehen auch alle in \fISockets=\fP aufgeführten \&.socket\-Units mittels automatischer \fIWants=\fP\- und \fIAfter=\fP\-Abhängigkeiten herein\&. .RE .PP Zusätzliche implizite Abhängigkeiten als Ergebnis der Ausführung und der gemäß \fBsystemd.exec\fP(5) und \fBsystemd.resource\-control\fP(5) dokumentierten Ressourcen\-Steuerungsparameter können hinzugefügt werden. .SS Standardabhängigkeiten .PP Die folgenden Abhängigkeiten werden hinzugefügt, es sei denn, \fIDefaultDependencies=no\fP ist gesetzt: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Dienste\-Units werden Abhängigkeiten des Typs \fIRequires=\fP und \fIAfter=\fP von sysinit\&.target, eine Abhängigkeit des Typs \fIAfter=\fP on basic\&.target sowie Abhängigkeiten vom Typ \fIConflicts=\fP und \fIBefore=\fP 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\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Instanziierten Dienste\-Units (d\&.h\&. Dienste\-Units mit einem »@« in ihrem Namen) wird standardmäßig eine vorlagenbezogene Scheiben\-Unit zugewiesen (siehe \fBsystemd.slice\fP(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 \fIDefaultDependencies=no\fP in der Vorlagen\-Unit und definieren entweder Ihre eigene, vorlagenbezogene Scheiben\-Unit\-Datei, die auch \fIDefaultDependencies=no\fP setzt oder setzen \fISlice=system\&.slice\fP (oder eine andere geeignete Scheibe) in der Vorlagen\-Unit\&. Siehe auch \fBsystemd.resource\-control\fP(5)\&. .RE .SH OPTIONEN .PP Dienstedateien müssen einen Abschnitt »[Service]« enthalten, der Informationen über den Dienst und den Prozess, den er überwacht, zusammenträgt\&. Eine Reihe von Optionen, die in diesem Abschnitt genutzt werden können, werden mit anderen Unit\-Typen gemeinsam benutzt\&. Diese Optionen sind in \fBsystemd.exec\fP(5), \fBsystemd.kill\fP(5) und \fBsystemd.resource\-control\fP(5) beschrieben\&. Die für den Abschnitt »[Service]« von Dienste\-Units spezifischen Optionen sind: .PP \fIType=\fP .RS 4 Konfiguriert den Prozessstarttyp für diese Dienste\-Unit\&. Einer aus \fBsimple\fP, \fBexec\fP, \fBforking\fP, \fBoneshot\fP, \fBdbus\fP, \fBnotify\fP oder \fBidle\fP: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Falls auf \fBsimple\fP gesetzt ist (die Vorgabe, falls \fIExecStart=\fP angegeben ist, aber weder \fIType=\fP noch \fIBusName=\fP gesetzt sind), wird der Diensteverwalter die Unit als gestartet betrachten, sobald der Hauptdiensteprozess mittels »fork« erzeugt wurde\&. Es wird erwartet, dass der mit \fIExecStart=\fP 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 \fBsystemctl start\fP für \fBsimple\fP\-Dienste Erfolg melden werden, selbst wenn das Programm des Dienstes nicht erfolgreich aufgerufen werden kann (beispielsweise weil der ausgewählte \fIUser=\fP nicht existiert oder das Programm des Dienstes fehlt)\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Der Typ \fBexec\fP ist ähnlich zu \fBsimple\fP, 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: \fBsimple\fP fährt einfach mit weiteren Aufträgen fort, direkt nachdem \fBfork()\fP zurückkehrt, während \fBexec\fP nicht fortfahren wird, bevor sowohl \fBfork()\fP als auch \fBexecve()\fP im Diensteprozess erfolgreich waren\&.) Beachten Sie, dass dies bedeutet, dass die Befehlszeile \fBsystemctl start\fP für \fBexec\fP\-Dienste einen Fehlschlag melden wird, wenn das Programm des Dienstes nicht erfolgreich aufgerufen werden kann (beispielsweise weil der ausgewählte \fIUser=\fP nicht existiert oder das Diensteprogramm fehlt)\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Falls auf \fBforking\fP gesetzt, wird erwartet, dass der mit \fIExecStart=\fP konfigurierte Prozess \fBfork()\fP 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 \fIPIDFile=\fP 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\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Das Verhalten von \fBoneshot\fP ist ähnlich zu \fBsimple\fP, allerdings wird der Diensteverwalter die Unit als hochgebracht betrachten, nachdem sich der Hauptprozess beendet hat\&. Er wird dann nachfolgende Units starten\&. \fIRemainAfterExit=\fP ist für diesen Dienstetyp besonders nützlich\&. \fIType=\fP\fBoneshot\fP ist die implizierte Vorgabe, falls weder \fIType=\fP noch \fIExecStart=\fP angegeben ist\&. Beachten Sie, dass bei der Verwendung dieser Option ohne \fIRemainAfterExit=\fP 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 \fIRemainAfterExit=\fP nicht gesetzt hat), dieser danach nicht als gestartet sondern als tot angezeigt wird\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Verhalten von \fBdbus\fP ist ähnlich zu \fBsimple\fP; allerdings wird erwartet, dass der Dienst einen Namen auf dem D\-Bus\-Bus erlangt, wie dies in \fIBusName=\fP 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 \fIBusName=\fP 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 \fBSIGTERM\fP (oder ein anderes, in \fIKillSignal=\fP konfiguriertes Signal) im Ergebnis zu erhalten\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Das Verhalten von \fBnotify\fP ist ähnlich zu \fBexec\fP, allerdings wird erwartet, dass der Dienst mittels \fBsd_notify\fP(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 \fINotifyAccess=\fP (siehe unten) auf offenen Zugriff auf den von Systemd bereitgestellten Benachrichtigungs\-Socket gesetzt werden\&. Falls \fINotifyAccess=\fP fehlt oder auf \fBnone\fP gesetzt ist, wird er zwangsweise auf \fBmain\fP gesetzt\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Das Verhalten von \fBidle\fP ist sehr ähnlich zu \fBsimple\fP; allerdings wird die tatsächliche Ausführung des Diensteprogramms verzögert, bis alle aktiven Aufträge abgefertigt sind\&. Dadurch wird vermieden, dass die Ausgabe von Shell\-Diensten mit der Statusausgabe auf der Konsole vermischt wird\&. Beachten Sie, dass dieser Typ nur zur Verbesserung der Konsolenausgabe nützlich ist, er ist nicht als allgemeines Werkzeug zum Sortieren von Units nützlich und der Effekt dieses Dienstetyps unterliegt einer Zeitüberschreitung von 5 s, nach der das Diensteprogramm auf jeden Fall ausgeführt wird\&. .RE .sp Es wird im Allgemeinen empfohlen, \fIType=\fP\fBsimple\fP 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 \fBnotify\fP oder \fBdbus\fP (Letzteres nur in dem Fall, in dem der Dienst eine D\-Bus\-Schnittstelle bereitstellt) die bevorzugten Optionen, da sie dem Diensteprogramm genau einzuplanen erlauben, wann der Dienst als erfolgreich gestartet betrachtet werden soll und wann mit den nachfolgenden Units fortgefahren werden soll\&. Der Dienstetyp \fBnotify\fP benötigt explizite Unterstützung im Programmcode des Dienstes (da \fBsd_notify()\fP oder eine äquivalente API zum geeigneten Zeitpunkt durch den Dienst aufgerufen werden muss) \(em falls dies nicht unterstützt wird, ist \fBforking\fP eine Alternative: es unterstützt das Startprotokoll traditioneller UNIX\-Dienste\&. Schließlich kann \fBexec\fP eine Option für die Fälle sein, in denen es ausreicht, sicherzustellen, dass das Diensteprogramm aufgerufen wurde und in denen das Diensteprogramm selbst keine oder nur sehr geringe Initialisierungen durchführt (und diese höchstwahrscheinlich erfolgreich sind)\&. Beachten Sie, dass die Verwendung aller von \fBsimple\fP 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 \fBsimple\fP verschiedene Typen zu verwenden\&. (Es wird im Allgemeinen auch nicht empfohlen, \fBidle\fP oder \fBoneshot\fP für langlaufende Dienste zu verwenden\&.) .RE .PP \fIRemainAfterExit=\fP .RS 4 Akzeptiert einen logischen Wert, der angibt, ob der Dienst, selbst wenn sich alle seine Prozesse beendet haben, als aktiv betrachtet werden sollte\&. Standardmäßig \fBno\fP\&. .RE .PP \fIGuessMainPID=\fP .RS 4 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 \fBType=forking\fP ist gesetzt und \fBPIDFile=\fP 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 \fByes\fP\&. .RE .PP \fIPIDFile=\fP .RS 4 Akzeptiert einen Pfad zur PID\-Datei des Dienstes\&. Für Dienste, bei denen \fIType=\fP auf \fBforking\fP 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\&. .RE .PP \fIBusName=\fP .RS 4 Akzeptiert einen D\-Bus\-Zielnamen, den dieser Dienst nutzen soll\&. Diese Option ist für Dienste verpflichtend, bei denen \fIType=\fP auf \fBdbus\fP 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 \fBsystemctl service\-log\-level/service\-log\-target\fP verwenden dies\&. .RE .PP \fIExecStart=\fP .RS 4 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)\&. .sp Es muss genau ein Befehl angegeben werden, außer \fIType=\fP ist auf \fBoneshot\fP gesetzt\&. Wenn \fIType=oneshot\fP 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 \fIExecStart=\fP angegeben ist, dann muss der Dienst \fIRemainAfterExit=yes\fP und mindestens eine gesetzte \fIExecStop=\fP\-Zeile haben\&. (Dienste, denen sowohl \fIExecStart=\fP als auch \fIExecStop=\fP fehlt, sind nicht gültig\&.) .sp 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: .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br \fBTabelle\ \&1.\ \&Besondere Präfixe für Programme\fP .TS allbox tab(:); lB lB. T{ Präfix T}:T{ Effekt T} .T& l l l l l l l l l l l l. T{ "@" T}:T{ 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\&. T} T{ "\-" T}:T{ 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\&. T} T{ ":" T}:T{ Falls dem Programmpfad ein »:« vorangestellt ist, erfolgt keine Umgebungsvariablenersetzung (wie in dem nachfolgenden Abschnitt »Befehlszeilen« beschrieben)\&. T} T{ "+" T}:T{ Falls dem Programmpfad ein »+« vorangestellt ist, wird der Prozess mit vollen Privilegien ausgeführt\&. In diesem Modus werden die mit \fIUser=\fP, \fIGroup=\fP, \fICapabilityBoundingSet=\fP oder den verschiedenen Dateisystemnamensraumoptionen (wie \fIPrivateDevices=\fP, \fIPrivateTmp=\fP) konfigurierten Privilegienbeschränkungen für die aufgerufene Befehlszeile nicht angewandt (betreffen aber weiterhin jede andere \fIExecStart=\fP\-, \fIExecStop=\fP\-, … \-Zeilen)\&. T} T{ "!" T}:T{ Ähnlich zum oben besprochenen Zeichen »+« ermöglicht dieser den Aufruf von Befehlszeilen mit erweiterten Privilegien\&. Anders als »+« ändert das Zeichen »!« exklusiv den Effekt von \fIUser=\fP, \fIGroup=\fP und \fISupplementaryGroups=\fP, d\&.h\&. nur die Absätze, die Benutzer\- und Gruppenberechtigungen betreffen\&. Beachten Sie, dass diese Einstellung mit \fIDynamicUser=\fP 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\&. T} T{ "!!" T}:T{ 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 \fIAmbientCapabilities=\fP\&. 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 \fISystemCallFilter=\fP und \fICapabilityBoundingSet=\fP 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 \fIAmbientCapabilities=\fP ü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\&. T} .TE .sp 1 »@«, »\-«, »:« 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\&. \fIExecStartPre=\fP, \fIExecStartPost=\fP, \fIExecReload=\fP, \fIExecStop=\fP und \fIExecStopPost=\fP\&. .sp 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\&. .sp Außer falls \fIType=forking\fP gesetzt ist, wird der über die Befehlszeile gestartete Prozess als Hauptprozess des Daemons betrachtet\&. .RE .PP \fIExecStartPre=\fP, \fIExecStartPost=\fP .RS 4 Zusätzliche Befehle, die vor bzw\&. nach dem Befehl in \fIExecStart=\fP gestartet werden\&. Syntax ist identisch zu \fIExecStart=\fP, außer dass mehrere Befehlszeilen erlaubt sind und die Befehle seriell einer nach dem anderen ausgeführt werden\&. .sp Falls einer dieser Befehle (dem nicht »\-« vorangestellt ist) fehlschlägt, wird der Rest nicht ausgeführt und die Unit als fehlgeschlagen betrachtet\&. .sp \fIExecStart=\fP\-Befehle werden nur ausgeführt, nachdem alle \fIExecStartPre=\fP\-Befehle, denen kein »\-« vorangestellt wurde, sich erfolgreich beendet haben\&. .sp \fIExecStartPost=\fP\-Befehle werden nur ausgeführt, nachdem die in \fIExecStart=\fP festgelegten Befehle erfolgreich gestartet wurden, wie durch \fIType=\fP festgelegt (d\&.h\&. der Prozess wurde für \fIType=simple\fP oder \fIType=idle\fP gestartet, der letzte \fIExecStart=\fP\-Prozess hat sich erfolgreich für \fIType=oneshot\fP beendet, der anfängliche Prozess hat sich für \fIType=forking\fP erfolgreich beendet, »READY=1« ist für \fIType=notify\fP gesetzt oder der \fIBusName=\fP ist für \fIType=dbus\fP genommen worden\&. .sp Beachten Sie, dass \fIExecStartPre=\fP nicht zum Starten von langlaufenden Prozessen verwandt werden darf\&. Alle von mittels \fIExecStartPre=\fP aufgerufenen Prozesse mittels Fork gestarteten Prozesse werden getötet, bevor der nächste Diensteprozess ausgeführt wird\&. .sp Beachten Sie, dass falls einer der in \fIExecStartPre=\fP, \fIExecStart=\fP oder \fIExecStartPost=\fP 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 \fIExecStopPost=\fP festgelegten Komponenten fortgefahren wird und die Befehle in \fIExecStop=\fP übersprungen werden\&. .sp Beachten Sie, dass die Ausführung von \fIExecStartPost=\fP zum Zwecke der \fIBefore=\fP/\fIAfter=\fP Ordnungsbeschränkungen berücksichtigt wird\&. .RE .PP \fIExecCondition=\fP .RS 4 Optionale Befehle, die vor dem Befehl/den Befehlen in \fIExecStartPre=\fP gestartet werden\&. Syntax ist identisch zu \fIExecStart=\fP, außer dass mehrere Befehlszeilen erlaubt sind und die Befehle seriell einer nach dem anderen ausgeführt werden\&. .sp Das Verhalten ist wie ein \fIExecStartPre=\fP und die Bedingungsprüfung erfolgt hybrid: wenn sich ein \fIExecCondition=\fP\-Befehl mit Exit\-Code 1 bis 254 (einschließlich) beendet, werden die verbleibenden Befehle übersprungen und die Unit wird \fInicht\fP als fehlgeschlagen markiert\&. Falls sich allerdings ein \fIExecCondition=\fP\-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 \fISuccessExitStatus=\fP passen, führen zur Ausführung des oder der nächsten Befehle\&. .sp Die gleiche Empfehlung, keine langlaufenden Prozesse in \fIExecStartPre=\fP auszuführen, gilt auch für \fIExecCondition=\fP\&. \fIExecCondition=\fP wird, falls eine Beendigung nicht Null oder unnormal erfolgt, beim Stoppen des Dienstes auch die in \fIExecStopPost=\fP aufgeführten Befehle ausführen, wie die oben beschriebenen\&. .RE .PP \fIExecReload=\fP .RS 4 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 \fIExecStart=\fP folgen\&. Die Verwendung dieser Einstellung ist optional\&. Festlegungs\- und Umgebungsvariablenersetzung wird hier mit dem gleichen Schema wie für \fIExecStart=\fP unterstützt\&. .sp Eine zusätzliche, besondere Umgebungsvariable wird gesetzt: falls bekannt, wird \fI$MAINPID\fP auf den Hauptprozess des Daemons gesetzt und kann für Befehlszeilen wie der folgenden benutzt werden: .sp .if n \{\ .RS 4 .\} .nf ExecReload=kill \-HUP $MAINPID .fi .if n \{\ .RE .\} .sp 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, \fIExecReload=\fP 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 \fBdbus\-broker\fP(1) Folgendes: .sp .if n \{\ .RS 4 .\} .nf ExecReload=busctl call org\&.freedesktop\&.DBus \e /org/freedesktop/DBus org\&.freedesktop\&.DBus \e ReloadConfig .fi .if n \{\ .RE .\} .RE .PP \fIExecStop=\fP .RS 4 Die zum Stoppen des mittels \fIExecStart=\fP gestarteten Dienstes zu verwendenden Befehle\&. Dieses Argument akzeptiert mehrere Befehlszeilen, die dem gleichen Schema wie oben für \fIExecStart=\fP 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 \fIKillMode=\fP beendet (siehe \fBsystemd.kill\fP(5))\&. Falls diese Option nicht angegeben ist, werden die Prozesse durch Senden des in \fIKillSignal=\fP oder \fIRestartKillSignal=\fP festgelegten Signals beendet, wenn das Beenden eines Dienstes angefragt wird\&. Festlegungs\- und Umgebungsvariablenersetzung wird unterstützt (einschließlich \fI$MAINPID\fP, siehe oben)\&. .sp 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 \fIKillMode=\fP und \fIKillSignal=\fP oder \fIRestartKillSignal=\fP getötet werden, kann dies zu einem unsauberen Stopp führen\&. Der angegebene Befehl sollte daher eine synchrone Aktion und nicht eine asynchrone sein\&. .sp Beachten Sie, dass die in \fIExecStop=\fP 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 \fIExecStart=\fP, \fIExecStartPre=\fP oder \fIExecStartPost=\fP festgelegten Befehle fehlschlug (oder ihm kein »\-« vorangestellt wurde, siehe oben) oder eine Zeitüberschreitung erfolgte\&. Verwenden Sie \fIExecStopPost=\fP, 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\&. \fI$MAINPID\fP wird nicht gesetzt sein, falls Systemd weiß, das sich der Hauptprozess zum Zeitpunkt des Aufrufs des Stopp\-Befehls beendet hat\&. .sp Diensteneustartanfragen sind als Stopp\-Aktionen gefolgt von Start\-Aktionen implementiert\&. Dies bedeutet, dass während einer Diensteneustartaktion \fIExecStop=\fP und \fIExecStopPost=\fP ausgeführt werden\&. .sp 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 \fIExecStopPost=\fP\&. .RE .PP \fIExecStopPost=\fP .RS 4 Zusätzliche Befehle, die ausgeführt werden, nachdem der Dienst beendet wurde\&. Dies schließt Fälle mit ein, bei denen die in \fIExecStop=\fP konfigurierten Befehle verwandt wurden, bei denen der Dienst kein definiertes \fIExecStop=\fP hat oder bei denen der Dienst unerwartet beendet wurde\&. Dieses Argument akzeptiert mehrere Befehlszeilen, die dem gleichen für \fIExecStart=\fP definierten Schema folgen\&. Die Verwendung dieser Einstellungen ist optional\&. Festlegungs\- und Umgebungsvariablenersetzung wird unterstützt\&. Beachten Sie, dass Befehle, die mit dieser Einstellung festgelegt werden \(en anders als \fIExecStop=\fP \(en aufgerufen werden, wenn ein Dienst nicht korrekt startet und wieder heruntergefahren wird\&. .sp 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\&. .sp 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 \fI$SERVICE_RESULT\fP, \fI$EXIT_CODE\fP und \fI$EXIT_STATUS\fP, aufgerufen werden, siehe \fBsystemd.exec\fP(5) für Details\&. .sp Beachten Sie, dass die Ausführung von \fIExecStopPost=\fP zum Zwecke der \fIBefore=\fP/\fIAfter=\fP Ordnungsbeschränkungen berücksichtigt wird\&. .RE .PP \fIRestartSec=\fP .RS 4 Konfiguriert die vor dem Neustart eines Dienstes zu schlafende Zeit (wie in \fIRestart=\fP konfiguriert)\&. Akzeptiert einen einheitenfreien Wert in Sekunden oder einen Zeitdauerwert wie »5min 20s«\&. Standardmäßíg 100 ms\&. .RE .PP \fITimeoutStartSec=\fP .RS 4 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 \fITimeoutStartFailureMode=\fP ab\&. Akzeptiert einen einheitenfreien Wert in Sekunden oder einen Zeitdauerwert wie »5min 20s«\&. Übergeben Sie »infinity«, um die Zeitüberschreitungslogik zu deaktivieren\&. Standardmäßig \fIDefaultTimeoutStartSec=\fP aus der Verwalterkonfigurationsdatei, außer wenn \fIType=oneshot\fP konfiguriert ist, dann wird die Zeitüberschreitung standardmäßig deaktiviert (siehe \fBsystemd\-system.conf\fP(5))\&. .sp Falls ein Dienst vom \fIType=notify\fP »EXTEND_TIMEOUT_USEC=…« sendet, kann dies dazu führen, dass die Startzeit sich über \fITimeoutStartSec=\fP hinauszieht\&. Der erste Empfang dieser Nachricht muss auftreten, bevor \fITimeoutStartSec=\fP überschritten wird und sobald die Startzeit sich über \fITimeoutStartSec=\fP 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 \fBsd_notify\fP(3))\&. .RE .PP \fITimeoutStopSec=\fP .RS 4 Diese Option dient zwei Zwecken\&. Zuerst konfiguriert sie die Zeit, die für jeden \fIExecStop=\fP\-Befehl gewartet werden soll\&. Falls bei einem von ihnen eine Zeitüberschreitung auftritt, werden nachfolgende \fIExecStop=\fP\-Befehle übersprungen und der Dienst wird durch \fBSIGTERM\fP beendet\&. Falls keine \fIExecStop=\fP\-Befehle festgelegt sind, erhält der Dienst das \fBSIGTERM\fP sofort\&. Dieses Standardverhalten kann mit der Option \fITimeoutStopFailureMode=\fP 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 \fBSIGKILL\fP (siehe \fIKillMode=\fP in \fBsystemd.kill\fP(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 \fIDefaultTimeoutStopSec=\fP aus der Verwalterkonfigurationsdatei (siehe \fBsystemd\-system.conf\fP(5))\&. .sp Falls ein Dienst vom \fIType=notify\fP »EXTEND_TIMEOUT_USEC=…« sendet, kann dies dazu führen, dass die Stoppzeit sich über \fITimeoutStopSec=\fP hinauszieht\&. Der erste Empfang dieser Nachricht muss auftreten, bevor \fITimeoutStopSec=\fP überschritten wird und sobald die Stoppzeit sich über \fITimeoutStopSec=\fP 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 \fBsd_notify\fP(3))\&. .RE .PP \fITimeoutAbortSec=\fP .RS 4 Diese Option konfiguriert die Zeit, die auf die Beendigung des Dienstes gewartet werden soll, wenn dieser aufgrund einer Watchdog\-Zeitüberschreitung abgebrochen wird (siehe \fIWatchdogSec=\fP))\&. Falls der Dienst eine kleine \fITimeoutStopSec=\fP hat, kann diese Option dem System mehr Zeit zum Schreiben eines Speicherauszuges des Dienstes geben\&. Nach Ablauf wird der Dienst zwangsweise mit \fBSIGKILL\fP (siehe \fIKillMode=\fP in \fBsystemd.kill\fP(5)) beendet\&. In diesem Fall wird die Speicherauszugsdatei abgeschnitten\&. Verwenden Sie \fITimeoutAbortSec=\fP, 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\&. .sp 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 \fITimeoutStopSec=\fP zurückzufallen\&. Übergeben Sie »infinity«, um die Zeitüberschreitungslogik zu überspringen\&. Standardmäßig \fIDefaultTimeoutAbortSec=\fP aus der Verwalterkonfigurationsdatei (siehe \fBsystemd\-system.conf\fP(5))\&. .sp Falls ein Dienst vom \fIType=notify\fP \fBSIGABRT\fP selber handhabt (statt sich auf den Kernel zum Schreiben eines Speicherauszuges zu verlassen), kann er »EXTEND_TIMEOUT_USEC=…« senden, um die Abbruchzeit über \fITimeoutAbortSec=\fP hinaus zu verlängern\&. Der erste Empfang dieser Nachricht muss auftreten, bevor \fITimeoutAbortSec=\fP überschritten wird und sobald die Abbruchzeit sich über \fITimeoutAbortSec=\fP 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 \fBsd_notify\fP(3))\&. .RE .PP \fITimeoutSec=\fP .RS 4 Eine Kurzform, um sowohl \fITimeoutStartSec=\fP als auch \fITimeoutStopSec=\fP auf den angegebenen Wert zu konfigurieren\&. .RE .PP \fITimeoutStartFailureMode=\fP, \fITimeoutStopFailureMode=\fP .RS 4 Diese Option konfiguriert die Aktion, die durchgeführt wird, falls ein Dameon\-Dienst nicht das Hochfahren innerhalb von \fITimeoutStartSec=\fP bzw\&. nicht das Beenden innerhalb von \fITimeoutStopSec=\fP anzeigt\&. Akzeptiert entweder \fBterminate\fP, \fBabort\fP oder \fBkill\fP\&. Die Vorgabe für beide Optionen ist \fBterminate\fP\&. .sp Falls \fBterminate\fP gesetzt ist, wird der Dienst sauber beendet, indem ihm das in \fIKillSignal=\fP festgelegte Signal (standardmäßig \fBSIGTERM\fP, siehe \fBsystemd.kill\fP(5)) gesandt wird\&. Falls sich der Dienst nicht beendet, dann wird \fIFinalKillSignal=\fP nach \fITimeoutStopSec=\fP gesendet\&. Falls \fBabort\fP gesetzt ist, wird stattdessen \fIWatchdogSignal=\fP gesandt und \fITimeoutAbortSec=\fP gilt bevor \fIFinalKillSignal=\fP gesandt wird\&. Diese Einstellung kann zur Analyse von Diensten verwandt werden, die beim Hoch\- oder Runterfahren zeitweilig fehlschlagen\&. Durch Verwendung von \fBkill\fP wird der Dienst sofort durch Senden von \fIFinalKillSignal=\fP beendet, ohne weitere Zeitüberschreitungen\&. Diese Einstellung kann zur Beschleunigung des Herunterfahrens von fehlgeschlagenen Diensten verwandt werden\&. .RE .PP \fIRuntimeMaxSec=\fP .RS 4 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 \fIType=oneshot\fP\-Dienste hat, da diese sofort beendet werden, nachdem ihre Aktivierung abgeschlossen ist\&. Übergeben Sie »infinity« (die Vorgabe), um keine Laufzeitbeschränkung zu konfigurieren\&. .sp Falls ein Dienst vom \fIType=notify\fP »EXTEND_TIMEOUT_USEC=…« sendet, kann dies dazu führen, dass die Laufzeit sich über \fIRuntimeMaxSec=\fP hinauszieht\&. Der erste Empfang dieser Nachricht muss auftreten, bevor \fIRuntimeMaxSec=\fP überschritten wird und sobald die Laufzeit sich über \fIRuntimeMaxSec=\fP 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 \fBsd_notify\fP(3))\&. .RE .PP \fIWatchdogSec=\fP .RS 4 Konfiguriert die Watchdog\-Zeitüberschreitung für einen Dienst\&. Der Watchdog wird aktiviert, wenn das Hochfahren abgeschlossen ist\&. Der Dienst muss regelmäßig \fBsd_notify\fP(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 \fBSIGABRT\fP (oder dem mit \fIWatchdogSignal=\fP festgelegten Signal) beendet\&. Durch Setzen von \fIRestart=\fP auf \fBon\-failure\fP, \fBon\-watchdog\fP, \fBon\-abnormal\fP oder \fBalways\fP wird der Dienst automatisch neu gestartet\&. Die hier konfigurierte Zeit wird in der Umgebungsvariablen \fIWATCHDOG_USEC=\fP 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 \fINotifyAccess=\fP (siehe unten) auf offenen Zugriff auf das durch Systemd bereitgestellte Benachrichtigungs\-Socket gesetzt werden\&. Falls \fINotifyAccess=\fP nicht gesetzt ist, wird es implizit auf \fBmain\fP gesetzt\&. Standardmäßig 0, wodurch diese Funktionalität deaktiviert wird\&. Der Dienst kann prüfen, ob der Diensteverwalter Watchdog\-Lebenszeichenbenachrichtigungen erwartet\&. Siehe \fBsd_watchdog_enabled\fP(3) für Details\&. \fBsd_event_set_watchdog\fP(3) kann zur Aktivierung der automatischen Watchdog\-Benachrichtigungsunterstützung verwandt werden\&. .RE .PP \fIRestart=\fP .RS 4 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 \fIExecStartPre=\fP, \fIExecStartPost=\fP, \fIExecStop=\fP, \fIExecStopPost=\fP oder \fIExecReload=\fP 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\&. .sp Akzeptiert \fBno\fP, \fBon\-success\fP, \fBon\-failure\fP, \fBon\-abnormal\fP, \fBon\-watchdog\fP, \fBon\-abort\fP oder \fBalways\fP\&. Falls auf \fBno\fP (die Vorgabe) gesetzt, wird der Dienst nicht neu gestartet\&. Falls auf \fBon\-success\fP gesetzt, wird er nur neu gestartet, wenn sich der Diensteprozess sauber beendet\&. In diesem Kontext bedeutet das saubere Beenden einen Exit\-Code 0 oder eines der Signale \fBSIGHUP\fP, \fBSIGINT\fP, \fBSIGTERM\fP oder \fBSIGPIPE\fP und zusätzlich in \fISuccessExitStatus=\fP festgelegte Exit\-Stati und Signale\&. Falls auf \fBon\-failure\fP 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 \fBon\-abnormal\fP 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 \fBon\-abort\fP 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 \fBon\-watchdog\fP gesetzt, wird der Dienst nur neu gestartet, wenn die Watchdog\-Zeitüberschreitung für den Dienst abläuft\&. Falls auf \fBalways\fP 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\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br \fBTabelle\ \&2.\ \&Exit\-Gründe und der Effekt der Einstellung \fP\fIRestart=\fP\fB darauf\fP .TS allbox tab(:); lB lB lB lB lB lB lB lB. T{ Neustart\-Einstellung/Exit\-Grund T}:T{ \fBno\fP T}:T{ \fBalways\fP T}:T{ \fBon\-success\fP T}:T{ \fBon\-failure\fP T}:T{ \fBon\-abnormal\fP T}:T{ \fBon\-abort\fP T}:T{ \fBon\-watchdog\fP T} .T& l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l. T{ Sauberer Exit\-Code oder \-Signal T}:T{ \ \& T}:T{ X T}:T{ X T}:T{ \ \& T}:T{ \ \& T}:T{ \ \& T}:T{ \ \& T} T{ Unsauberer Exit\-Code T}:T{ \ \& T}:T{ X T}:T{ \ \& T}:T{ X T}:T{ \ \& T}:T{ \ \& T}:T{ \ \& T} T{ Unsauberes Signal T}:T{ \ \& T}:T{ X T}:T{ \ \& T}:T{ X T}:T{ X T}:T{ X T}:T{ \ \& T} T{ Zeitüberschreitung T}:T{ \ \& T}:T{ X T}:T{ \ \& T}:T{ X T}:T{ X T}:T{ \ \& T}:T{ \ \& T} T{ Watchdog T}:T{ \ \& T}:T{ X T}:T{ \ \& T}:T{ X T}:T{ X T}:T{ \ \& T}:T{ X T} .TE .sp 1 Als Ausnahme zu den obigen Einstellungen wird der Dienst nicht neu gestartet, falls der Exit\-Code oder das Exit\-Signal in \fIRestartPreventExitStatus=\fP (siehe unten) festgelegt ist oder der Dienst mit \fBsystemctl stop\fP oder einer äquivalenten Aktion gestoppt wird\&. Auch wird der Dienst immer neu gestartet, falls der Exit\-Code oder das Exit\-Signal in \fIRestartForceExitStatus=\fP (siehe unten) festgelegt ist\&. .sp Beachten Sie, dass der Diensteneustart der mit \fIStartLimitIntervalSec=\fP und \fIStartLimitBurst=\fP konfigurierten Unit\-Startratenbegrenzung unterliegt, siehe \fBsystemd.unit\fP(5) für Details\&. Ein neugestarteter Dienst tritt in den Fehlerzustand nur ein, nachdem die Startratenbegrenzungen erreicht wurden\&. .sp Für langlaufende Dienste wird empfohlen, dies auf \fBon\-failure\fP 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 \fBon\-abnormal\fP eine alternative Wahl\&. .RE .PP \fISuccessExitStatus=\fP .RS 4 Akzeptiert eine Liste von Exit\-Statusdefinitionen, die als erfolgreiche Beendigung betrachtet werden, wenn sie vom Hauptdiensteprozess zurückgeliefert werden, zusätzlich zu dem normalen Exit\-Status 0 und den Signalen \fBSIGHUP\fP, \fBSIGINT\fP, \fBSIGTERM\fP und \fBSIGPIPE\fP\&. Exit\-Statusdefinitionen können numerische Exit\-Stati, Beendigungs\-Statusnamen oder Beendigungssignalnamen, getrennt durch Leerzeichen, sein\&. Siehe den Abschnitt »PROZESS\-EXIT\-CODES« in \fBsystemd.exec\fP(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 \fBsignal\fP(7) für eine Liste der Signalnamen\&. .sp 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\&. .sp 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\&. .PP \fBBeispiel\ \&1.\ \&Ein Dienst mit der Einstellung \fP\fISuccessExitStatus=\fP .sp .if n \{\ .RS 4 .\} .nf SuccessExitStatus=TEMPFAIL 250 SIGKILL .fi .if n \{\ .RE .\} .sp Exit\-Status 75 (\fBTEMPFAIL\fP), 250 und das Beendigungssignal wird \fBSIGKILL\fP als saubere Dienstebeendigung betrachtet\&. Beachten Sie: \fBsystemd\-analyze exit\-codes\fP kann zur Auflistung der Exit\-Stati und zur Übersetzung zwischen numerischen Code\-Werten und Namen verwandt werden\&. .RE .PP \fIRestartPreventExitStatus=\fP .RS 4 Akzeptiert eine Liste von Exit\-Statusdefinitionen, die automatische Diensteneustarts verhindern, wenn sie von dem Hauptdienstprozess zurückgeliefert werden, unabhängig von der mit \fIRestart=\fP 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: .sp .if n \{\ .RS 4 .\} .nf RestartPreventExitStatus=1 6 SIGABRT .fi .if n \{\ .RE .\} .sp Dies stellt sicher, dass die Exit\-Codes 1 und 6 und das Beendigungssignal \fBSIGABRT\fP 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\&. .sp Beachten Sie, dass diese Einstellung keine Auswirkung auf mittels \fIExecStartPre=\fP, \fIExecStartPost=\fP, \fIExecStop=\fP, \fIExecStopPost=\fP oder \fIExecReload=\fP konfigurierte Prozesse hat, sondern nur auf den Hauptdiensteprozess, d\&.h\&. entweder den mittels \fIExecStart=\fP aufgerufenen oder (abhängig von \fIType=\fP, \fIPIDFile=\fP, …) den anderweitig konfigurierten Hauptprozess\&. .RE .PP \fIRestartForceExitStatus=\fP .RS 4 Akzeptiert eine Liste von Exit\-Statusdefinitionen, die automatische Diensteneustarts erzwingen, wenn sie von dem Hauptdienstprozess zurückgeliefert werden, unabhängig von der mit \fIRestart=\fP konfigurierten Neustarteinstellung\&. Das Argumentenformat ist ähnlich zu \fIRestartPreventExitStatus=\fP\&. .RE .PP \fIRootDirectoryStartOnly=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls wahr, wird das Wurzelverzeichnis, das mit der Option \fIRootDirectory=\fP (siehe \fBsystemd.exec\fP(5) für weitere Informationen) konfiguriert ist, nur für den mit \fIExecStart=\fP gestarteten Prozess angewandt und nicht für die verschiedenen anderen Befehle \fIExecStartPre=\fP, \fIExecStartPost=\fP, \fIExecReload=\fP, \fIExecStop=\fP und \fIExecStopPost=\fP\&. Falls falsch, wird die Einstellung auf alle konfigurierten Befehle auf die gleiche Art angewandt\&. Standardmäßig falsch\&. .RE .PP \fINonBlocking=\fP .RS 4 Setzt den Schalter \fBO_NONBLOCK\fP 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 \fIFileDescriptorStoreMax=\fP für Details) übergeben wurden, der Schalter \fBO_NONBLOCK\fP gesetzt und diese sind daher im nicht blockierenden Modus\&. Diese Option ist wie in \fBsystemd.socket\fP(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\&. .RE .PP \fINotifyAccess=\fP .RS 4 Steuert den Zugriff auf das Statusbenachrichtigungs\-Socket, wie es über den Aufruf \fBsd_notify\fP(3) erreichbar ist\&. Akzeptiert \fBnone\fP (die Vorgabe), \fBmain\fP, \fBexec\fP oder \fBall\fP\&. Falls \fBnone\fP, werden keine Daemon\-Statusaktualisierungen vom Diensteprozess akzeptiert, alle Statusaktualisierungsnachrichten werden ignoriert\&. Falls \fBmain\fP, werden nur vom Hauptprozess des Dienstes gesandte Diensteaktualisierungen akzeptiert\&. Falls \fBexec\fP, werden nur Diensteaktualisierungen, die von einem der Haupt\- oder Steuerprozesse, die aus einem der Befehle \fIExec*=\fP stammen, gesandt wurden, akzeptiert\&. Falls \fBall\fP, 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 \fIType=notify\fP oder \fIWatchdogSec=\fP verwandt wird (siehe oben)\&. Falls jene Optionen verwandt werden, aber \fINotifyAccess=\fP nicht konfiguriert ist, werden sie implizit auf \fBmain\fP gesetzt\&. .sp Beachten Sie, dass \fBsd_notify()\fP\-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 \fBfork\fP erzeugte, d\&.h\&. bei allen Prozessen, die auf \fINotifyAccess=\fP\fBmain\fP oder \fINotifyAccess=\fP\fBexec\fP passen\&. Umgekehrt, falls ein Hilfsprozess einer Unit eine \fBsd_notify()\fP\-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 \fINotifyAccess=\fP\fBall\fP für sie gesetzt ist\&. .sp Um daher alle Ressourcenwettläufe, die mit Nachschlagen von Units des Clients verknüpft sind, zu beseitigen und Benachrichtigungen Units richtig zuzuordnen, kann \fBsd_notify_barrier()\fP 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 \fBsd_notify_barrier()\fP 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\&. .RE .PP \fISockets=\fP .RS 4 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\&. .sp 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 \fIService=\fP von \&.socket\-Units muss nicht auf das Inverse der Einstellung \fISockets=\fP von \&.service, auf die es sich bezieht, passen\&. .sp 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\&. .RE .PP \fIFileDescriptorStoreMax=\fP .RS 4 Konfiguriert, wie viele Dateideskriptoren in dem Diensteverwalter für den Dienst mittels »FDSTORE=1«\-Nachrichten von \fBsd_pid_notify_with_fds\fP(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 \fBmemfd_create\fP(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 \fBsd_listen_fds\fP(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 \fBPOLLHUP\fP oder \fBPOLLERR\fP 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 \fINotifyAccess=\fP (siehe oben) gesetzt werden, um Zugriff auf den von Systemd bereitgestellten Benachrichtigungs\-Socket zu öffnen\&. Falls \fINotifyAccess=\fP nicht gesetzt ist, wird es implizit auf \fBmain\fP gesetzt\&. .RE .PP \fIUSBFunctionDescriptors=\fP .RS 4 Konfiguriert den Ort einer Datei, die Deskriptoren für \m[blue]\fBUSB FunctionFS\fP\m[]\&\s-2\u[2]\d\s+2, für die Implementierung von USB\-Gadget\-Funktionen, enthält\&. Dies wird nur in Zusammenhang mit einer Socket\-Unit mit konfiguriertem \fIListenUSBFunction=\fP verwandt\&. Der Inhalt dieser Datei wird nach deren Öffnen in die Datei ep0 geschrieben\&. .RE .PP \fIUSBFunctionStrings=\fP .RS 4 Konfiguriert den Ort einer Datei, die USB\-FunctionFS\-Zeichenketten enthält\&. Das Verhalten ist zu obiger \fIUSBFunctionDescriptors=\fP ähnlich\&. .RE .PP \fIOOMPolicy=\fP .RS 4 Konfiguriert die Richtlinie des Speicherknappheits\- (OOM\-)Killers\&. Wenn der Speicher knapp wird, dann kann sich der Kernel unter Linux entscheiden, einen laufenden Prozess zu beenden, um Speicher freizugeben und den Speicherdruck zu reduzieren\&. Diese Einstellung akzeptiert entweder \fBcontinue\fP, \fBstop\fP oder \fBkill\fP\&. Falls auf \fBcontinue\fP gesetzt und ein Prozess des Dienstes wird vom OOM\-Killer des Kernels beendet, dann wird dies protokolliert, aber der Dienst läuft weiter\&. Falls auf \fBstop\fP gesetzt, wird das Ereignis protokolliert, aber der Dienst wird sauber durch den Diensteverwalter beendet\&. Falls auf \fBkill\fP gesetzt und einer der Prozesse des Dienstes wird vom OOM\-Killer getötet, wird der Kernel angewiesen, alle verbliebenen Prozesse des Dienstes auch zu beenden\&. Die Vorgabe entspricht der Einstellung \fIDefaultOOMPolicy=\fP in \fBsystemd\-system.conf\fP(5), außer für Dienste, bei denen \fIDelegate=\fP eingeschaltet ist, wo die Vorgabe \fBcontinue\fP lautet\&. .sp Verwenden Sie die Einstellung \fIOOMScoreAdjust=\fP, um zu konfigurieren, ob Prozesse der Unit als bevorzugte oder weniger bevorzugte Kandidaten für die Beendigung durch die Linux\-OOM\-Killer\-Logik betrachtet werden sollen\&. Siehe \fBsystemd.exec\fP(5) für Details\&. .RE .PP Lesen Sie \fBsystemd.exec\fP(5) und \fBsystemd.kill\fP(5) für weitere Einstellungen\&. .SH BEFEHLSZEILEN .PP Dieser Abschnitt beschreibt die Auswertung der Befehlszeile und Variablen\- und Kennzeichnerersetzung für die Optionen \fIExecStart=\fP, \fIExecStartPre=\fP, \fIExecStartPost=\fP, \fIExecReload=\fP, \fIExecStop=\fP und \fIExecStopPost=\fP\&. .PP 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 »\e;« maskiert werden\&. .PP Jede Befehlszeile wird bei Leerraumzeichen aufgeteilt, wobei das erste Objekt der auszuführende Befehl und die nachfolgenden Objekte dessen Argumente sind\&. Doppelte ("…") und einfache Anführungszeichen (\*(Aq…\*(Aq) können zum Einhüllen eines ganzen Objekts verwandt werden (das öffnende Anführungszeichen darf nur am Anfang oder nach Leerraumzeichen, die nicht in Anführungszeichen sind, erscheinen und dem schließenden Anführungszeichen muss Leerraumzeichen oder das Zeilenende folgen), dabei wird alles bis zum nächsten passenden Anführungszeichen Teil des gleichen Arguments\&. Die Anführungszeichen selbst werden entfernt\&. C\-artige Maskierungen werden auch unterstützt\&. Die nachfolgende Tabelle enthält die Liste der bekannten Maskiermuster\&. Nur Maskiermuster, die auf die Syntax in der Tabelle passen, sind erlaubt; andere Muster können in der Zukunft hinzugefügt werden und unbekannte Muster führen zu einer Warnung\&. Insbesondere sollten alle Rückwärtsschrägstriche verdoppelt werden\&. Schließlich kann ein abschließender Rückwärtsschrägstrich (»\e«) zum Zusammenführen von Zeilen verwandt werden\&. .PP 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 \fIandere Elemente der Shell\-Syntax nicht unterstützt\fP\&. .PP Der auszuführende Befehl darf Leerzeichen enthalten, aber Steuerzeichen sind nicht erlaubt\&. .PP Die Befehlszeile akzeptiert wie in \fBsystemd.unit\fP(5) beschrieben »%s«\-Kennzeichner\&. .PP 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\&. .PP 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 \fBsystemd\-path search\-binaries\-default\fP abgefragt werden\&. .PP Beispiel: .sp .if n \{\ .RS 4 .\} .nf Environment="EINS=eins" \*(AqZWEI=zwei zwei\*(Aq ExecStart=echo $EINS $ZWEI ${ZWEI} .fi .if n \{\ .RE .\} .PP Dies führt \fB/bin/echo\fP mit vier Argumenten aus: »eins«, »zwei«, »zwei« und »zwei zwei«\&. .PP Beispiel: .sp .if n \{\ .RS 4 .\} .nf Environment=EINS=\*(Aqeins\*(Aq "ZWEI=\*(Aqzwei\ \&zwei\*(Aq\ \&auch" DREI= ExecStart=/bin/echo ${EINS} ${ZWEI} ${DREI} ExecStart=/bin/echo $EINS $ZWEI $DREI .fi .if n \{\ .RE .\} .PP Dies führt dazu, dass /bin/echo zweimal aufgerufen wird, das erste Mal mit den Argumenten »\*(Aqeins\*(Aq«, »\*(Aqzwei zwei\*(Aq \&auch« »« und das zweite Mal mit den Argumenten »eins«, »zwei\ zwei«, »auch«\&. .PP Um ein wörtliches Dollarzeichen zu übergeben, verwenden Sie »$$«\&. Variablen, deren Wert zum Expansionszeitpunkt nicht bekannt ist, werden als leere Zeichenkette behandelt\&. Beachten Sie, dass das erste Argument (d\&.h\&. das auszuführende Programm) keine Variable sein darf\&. .PP Variablen, die auf diese Art verwandt werden, können mittels \fIEnvironment=\fP und \fIEnvironmentFile=\fP definiert werden\&. Zusätzlich können Variablen, die im Abschnitt »Umgebungsvariablen in erzeugten Prozessen« in \fBsystemd.exec\fP(5), die als »statische Konfiguration« betrachtet werden, verwandt werden (dies schließt beispielsweise \fI$USER\fP, aber nicht \fI$TERM\fP ein)\&. .PP Beachten Sie, dass Shell\-Befehlszeilen nicht direkt unterstützt werden\&. Falls Shell\-Befehlszeilen verwandt werden sollen, müssen sie explizit an eine Art von Shell\-Implementierung übergeben werden\&. Beispiel: .sp .if n \{\ .RS 4 .\} .nf ExecStart=sh \-c \*(Aqdmesg | tac\*(Aq .fi .if n \{\ .RE .\} .PP Beispiel: .sp .if n \{\ .RS 4 .\} .nf ExecStart=echo eins ; echo "zwei zwei" .fi .if n \{\ .RE .\} .PP Dies wird \fBecho\fP zwei Mal ausführen, jedes Mal mit einem Argument: »eins« bzw\&. »zwei zwei«\&. Da zwei Befehle angegeben sind, muss \fIType=oneshot\fP verwandt werden\&. .PP Beispiel: .sp .if n \{\ .RS 4 .\} .nf ExecStart=echo / >/dev/null & \e; \e ls .fi .if n \{\ .RE .\} .PP Dies wird \fBecho\fP mit fünf Argumenten ausführen: »/«, »>/dev/null«, »&«, »;« und »ls«\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br \fBTabelle\ \&3.\ \&In Befehlszeilen und Umgebungsvariablen unterstützte C\-Maskierungen\fP .TS allbox tab(:); lB lB. T{ Wortsinn T}:T{ Tatsächlicher Wert T} .T& l l l l l l l l l l l l l l l l l l l l l l l l l l. T{ "\ea" T}:T{ Glockenton T} T{ "\eb" T}:T{ Rückschritt (»backspace«) T} T{ "\ef" T}:T{ Seitenvorschub T} T{ "\en" T}:T{ Zeilenumbruch T} T{ "\er" T}:T{ Wagenrücklauf T} T{ "\et" T}:T{ Tabulator T} T{ "\ev" T}:T{ Vertikaler Tabulator T} T{ "\e\e" T}:T{ Rückschrägstrich (»backslash«) T} T{ "\e"" T}:T{ doppeltes englisches Anführungszeichen T} T{ "\e\*(Aq" T}:T{ einfaches englisches Anführungszeichen T} T{ "\es" T}:T{ Leerzeichen T} T{ "\ex\fIxx\fP" T}:T{ Zeichen Nummer \fIxx\fP in hexadezimaler Kodierung T} T{ "\e\fInnn\fP" T}:T{ Zeichen Nummer \fInnn\fP in oktaler Kodierung T} .TE .sp 1 .SH BEISPIELE .PP \fBBeispiel\ \&2.\ \&Einfacher Dienst\fP .PP Die folgende Unit\-Datei erstellt einen Dienst, der /usr/sbin/foo\-daemon ausführt\&. Da kein \fIType=\fP angegeben ist, wird die Vorgabe \fIType=\fP\fBsimple\fP angenommen\&. Systemd wird annehmen, dass die Unit sofort nach Beginn der Ausführung des Programmes gestartet werden soll\&. .sp .if n \{\ .RS 4 .\} .nf [Unit] Description=Foo [Service] ExecStart=/usr/sbin/foo\-daemon [Install] WantedBy=multi\-user\&.target .fi .if n \{\ .RE .\} .PP Beachten Sie, dass Systemd hier annimmt, dass der durch Systemd gestartete Prozess läuft, bis der Dienst beendet wird\&. Falls das Programm sich selbst zum Daemon macht (d\&.h\&. Fork ausführt), verwenden Sie bitte stattdessen \fIType=\fP\fBforking\fP\&. .PP Da kein \fIExecStop=\fP angegeben wurde, wird Systemd SIGTERM an alle von diesem Dienst gestarteten Prozesse senden und nach einer Zeitüberschreitung auch SIGKILL\&. Dieses Verhalten kann verändert werden, siehe \fBsystemd.kill\fP(5) für Details\&. .PP Beachten Sie, dass dieser Unit\-Typ keine Art von Benachrichtigung, wenn der Dienst seine Initialisierung abgeschlossen hat, enthält\&. Dafür sollten Sie andere Unit\-Typen, wie \fIType=\fP\fBnotify\fP, falls der Dienst das Benachrichtigungsprotokoll von Systemd versteht, \fIType=\fP\fBforking\fP, falls der Dienst sich selbst in den Hintergrund bringen kann oder \fIType=\fP\fBdbus\fP, falls der Dienst einen DBus\-Namen erlangt, sobald die Initialisierung abgeschlossen ist, in Betracht ziehen\&. Siehe unten\&. .PP \fBBeispiel\ \&3.\ \&Oneshot\-Dienst\fP .PP Manchmal sollen Units einfach eine Aktion ausführen, ohne aktive Prozesse zu behalten, wie beispielsweise eine Dateisystemüberprüfung oder eine Aufräumaktion beim Systemstart\&. Dafür existiert \fIType=\fP\fBoneshot\fP\&. Units dieser Art werden warten, bis der festgelegte Prozess sich beendet hat und dann auf einen inaktiven Status zurückfallen\&. Die folgende Unit wird eine Aufräumaktion durchführen: .sp .if n \{\ .RS 4 .\} .nf [Unit] Description=Bereinigung alter Foo\-Daten [Service] Type=oneshot ExecStart=/usr/sbin/foo\-cleanup [Install] WantedBy=multi\-user\&.target .fi .if n \{\ .RE .\} .PP Beachten Sie, dass Systemd die Unit im Status »starting« betrachten wird, bis sich das Programm beendet hat, daher werden Ordnungsabhängigkeiten auf die Beendigung des Programms warten, bevor sie sich selbst starten\&. Die Unit wird zum Zustand »inactive« nach dem Abschluss der Ausführung zurückkehren und niemals den Zustand »active« erreichen\&. Das bedeutet, dass eine weitere Anfrage, die Unit zu starten, die Aktion erneut ausführen wird\&. .PP Nur Units mit \fIType=\fP\fBoneshot\fP dürfen mehr als ein \fIExecStart=\fP festgelegt haben\&. Für Units mit mehreren Befehlen (\fIType=oneshot\fP) werden alle Befehle erneut ausgeführt\&. .PP Für \fIType=oneshot\fP sind \fIRestart=\fP\fBalways\fP und \fIRestart=\fP\fBon\-success\fP \fInicht\fP erlaubt\&. .PP \fBBeispiel\ \&4.\ \&Beendbarer Oneshot\-Dienst\fP .PP Ähnlich zum Oneshot\-Dienst gibt es manchmal Units, die ein Programm ausführen müssen, um etwas einzurichten, und dann ein anderes, um es herunterzufahren, aber es bleibt kein Prozess aktiv, während diese als »started« betrachtet werden\&. Netzwerkkonfiguration kann manchmal in diese Kategorie fallen\&. Ein anderer Anwendungsfall ist, falls ein Oneshot\-Dienst nicht jedesmal, wenn er als Abhängigkeit hereingezogen wird, ausgeführt werden soll, sondern nur beim ersten Mal\&. .PP Dafür kennt Systemd die Einstellung \fIRemainAfterExit=\fP\fByes\fP, die dazu führt, dass Systemd die Unit als aktiv betrachtet, falls die Startaktion sich erfolgreich beendet hat\&. Diese Anweisung kann mit allen Typen verwandt werden, ist aber mit \fIType=\fP\fBoneshot\fP und \fIType=\fP\fBsimple\fP am nützlichsten\&. Mit \fIType=\fP\fBoneshot\fP wird Systemd warten, bis die Startaktion abgeschlossen ist, bevor es die Unit als aktiv betrachtet, daher starten Abhängigkeiten erst nachdem die Startaktion erfolgreich war\&. Mit \fIType=\fP\fBsimple\fP werden die Abhängigkeiten sofort nach dem Absetzen der Startaktion gestartet\&. Die nachfolgende Unit stellt ein Beispiel für eine einfache statische Firewall bereit\&. .sp .if n \{\ .RS 4 .\} .nf [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 .fi .if n \{\ .RE .\} .PP Da die Unit als laufend betrachtet wird, nachdem sich die Start\-Aktion beendet hat, wird der Aufruf von \fBsystemctl start\fP auf dieser Unit zu keiner Aktion führen\. .PP \fBBeispiel\ \&5.\ \&Traditioneller forkender Dienst\fP .PP Viele traditionelle Daemons/Dienste bringen sich selbst in den Hintergrund (d\&.h\&. forken, daemonisieren sich), wenn sie starten\&. Setzen Sie \fIType=\fP\fBforking\fP in der Unit\-Datei des Dienstes, um diesen Betriebsmodus zu unterstützen\&. Systemd wird den Dienst im Prozess der Initialisierung betrachten, während das ursprüngliche Programm noch läuft\&. Sobald es sich erfolgreich beendet und mindestens ein Prozess verbleibt (und \fIRemainAfterExit=\fP\fBno\fP), wird der Dienst als gestartet betrachtet\&. .PP Oft besteht ein traditioneller Daemon nur aus einem Prozess\&. Daher wird Systemd diesen Prozess als den Hauptprozess des Dienstes betrachten, falls nur ein Prozess nach Beendigung des ursprünglichen Prozesses verbleibt\&. In diesem Fall wird die Variable \fI$MAINPID\fP in \fIExecReload=\fP, \fIExecStop=\fP usw\&. verfügbar sein\&. .PP 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 \fI$MAINPID\fP 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 \fIPIDFile=\fP entsprechend\&. Beachten Sie, dass der Daemon diese Datei schreiben sollte, bevor er seine Initialisierung abschließt\&. Andernfalls könnte Systemd versuchen, die Datei zu lesen, bevor sie existiert\&. .PP Das folgende Beispiel zeigt einen einfachen Daemon, der forkt und einfach einen Prozess im Hintergrund startet: .sp .if n \{\ .RS 4 .\} .nf [Unit] Description=Ein einfacher Daemon [Service] Type=forking ExecStart=/usr/sbin/my\-simple\-daemon \-d [Install] WantedBy=multi\-user\&.target .fi .if n \{\ .RE .\} .PP Bitte lesen Sie \fBsystemd.kill\fP(5) für Details, wie Sie die Art, wie Systemd die Dienste beendet, beeinflussen können\&. .PP \fBBeispiel\ \&6.\ \&DBus\-Dienste\fP .PP Für Dienste, die einen Namen auf dem DBus\-Systembus erlangen, verwenden Sie \fIType=\fP\fBdbus\fP und setzen \fIBusName=\fP 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: .sp .if n \{\ .RS 4 .\} .nf [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 .fi .if n \{\ .RE .\} .PP Für \fIBus\-aktivierbare\fP Dienste nehmen Sie keinen Abschnitt »[Install]« in der Systemd\-Dienstedatei auf, sondern verwenden die Option \fISystemdService=\fP in der entsprechenden DBus\-Dienstedatei, beispielsweise (/usr/share/dbus\-1/system\-services/org\&.example\&.simple\-dbus\-service\&.service): .sp .if n \{\ .RS 4 .\} .nf [D\-BUS Service] Name=org\&.example\&.simple\-dbus\-service Exec=/usr/sbin/simple\-dbus\-service User=root SystemdService=simple\-dbus\-service\&.service .fi .if n \{\ .RE .\} .PP Bitte lesen Sie \fBsystemd.kill\fP(5) für Details, wie Sie die Art, wie Systemd die Dienste beendet, beeinflussen können\&. .PP \fBBeispiel\ \&7.\ \&Dienste, die Systemd über ihre Initialisierung benachrichtigen\fP .PP \fIType=\fP\fBsimple\fP\-Dienste sind wirklich einfach zu schreiben, haben aber den großen Nachteil, dass Systemd nicht feststellen kann, wann die Initialisierung des gegebenen Dienstes abgeschlossen ist\&. Aus diesem Grund unterstützt Systemd ein einfaches Benachrichtigungsprotokoll, das es Daemons erlaubt, Systemd darüber in Kenntnis zu setzen, dass sie initialisiert sind\&. Verwenden Sie dafür \fIType=\fP\fBnotify\fP\&. Eine typische Dienste\-Datei für solch einen Daemon sähe wie folgt aus: .sp .if n \{\ .RS 4 .\} .nf [Unit] Description=Einfacher Benachrichtigungsdienst [Service] Type=notify ExecStart=/usr/sbin/simple\-notifying\-service [Install] WantedBy=multi\-user\&.target .fi .if n \{\ .RE .\} .PP Beachten Sie, dass der Daemon das Benachrichtigungsprotokoll von Systemd unterstützen muss, da ansonsten Systemd glauben wird, dass der Dienst noch nicht gestartet wurde und ihn nach einer Zeitüberschreitung töten wird\&. Für ein Beispiel, wie transparent ein Daemon aktualisiert wird, um dieses Protokoll zu unterstützen, schauen Sie in \fBsd_notify\fP(3)\&. Systemd wird die Unit im Zustand »starting« betrachten, bis eine Bereitschaftsbenachrichtigung angekommen ist\&. .PP Bitte lesen Sie \fBsystemd.kill\fP(5) für Details, wie Sie die Art, wie Systemd die Dienste beendet, beeinflussen können\&. .SH "SIEHE AUCH" .PP \fBsystemd\fP(1), \fBsystemctl\fP(1), \fBsystemd\-system.conf\fP(5), \fBsystemd.unit\fP(5), \fBsystemd.exec\fP(5), \fBsystemd.resource\-control\fP(5), \fBsystemd.kill\fP(5), \fBsystemd.directives\fP(7), \fBsystemd\-run\fP(1) .SH ANMERKUNGEN .IP " 1." 4 Inkompatibilitäten mit SysV .RS 4 \%https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities .RE .IP " 2." 4 USB FunctionFS .RS 4 \%https://www.kernel.org/doc/Documentation/usb/functionfs.txt .RE .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE 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 .MT debian-l10n-german@\:lists.\:debian.\:org Mailingliste der Übersetzer .ME .