[LINUX] man systemd.service Japanische Übersetzung

Japanische Übersetzung des von man systemd.service angezeigten Handbuchs.

Name

Konfiguration der systemd.service-service-Einheit

Überblick

service.service

Erläuterung

Gerätekonfigurationsdateien, deren Namen mit ".service" enden, codieren Informationen zu den Prozessen, die von systemd gesteuert und überwacht werden.

Diese Handbuchseite listet Konfigurationsoptionen auf, die für diesen Gerätetyp spezifisch sind. Unter systemd.unit (5) finden Sie Optionen, die allen Gerätekonfigurationsdateien gemeinsam sind. Gemeinsame Komponenten bestehen normalerweise aus den Abschnitten [Unit] und [Install]. Dienstspezifische Konfigurationsoptionen werden im Abschnitt "[Dienst]" konfiguriert.

Zusätzliche Optionen sind systemd.exec (5), das die Ausführungsumgebung definiert, in der der Befehl ausgeführt wird, systemd.kill (5), die definiert, wie der Serviceprozess beendet wird, und systemd, das die Einstellungen für die Ressourcensteuerung für den Serviceprozess konfiguriert. Es ist in .resource-control (5) aufgeführt.

Wenn der Dienst mit einem bestimmten Namen angefordert wird, die Gerätekonfigurationsdatei jedoch nicht gefunden wird, sucht systemd nach einem SysV-Init-Skript mit demselben Namen (wobei die Erweiterung ".service" entfernt wurde) und führt die Diensteinheit über dieses Skript aus. Erstellen Dies ist nützlich für die Kompatibilität mit SysV. Diese Kompatibilität ist sehr umfassend, aber nicht 100%. Weitere Informationen zu Inkompatibilitäten finden Sie unter Inkompatibilitäten mit SysV (https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities).

Servicevorlage

Der systemd-Dienst kann ein einzelnes Argument über die Syntax service @ argument.service annehmen. Solche Dienste werden als "instanziierte" Dienste bezeichnet, und Einheitendefinitionen ohne Argumentparameter werden als "Vorlage" bezeichnet. Beispielsweise verwendet die Dienstvorlage "dhcpcd @ .service" eine Netzwerkschnittstelle als Parameter, um einen instanziierten Dienst zu bilden. Innerhalb der Servicedatei können Sie mit dem Bezeichner % auf diesen Parameter oder den Instanznamen zugreifen. Weitere Informationen finden Sie unter systemd.unit (5).

Automatische Abhängigkeiten

Implizite Abhängigkeiten

Die folgenden Abhängigkeiten werden implizit hinzugefügt:

Implizite Abhängigkeiten können als Ergebnis von Ausführungs- und Ressourcensteuerungsparametern hinzugefügt werden, wie in systemd.exec (5) und systemd.resource-control (5) beschrieben.

Standardabhängigkeiten

Die folgenden Abhängigkeiten werden hinzugefügt, sofern nicht "DefaultDependencies = no" festgelegt ist:

Möglichkeit

Die Servicedatei muss einen Abschnitt "[Service]" enthalten. Dieser Abschnitt enthält Informationen zum Dienst und den von ihm überwachten Prozessen. Einige der in diesem Abschnitt verfügbaren Optionen werden mit anderen Einheitentypen geteilt. Diese Optionen sind in systemd.exec (5), systemd.kill (5), systemd.resource-control (5) beschrieben. Die spezifischen Optionen für den Abschnitt "[Service]" der Serviceeinheit sind:

Type= Legt den Prozessstarttyp für diese Serviceeinheit fest.

Type = simple ist die einfachste und schnellste Option. Wir empfehlen daher, sie nach Möglichkeit für Dienste mit langer Laufzeit zu verwenden. Dieser Diensttyp verbreitet jedoch keine Dienststartfehler und ermöglicht nicht, dass andere Einheiten bestellt werden, um die Dienstinitialisierung abzuschließen.

Der IPC-Kanal wird nur vom Dienst selbst eingerichtet. (Zum Beispiel nützlich, wenn der Client über eine Form von IPC eine Verbindung zum Dienst herstellen muss.) Im Gegensatz zur Voreinstellung von Kanälen, z. B. durch Socket- oder Busaktivierung, ist dies häufig nicht ausreichend. In diesem Fall empfehlen wir die Verwendung von notify oder dbus (letzteres nur, wenn der Dienst eine D-Bus-Schnittstelle bereitstellt). Auf diese Weise kann der Serviceprogrammcode genau planen, wann der Service als erfolgreich angesehen werden soll und wann nachfolgende Einheiten fortgesetzt werden sollen. Der Benachrichtigungstyp erfordert explizite Unterstützung in der Servicecodebasis, da sd_notify () oder eine gleichwertige API vom Service zum richtigen Zeitpunkt aufgerufen werden muss. Verwenden Sie stattdessen Forking, wenn es nicht unterstützt wird: Forking unterstützt herkömmliche Startprotokolle für UNIX-Dienste.

Schließlich reicht exec aus, um sicherzustellen, dass die Service-Binärdatei aufgerufen wird. Dies ist eine Option, wenn die Service-Binärdatei selbst keine oder nur eine sehr geringe Initialisierung durchführt (wenn die Initialisierung wahrscheinlich nicht fehlschlägt). Sie könnten. Beachten Sie, dass die Verwendung eines anderen als einfachen Typs den Startvorgang verzögern kann, indem Sie darauf warten, dass der Service Manager die Service-Initialisierung abschließt. Wir empfehlen daher, dass Sie nicht unachtsam andere als einfache Typen verwenden. (Beachten Sie auch, dass es im Allgemeinen nicht empfohlen wird, Leerlauf oder Oneshot für Dienste mit langer Laufzeit zu verwenden.)

RemainAfterExit= Es wird ein boolescher Wert verwendet, der angibt, ob der Dienst als aktiv betrachtet wird, auch wenn alle Prozesse beendet wurden. Der Standardwert ist "Nein".

GuessMainPID= Nimmt einen booleschen Wert an, der angibt, ob systemd die Haupt-PID des Dienstes ableitet, wenn diese nicht zuverlässig bestimmt werden kann. Diese Option wird ignoriert, es sei denn, Type = forking ist gesetzt und PIDFile = ist nicht gesetzt. Bei anderen Typen oder bei explizit konfigurierten PID-Dateien (#pidfile) ist die Haupt-PID immer bekannt. Wenn der Dämon aus mehreren Prozessen besteht, kann der Schätzalgorithmus zu falschen Schlussfolgerungen führen. Wenn die Haupt-PID nicht ermittelt werden kann, funktionieren die Erkennung von Dienststartfehlern und der automatische Neustart nicht ordnungsgemäß. Der Standardwert ist "Ja".

PIDFile= Ruft den Pfad ab, der auf die PID-Datei des Dienstes verweist. Wir empfehlen, diese Option für Dienste zu verwenden, die auf "Type = Fork" eingestellt sind. Der angegebene Pfad verweist normalerweise auf Dateien unter / run /. Wenn ein relativer Pfad angegeben wird, wird dem Pfad implizit / run / vorangestellt. Nach dem Starten des Dienstes liest der Dienstmanager die PID des Hauptprozesses des Dienstes aus der in PIDFile angegebenen Datei. Der Service Manager schreibt nicht in die hier konfigurierten Dateien, sondern löscht die Dateien nach dem Herunterfahren, wenn der Service noch vorhanden ist. Die PID-Datei muss nicht einem privilegierten Benutzer gehören. Wenn sie jedoch einem nicht privilegierten Benutzer gehört, gelten zusätzliche Sicherheitsbeschränkungen. Die Datei darf keine symbolische Verknüpfung (direkt oder indirekt) zu einer Datei sein, die einem anderen Benutzer gehört. Die PID-Datei sollte sich auf den Prozess beziehen, der zum Dienst gehört.

BusName= Ruft den Namen des D-Bus-Busses ab, der diesen Dienst erreichen kann. Diese Option ist für Dienste mit "Type = dbus" erforderlich.

ExecStart= Gibt einen Befehl mit Argumenten an, die beim Start des Dienstes ausgeführt werden sollen. Der Wert wird gemäß den unten beschriebenen Regeln in Befehlszeilen aufgeteilt (siehe Abschnitt Befehlszeile (#Befehlszeile) unten).

Es muss genau ein Befehl angegeben werden, es sei denn, "Type = oneshot". Sie können null oder mehr Befehle angeben, wenn Sie "Type = oneshot" verwenden. Ein Befehl kann mehrere Befehlszeilen mit derselben Anweisung angeben. Alternativ können Sie diese Anweisung mehrmals angeben, um den gleichen Effekt zu erzielen. Wenn dieser Option eine leere Zeichenfolge zugewiesen ist, wird die Liste der zu startenden Befehle zurückgesetzt. Das Zuweisen dieser Option vor einer leeren Zeichenfolge hat keine Auswirkung. Wenn ExecStart = nicht angegeben ist, muss der Dienst "RemainAfterExit = yes" und mindestens eine Zeile ExecStop = haben. (Dienste ohne ExecStart = und ExecStop = sind ungültig.)

Das erste Argument jedes angegebenen Befehls muss ein absoluter Pfad zu einer ausführbaren Datei oder ein einfacher Dateiname ohne Schrägstriche sein. Optional können Sie dem Dateinamen einige Sonderzeichen voranstellen.

** Tabelle 1. Spezielles ausführbares Präfix **

Präfix bewirken
@ Am Anfang des ausführbaren Pfads@Wenn Sie hinzufügen, ist das zweite angegebene Tokenargv[0]Wie(Nicht der tatsächliche Dateiname)Es wird an den ausgeführten Prozess übergeben, gefolgt vom angegebenen Argument nach dem zweiten Token.
- Am Anfang des ausführbaren Pfads-Beenden Sie den Code für Befehle, die normalerweise als fehlgeschlagen gelten, wenn(Das heißt, mit einem Beendigungsstatus oder -signal ungleich Null abbrechen)Wird aufgezeichnet, hat aber keine weiteren Auswirkungen und wird als gleichbedeutend mit Erfolg angesehen.
+ Am Anfang des ausführbaren Pfads+Wenn dies der Fall ist, wird der Prozess mit allen Berechtigungen ausgeführt. In diesem ModusUser= , Group= , CapabilityBoundingSet=Oder Namespace-Optionen für Dateisysteme( PrivateDevices= , PrivateTmp=Eine solche)Mit konfigurierte Berechtigungsbeschränkungen gelten nicht für die aufgerufene Befehlszeile.(Jedoch andereExecStart=,ExecStop=BeeinflusstBefehlszeilenwie)
! über+Wie Zeichen können Sie Befehlszeilen mit erhöhten Berechtigungen aufrufen. jedoch+Nicht wie,!CharakterUser= , Group= , SupplementaryGroups=Ändern Sie nur die Wirkung von. Das heißt, nur Zeilengruppen, die sich auf Benutzer- und Gruppenanmeldeinformationen auswirken. Diese Einstellung istDynamicUser=Kann mit kombiniert werden. In diesem Fall wird der Benutzer vor dem Befehl aufgerufen/Gruppenpaare werden dynamisch zugewiesen, Änderungen an Anmeldeinformationen bleiben jedoch dem laufenden Prozess selbst überlassen.
!! Dieses Präfix ist!Ähnlich, aber ohne Unterstützung für Umgebungsverarbeitungsfunktionen, d. H.AmbientCapabilities=Betrifft nur Systeme, die keine Unterstützung haben. Es ist für Gerätedateien vorgesehen, die Umgebungsfunktionen verwenden, um Prozesse mit den geringstmöglichen Berechtigungen auszuführen, während die Kompatibilität mit Systemen erhalten bleibt, die Umgebungsfunktionen nicht unterstützen.!!Damit der erzeugte Prozess Anmeldeinformationen und Funktionen widerrufen kann, auch wenn er so konfiguriert ist, dass er nicht zulässig istSystemCallFilter=WannCapabilityBoundingSet=Die Zeilengruppe wird implizit geändert. Wenn ein System erkannt wird, das dieses Präfix verwendet, jedoch keine Umgebungsfunktionalität unterstützt,AmbientCapabilities=Wird übersprungen und gilt nicht. Für Systeme, die die Umgebungsfunktion unterstützen!!Da es keine Auswirkung von gibt, ist die Beschreibung redundant.

Sie können entweder @, - und + / ! / !! verwenden und diese in beliebiger Reihenfolge angeben. Verwenden Sie jedoch +, ! , !! nur einmal. Diese Präfixe gelten für andere Befehlszeileneinstellungen ([ExecStartPre =](# execstartpre-execstartpost), [ExecStartPost =](# execstartpre-execstartpost), ExecReload =, ExecStop = ), ExecStopPost =) wird ebenfalls unterstützt.

Wenn mehr als ein Befehl angegeben ist, werden die Befehle nacheinander in der Reihenfolge aufgerufen, in der sie in der Einheitendatei angezeigt werden. Wenn einer der Befehle fehlschlägt (und kein - vorangestellt ist), wird die andere Zeile nicht ausgeführt und die Einheit gilt als fehlgeschlagen.

Sofern Type = forking nicht festgelegt ist, wird der über diese Befehlszeile gestartete Prozess als Hauptprozess des Dämons betrachtet.

ExecStartPre=, ExecStartPost= Gibt zusätzliche Befehle an, die vor oder nach dem Befehl ExecStart = ausgeführt werden sollen. Die Syntax ist dieselbe wie für ExecStart =, außer dass mehrere Befehlszeilen zulässig sind und die Befehle nacheinander ausgeführt werden. Wenn einer dieser Befehle fehlschlägt (und nicht mit - vorangestellt wird), wird die Befehlszeile nach dem Fehler nicht ausgeführt und die Einheit wird als fehlgeschlagen angesehen.

Der Befehl ExecStart = wird erst ausgeführt, nachdem alle Befehle [ExecStartPre =](# execstartpre-execstartpost) ohne das Präfix - erfolgreich ausgeführt wurden. Der Befehl [ExecStartPost =](# execstartpre-execstartpost) wird erst ausgeführt, nachdem der durch ExecStart = angegebene Befehl erfolgreich aufgerufen wurde. Dies wird durch Type = bestimmt.

Beispiel:

Beachten Sie, dass [ExecStartPre =](# execstartpre-execstartpost) möglicherweise nicht verfügbar ist, um einen Prozess mit langer Laufzeit zu starten. Alle Prozesse, die von dem über [ExecStartPre =](# execstartpre-execstartpost) aufgerufenen Prozess verzweigt werden, werden beendet, bevor der nächste Serviceprozess ausgeführt wird.

Einer der von [ExecStartPre =](# execstartpre-execstartpost), ExecStart = oder [ExecStartPost =](# execstartpre-execstartpost) angegebenen Befehle schlägt fehl (und wird mit - vorangestellt. Beachten Sie, dass der von ExecStopPost = angegebene Befehl weiterhin ausgeführt wird, wenn der Dienst vor dem vollständigen Start eine Zeitüberschreitung aufweist. Der Befehl ExecStop = wird übersprungen.

ExecReload= Gibt den Befehl an, der ausgeführt werden soll, um den Dienst zum erneuten Laden der Konfiguration auszulösen. Das Argument verwendet mehrere Befehlszeilen gemäß demselben Schema, das oben in ExecStart = beschrieben wurde. Die Verwendung dieser Einstellung ist optional. Das Ersetzen von Spezifizierern und Umgebungsvariablen wird nach demselben Schema wie ExecStart = unterstützt.

Eine zusätzliche spezielle Umgebungsvariable wird festgelegt. Wenn bekannt, wird "$ MAINPID" auf den Hauptprozess des Daemons gesetzt. Es kann in Befehlszeilen verwendet werden wie:

/bin/kill -HUP $MAINPID

Das Signalisieren und erneute Laden des Dämons wie im obigen Beispiel ist jedoch normalerweise keine gute Wahl, da dies eine asynchrone Operation ist und nicht zum Bestellen des erneuten Ladens mehrerer Dienste voneinander geeignet ist. .. Es wird dringend empfohlen, dass Sie nicht nur ein Konfigurations-Reload des Daemons mit ExecReload = auslösen, sondern auch einen Befehl festlegen, der darauf wartet, dass der Daemon synchron abgeschlossen wird.

ExecStop= Gibt den Befehl an, der ausgeführt werden soll, um Dienste zu stoppen, die mit ExecStart = gestartet wurden. Das Argument verwendet mehrere Befehlszeilen gemäß demselben Schema, das oben in ExecStart = beschrieben wurde. Die Verwendung dieser Einstellung ist optional. Nachdem der mit dieser Option konfigurierte Befehl ausgeführt wurde, wird der Dienst gestoppt und alle verbleibenden Prozesse werden gemäß der entsprechenden Einstellung KillMode beendet (siehe systemd.kill (5)). Wenn diese Option nicht angegeben ist, wird der Prozess beendet, indem das von KillSignal angegebene Signal entsprechend gesendet wird, wenn ein Servicestopp angefordert wird. Das Ersetzen von Spezifizierern und Umgebungsvariablen einschließlich "$ MAINPID" wird unterstützt.

Beachten Sie, dass es nicht ausreicht, den Dienst lediglich zum Beenden aufzufordern (z. B. eine Art Terminierungssignal in die Warteschlange zu stellen) und nicht auf das Beenden des Dienstes wartet. Der Rest des Serviceprozesses wird möglicherweise nicht ordnungsgemäß gestoppt, da er unmittelbar nach Beendigung des Befehls gemäß den KillMode-Status und KillSignal wie oben beschrieben beendet wird. Daher muss der angegebene Befehl eine synchrone Operation sein, keine asynchrone Operation.

Beachten Sie, dass der durch ExecStop = angegebene Befehl nur beim ersten erfolgreichen Start des Dienstes ausgeführt wird. Wenn der Dienst nie gestartet wurde oder nicht gestartet werden kann Wenn beispielsweise einer der in ExecStart =, [ExecStartPre =](# execstartpre-execstartpost) oder [ExecStartPost =](# execstartpre-execstartpost) angegebenen Befehle fehlschlägt (und mit - beginnt) (Wenn nicht angehängt ist) Oder es wird nicht aufgerufen, wenn das Zeitlimit überschritten wird.

Wenn der Dienst nicht ordnungsgemäß gestartet und wieder heruntergefahren werden kann, rufen Sie den Befehl mit ExecStopPost = auf. Beachten Sie auch, dass die Anforderung zum Neustart des Dienstes als Stoppoperation gefolgt von einer Startoperation implementiert wird. Das heißt, ExecStop = und ExecStopPost = werden während des Neustarts des Dienstes ausgeführt.

Wir empfehlen, diese Einstellung für Befehle zu verwenden, die mit Diensten kommunizieren, die eine saubere Beendigung anfordern. Wenn der mit dieser Option angegebene Befehl ausgeführt wird, müssen Sie davon ausgehen, dass der Dienst noch voll funktionsfähig ist und auf alle Befehle korrekt reagieren kann.

Die Prozedur nach der Bereinigung verwendet stattdessen ExecStopPost =.

ExecStopPost= Gibt zusätzliche Befehle an, die ausgeführt werden sollen, nachdem der Dienst beendet wurde. Dies schließt ein, wenn ein mit ExecStop = konfigurierter Befehl verwendet wird, ExecStop = für den Dienst nicht definiert ist oder der Dienst unerwartet beendet wird. Wird sein. Das Argument verwendet mehrere Befehlszeilen nach demselben Schema, das in ExecStart = beschrieben ist. Die Verwendung dieser Einstellungen ist optional. Unterstützt das Ersetzen von Spezifizierern und Umgebungsvariablen.

Im Gegensatz zu ExecStop = wird der in dieser Einstellung angegebene Befehl aufgerufen, wenn der Dienst nicht erfolgreich gestartet und erneut heruntergefahren wird.

Wir empfehlen, diese Einstellung für Bereinigungsvorgänge zu verwenden, die auch dann ausgeführt werden, wenn der Dienst nicht erfolgreich gestartet werden kann. Mit dieser Einstellung konfigurierte Befehle müssen auch dann ausgeführt werden können, wenn der Dienst nicht vorzeitig gestartet werden kann und unvollständig initialisierte Daten erhalten bleiben. Der Serviceprozess wurde bereits beendet, als die in dieser Einstellung angegebenen Befehle ausgeführt wurden, und sollte nicht versuchen, mit ihnen zu kommunizieren.

Alle mit dieser Einstellung konfigurierten Befehle sind das Ergebnis des Dienstes sowie der Hauptprozessbeendigungscode und der Status, die in den Umgebungsvariablen $ SERVICE_RESULT, $ EXIT_CODE, $ EXIT_STATUS festgelegt sind. Beachten Sie, dass es im Code aufgerufen wird. Weitere Informationen finden Sie unter systemd.exec (5).

RestartSec= Legt die Ruhezeit vor dem Neustart des durch Restart = festgelegten Dienstes fest. Nimmt einen Wert ohne Einheiten in Sekunden oder einen Zeitspannenwert wie "5min 20s". Der Standardwert ist "100 ms".

TimeoutStartSec= Stellen Sie die Zeit ein, um auf den Start zu warten. Wenn der Daemon-Dienst den Abschluss des Startvorgangs nicht innerhalb der konfigurierten Zeit benachrichtigt, gilt der Dienst als fehlgeschlagen und wird erneut heruntergefahren. Nimmt einen Wert ohne Einheiten in Sekunden oder einen Zeitspannenwert wie "5min 20s". Durch Übergeben von "unendlich" wird die Zeitüberschreitungslogik deaktiviert. Sofern nicht "Type = oneshot" verwendet wird, lautet der Standardwert "DefaultTimeoutStartSec" in der Manager-Konfigurationsdatei. In diesem Fall ist das Timeout standardmäßig deaktiviert (siehe systemd-system.conf (5)).

Wenn ein Dienst mit "Type = notify" "EXTEND_TIMEOUT_USEC = ..." sendet, kann dies die Startzeit über [TimeoutStartSec =](# timeoutstartsec) hinaus verlängern. Der erste Empfang dieser Nachricht muss erfolgen, bevor TimeoutStartSec = überschritten wird. Nachdem die Startzeit TimeoutStartSec = überschritten hat, wird EXTEND_TIMEOUT_USEC = ... wiederholt, bis der Dienststartstatus mit READY = 1 endet und der Service Manager den Service startet. Ermöglicht das Fortfahren. (Siehe sd_notify (3))

TimeoutStopSec= Diese Option hat zwei Zwecke. Konfigurieren Sie zunächst die Wartezeit für jeden Befehl ExecStop =. Wenn eine Zeitüberschreitung auftritt, wird der nachfolgende Befehl ExecStop = übersprungen und der Dienst durch "SIGTERM" beendet. Wenn der Befehl ExecStop = nicht angegeben ist, erhält der Dienst sofort ein "SIGTERM". Konfigurieren Sie dann die Wartezeit, bis der Dienst selbst beendet ist. Wenn es nicht innerhalb der angegebenen Zeit beendet wird, wird es von SIGKILL getötet (siehe `` KillMode-Ursachen in systemd.kill (5)). Nimmt einen Wert ohne Einheiten in Sekunden oder einen Zeitspannenwert wie "5min 20s". Durch Übergeben von "unendlich" wird die Zeitüberschreitungslogik deaktiviert. Der Standardwert ist "DefaultTimeoutStopSec wird geöffnet" in der Manager-Konfigurationsdatei (siehe systemd-system.conf (5)).

Wenn ein Dienst mit "Type = notify" "EXTEND_TIMEOUT_USEC = ..." sendet, kann die Ausfallzeit über [TimeoutStopSec =](# timeoutstopsec) hinaus verlängert werden. Der erste Empfang dieser Nachricht muss erfolgen, bevor TimeoutStopSec = überschritten wird, und nachdem die Stoppzeit TimeoutStopSec = überschritten hat, EXTEND_TIMEOUT_USEC = ... Wiederholen Sie diesen Vorgang, damit der Dienst beendet wird. (Siehe sd_notify (3))

TimeoutSec= Abkürzung für das Setzen von TimeoutStartSec = und TimeoutStopSec = auf die angegebenen Werte.

RuntimeMaxSec= Konfigurieren Sie die maximale Zeit, die der Dienst ausgeführt wird. Wenn dies verwendet wird und der Dienst länger als die angegebene Zeit aktiv war, wird der Dienst beendet und befindet sich in einem fehlgeschlagenen Zustand. Diese Einstellung wirkt sich nicht auf den Dienst "Type = oneshot" aus, da er sofort nach Abschluss der Aktivierung beendet wird. Durch das Übergeben von "unendlich" (Standard) werden keine Laufzeitlimits konfiguriert.

Wenn ein Dienst mit "Type = notify" "EXTEND_TIMEOUT_USEC = ..." sendet, kann die Ausführungszeit über RuntimeMaxSec = hinaus verlängert werden. Der erste Empfang dieser Nachricht muss erfolgen, bevor RuntimeMaxSec = überschritten wird. Wenn die Ausführungszeit über RuntimeMaxSec = hinaus verlängert wird, führt der Service Manager den Service aus. Ermöglichen. Wenn der Dienst während des Intervalls "EXTEND_TIMEOUT_USEC = ..." wiederholt, wird dies angegeben, bis "STOPPING = 1" (oder Beendigung) das Herunterfahren des Dienstes erreicht. (Siehe sd_notify (3))

WatchdogSec= Stellen Sie das Watchdog-Timeout für den Dienst ein. Der Wachhund wird aktiv, wenn der Start abgeschlossen ist. Der Dienst sollte sd_notify (3) regelmäßig mit WATCHDOG = 1 aufrufen (dh Keep-Alive-Ping). Wenn die Zeit zwischen diesen beiden Aufrufen länger als die konfigurierte Zeit ist, geht der Dienst in einen fehlgeschlagenen Zustand über und endet mit "SIGABRT" (oder dem von "WatchdogSignal" angegebenen Signal). Wenn Sie Restart = auf "On-Failure", "On-Watchdog", "On-Abnormal" oder "Always" setzen, wird der Dienst automatisch neu gestartet. Ich werde. Die hier eingestellte Zeit wird an den Serviceprozess übergeben, der mit der Umgebungsvariablen WATCHDOG_USEC = ausgeführt wird. Auf diese Weise kann der Dämon automatisch die "Keep-Alive-Ping" -Logik aktivieren, wenn die Watchdog-Unterstützung für den Dienst aktiviert ist. Wenn Sie diese Option verwenden, müssen Sie NotifyAccess = (#notifyaccess) festlegen, um den Zugriff auf den von systemd bereitgestellten Benachrichtigungssocket zu öffnen. Wenn NotifyAccess = nicht festgelegt ist, wird implizit auf main festgelegt. Der Standardwert ist 0, wodurch diese Funktion deaktiviert wird. Der Dienst kann sehen, ob der Dienstmanager erwartet, dass Watchdog-Benachrichtigungen am Leben bleiben. Weitere Informationen finden Sie unter sd_watchdog_enabled (3). Sie können sd_event_set_watchdog (3) verwenden, um die automatische Unterstützung für Watchdog-Benachrichtigungen zu aktivieren.

Restart= Konfigurieren Sie, ob der Serviceprozess beendet, beendet oder neu gestartet wird, wenn das Zeitlimit erreicht ist. Der Serviceprozess kann der Hauptserviceprozess sein, aber [ExecStartPre =](# execstartpre-execstartpost), [ExecStartPost =](# execstartpre-execstartpost), ExecStop =, [ExecStopPost =](# Dies kann auch einer der durch execstoppost angegebenen Prozesse oder ExecReload = sein. Wenn der Prozessstopp das Ergebnis einer systemd-Operation ist (z. B. Stoppen oder Neustarten des Dienstes), wird der Dienst nicht neu gestartet. Zu den Zeitüberschreitungen gehören Watchdog-Keep-Alive-Ping-Fehlzeiten, fehlende Ablaufzeiten für das Starten, Neuladen und Stoppen von Vorgängen.

Nehmen Sie eine der folgenden Möglichkeiten:

** Tabelle 2. Ursachen der Beendigung und die Auswirkungen der Einstellung "Neustart nacheinander" auf sie **

Starten Sie die Einstellungen neu/Kündigungsgrund no always on-success on-failure on-abnormal on-abort on-watchdog
Clean exit code or signal X X
Unclean exit code X X
Unclean signal X X X X
Timeout X X X
Watchdog X X X X

Als Ausnahme zu den obigen Einstellungen wird der Dienst neu gestartet, wenn in RestartPreventExitStatus = ein Beendigungscode oder -signal angegeben ist (#restartpreventexitstatus) oder wenn der Dienst durch "systemctl stop" oder eine gleichwertige Operation gestoppt wird. Es wird nicht starten. Wenn in RestartForceExitStatus = ein Beendigungscode oder -signal angegeben ist, wird der Dienst immer neu gestartet.

Beachten Sie, dass der Neustart des Dienstes von der Begrenzung der Startrate der Einheit betroffen ist, die aus "StartLimitIntervalSec wird geöffnet" und "StartLimitBurst nacheinander" besteht. Weitere Informationen finden Sie unter systemd.unit (5). Der neu gestartete Dienst schlägt erst fehl, nachdem das Startlimit erreicht wurde.

Die Einstellung "On-Failure" ist die empfohlene Option für Dienste mit langer Laufzeit, um eine automatische Wiederherstellung nach Fehlern zu versuchen und die Zuverlässigkeit zu verbessern. Sie können Dienste, die nach eigener Wahl beendet (und nicht sofort neu gestartet) werden können, durch "on-abnormal" ersetzen.

SuccessExitStatus= Beendigungscode 0 und Signale SIGHUP, SIGINT, SIGTERM, SIGPIPE bei Rückgabe vom Hauptdienstprozess sowie der als erfolgreich angesehene Beendigungsstatus Holen Sie sich eine Liste der Definitionen. Die Endstatusdefinition ist entweder ein durch Leerzeichen getrennter numerischer Endcode oder ein Endsignalname.

Beschreibungsbeispiel


SuccessExitStatus = 1 2 8 SIGKILL

In diesem Beispiel werden der Endcode 1, 2, 8 und das Endsignal "SIGKILL" als das Ende des sauberen Dienstes betrachtet.

Diese Option wird möglicherweise mehrmals angezeigt. In diesem Fall wird die Liste der erfolgreichen Abschlussstatus zusammengeführt. Wenn dieser Option eine leere Zeichenfolge zugewiesen wird, wird die Liste zurückgesetzt und alle Zuweisungen vor der leeren Zeichenfolge werden ungültig.

RestartPreventExitStatus= Ruft eine Liste der Definitionen des Beendigungsstatus ab, die einen automatischen Neustart von Diensten verhindern, unabhängig von den mit Restart =](#restart) konfigurierten Neustarteinstellungen, wenn diese vom Hauptdienstprozess zurückgegeben werden. Die Endstatusdefinition ist entweder ein numerischer Endcode oder ein Endsignalname, der durch ein Leerzeichen getrennt ist. Standardmäßig ist die Liste leer, sodass der Beendigungsstatus nicht von der konfigurierten Neustartlogik ausgeschlossen wird.

Beschreibungsbeispiel


RestartPreventExitStatus = 1 6 SIGABRT

Dieses Beispiel verhindert, dass der Dienst durch die Abschlusscodes 1 und 6 und das Abschlusssignal "SIGABRT" automatisch neu gestartet wird. Diese Option wird möglicherweise mehrmals angezeigt. In diesem Fall wird die Liste der Status für die Verhinderung des Neustarts zusammengeführt. Wenn dieser Option eine leere Zeichenfolge zugewiesen wird, wird die Liste zurückgesetzt und alle Zuweisungen vor der leeren Zeichenfolge werden ungültig.

RestartForceExitStatus= Ruft eine Liste der Beendigungsstatusdefinitionen ab, die einen automatischen Neustart des Dienstes erzwingen, unabhängig von der mit Restart =](#restart) konfigurierten Neustarteinstellung, wenn sie vom Hauptdienstprozess zurückgegeben werden. Das Format des Arguments ähnelt RestartPreventExitStatus =.

RootDirectoryStartOnly= Nimmt ein boolesches Argument. Für true Das mit RootDirectory = option konfigurierte Stammverzeichnis (Details siehe systemd.exec (5)) gilt nur für Prozesse, die mit ExecStart = gestartet wurden. Gilt für andere [ExecStartPre =](# execstartpre-execstartpost), [ExecStartPost =](# execstartpre-execstartpost), ExecReload =, ExecStop =, [ExecStopPost =]( Dies gilt nicht für den Befehl #execstoppost). Wenn false, wird die Einstellung auf alle konfigurierten Befehle auf die gleiche Weise angewendet. Der Standardwert ist "false".

NonBlocking= Setzen Sie das O_NONBLOCK-Flag für alle Dateideskriptoren, die durch Socket-basierte Aktivierung übergeben werden. Wenn true, sind alle Dateideskriptoren> = 3 (dh stdin, ) mit Ausnahme derjenigen, die die Dateideskriptorspeicherlogik durchlaufen (siehe [FileDescriptorStoreMax =](#filedescriptorstoremax) für Details). stdout, außer` `stderr) befindet sich im nicht blockierenden Modus, da das O_NONBLOCK-Flag gesetzt ist. Diese Option ist nur in Kombination mit einer Socket-Einheit nützlich, wie in systemd.socket (5) beschrieben, und wirkt sich nicht auf Dateideskriptoren aus, die zuvor im Dateideskriptorspeicher usw. gespeichert wurden. Der Standardwert ist false.

NotifyAccess= Steuert den Zugriff auf den Dienststatus-Benachrichtigungssocket, sodass mit dem Aufruf sd_notify (3) auf ihn zugegriffen werden kann. Nehmen Sie eine der folgenden Möglichkeiten:

Diese Option muss so eingestellt sein, dass der Zugriff auf den Benachrichtigungssocket geöffnet wird, wenn Type = notify oder WatchdogSec = verwendet wird (siehe oben). Wenn diese Optionen verwendet werden, NotifyAccess = (#notifyaccess) jedoch nicht konfiguriert ist, wird sie implizit auf main gesetzt.

Beachten Sie, dass sd_notify () - Benachrichtigungen einer Einheit nur dann korrekt zugeordnet sind, wenn der Sendevorgang noch vorhanden ist, wenn PID 1 die Nachricht verarbeitet, oder wenn der Sendevorgang vom Service Manager explizit zur Laufzeit verfolgt wird. Bitte. Letzteres ist der Fall, wenn der Service Manager den Prozess zum ersten Mal verzweigt, dh alle Prozesse, die mit main oder exec übereinstimmen. Wenn umgekehrt der Hilfsprozess des Geräts eine sd_notify () - Nachricht sendet und sofort beendet wird, kann der Servicemanager die Nachricht nicht ordnungsgemäß mit dem Gerät verknüpfen, selbst wenn "NotifyAccess = all" festgelegt ist. Ignorieren Sie die Nachricht.

Sockets= Gibt den Namen der Socket-Einheit an, die den Socket-Dateideskriptor beim Start des Dienstes erbt. Normalerweise müssen Sie diese Einstellung nicht verwenden. Alle Socket-Dateideskriptoren (mit unterschiedlichen Einheitenerweiterungen), die dieselbe Einheit wie der Dienst haben, werden an den erzeugten Prozess übergeben.

Beachten Sie, dass derselbe Socket-Dateideskriptor gleichzeitig an mehrere Prozesse übergeben werden kann. Beachten Sie außerdem, dass der eingehende Socket-Verkehr möglicherweise einen anderen Dienst aktiviert als den, der zum Erben des Socket-Dateideskriptors konfiguriert ist. Mit anderen Worten, die "Service-angemessene Einstellung der" .socket "-Einheit muss nicht mit der Umkehrung der Sockets = -Einstellung der" .service "-Einstellung übereinstimmen, auf die sie verweist.

Diese Option wird möglicherweise mehrmals angezeigt. In diesem Fall wird die Liste der Socket-Einheiten zusammengeführt. Wenn dieser Option eine leere Zeichenfolge zugewiesen wird, wird die Liste der Sockets zurückgesetzt und die vor der leeren Zeichenfolge angegebenen Einstellungen haben keine Auswirkung.

FileDescriptorStoreMax= Verwenden Sie die Nachricht FDSTORE = 1 in sd_pid_notify_with_fds (3), um die Anzahl der Dateideskriptoren zu konfigurieren, die im Service Manager des Service gespeichert werden können. Dies hilft bei der Implementierung von Diensten, die nach einer expliziten Anforderung oder einem Absturz ohne Statusverlust neu gestartet werden können. Auf diese Weise können geöffnete Sockets und andere Dateideskriptoren gespeichert werden, die während eines Neustarts nicht geschlossen werden sollten. Der Status der Anwendung kann in eine Datei in / run serialisiert oder im memfd_create (2) Speicherdateideskriptor gespeichert werden. Der Standardwert ist 0. Das heißt, Sie können einen Dateideskriptor nicht in einem Service-Deskriptor speichern. Alle Dateideskriptoren, die von einem bestimmten Dienst an den Dienstmanager übergeben werden, werden beim nächsten Neustart des Dienstes an den Hauptprozess des Dienstes zurückgegeben. Der an den Service Manager übergebene Dateideskriptor ist, wenn "POLLHUP" oder "POLLERR" angezeigt wird oder der Service vollständig gestoppt wird und der Job nicht in die Warteschlange gestellt wird oder ausgeführt wird. Wenn es automatisch schließt. Wenn Sie diese Option verwenden, müssen Sie NotifyAccess = (#notifyaccess) festlegen, um den Zugriff auf den von systemd bereitgestellten Benachrichtigungssocket zu öffnen. Wenn NotifyAccess = nicht festgelegt ist, wird implizit auf main festgelegt.

USBFunctionDescriptors= Legen Sie den Speicherort der Datei fest, die den Deskriptor USB FunctionFS enthält, um die USB-Gadget-Funktion zu implementieren. Dies wird nur in Kombination mit Socket-Einheiten verwendet, bei denen die ListenUSBFunction richtig eingestellt ist. Der Inhalt dieser Datei wird nach dem Öffnen in die Datei "ep0" geschrieben.

USBFunctionStrings= USB FunctionFS Konfiguriert den Speicherort von Dateien, die Zeichenfolgen enthalten. Die Operation ähnelt USBFunctionDescriptors = oben.

Überprüfen Sie systemd.exec (5) und systemd.kill (5) auf andere Einstellungen.

Befehlszeile

In diesem Abschnitt werden die folgenden optionalen Befehlszeilenanalysen sowie das Ersetzen von Variablen und Bezeichnern beschrieben.

Sie können mehrere Befehlszeilen zu einer einzigen Anweisung verketten, indem Sie sie durch Semikolons trennen (diese Semikolons müssen als separate Wörter übergeben werden). Ein einzelnes Semikolon kann als \; maskiert werden.

Jede Befehlszeile ist durch ein Leerzeichen getrennt. Das erste Element ist der auszuführende Befehl und das zweite Element sind die Argumente. Doppelte Anführungszeichen ("...") und einfache Anführungszeichen ('...') können verwendet werden, um das gesamte Element zu verpacken. (Startzitate können nur am Anfang oder nach einem Leerzeichen angezeigt werden, das nicht in Anführungszeichen eingeschlossen ist, und auf Endzitate folgt ein Leerzeichen oder ein Zeilenende.) In diesem Fall ist alles bis zum nächsten übereinstimmenden Zitat Teil desselben Arguments und das Zitat selbst wird entfernt. Das Escaping im C-Stil wird ebenfalls unterstützt. In der folgenden Tabelle sind die bekannten Escape-Muster aufgeführt. Es sind nur Escape-Muster zulässig, die der Syntax der Tabelle entsprechen. In Zukunft können weitere Muster hinzugefügt werden, und unbekannte Muster sind eine Warnung. Insbesondere muss der Backslash verdoppelt werden. Sie können Backslashes (\) am Zeilenende verwenden, um Zeilen zusammenzuführen.

Diese Syntax wird von der Shell-Syntax beeinflusst, es werden jedoch nur die unten beschriebenen Metazeichen und Erweiterungen interpretiert, und die Variablenerweiterungen sind unterschiedlich. Umleiten mit <, <<, > , >>, Pipe mit |, & Das Ausführen des Programms im verwendeten Hintergrund und andere Elemente der Shell-Syntax werden nicht unterstützt.

Der von Ihnen ausgeführte Befehl kann Leerzeichen enthalten, Sie können jedoch keine Steuerzeichen verwenden.

Die Befehlszeile akzeptiert den Bezeichner % , wie in systemd.unit (5) beschrieben.

Das Ersetzen grundlegender Umgebungsvariablen wird unterstützt. Wenn Sie $ {FOO} in der Befehlszeile als Teil eines Wortes oder als einzelnes Wort verwenden $ {FOO} wird durch den Wert der Umgebungsvariablen (einschließlich Leerzeichen) ersetzt, durch den Wert der Umgebungsvariablen ersetzt, durch Leerzeichen getrennt, 0 oder mehr Argumente werden generiert und in ein einzelnes Argument konvertiert. Getan werden. Wenn Sie "$ FOO" als ein anderes Wort in der Befehlszeile verwenden Zitate haben Vorrang, wenn sie in Wörter aufgeteilt und dann entfernt werden.

Wenn der Befehl kein vollständiger (absoluter) Pfad ist, wird er unter Verwendung eines festen Suchpfads, der zur Kompilierungszeit festgelegt wurde, in einen vollständigen Pfad aufgelöst. Die durchsuchten Verzeichnisse sind / usr / bin / und / usr / local / bin /, / usr / bin / auf Systemen, die das Verzeichnis / bin / verwenden. , / bin / und das entsprechende sbin / für Systeme, die bin /, sbin / verwenden. Daher ist es sicher, nur den Namen der ausführbaren Datei für ausführbare Dateien zu verwenden, die sich in einem der "Standard" -Verzeichnisse befinden. Der absolute Pfad sollte verwendet werden, wenn er sich nicht im Standardverzeichnis befindet. Es wird empfohlen, absolute Pfade zu verwenden, um Mehrdeutigkeiten zu vermeiden.

Tipp: Sie können diesen Suchpfad mit dem systemd-path search-binaries-default abfragen.

Beschreibungsbeispiel


Environment="ONE=one" 'TWO=two two'
ExecStart=echo $ONE $TWO ${TWO}

In diesem Beispiel wird / bin / echo mit 4 Argumenten ausgeführt.

  1. one
  2. two
  3. two
  4. two two

Beschreibungsbeispiel


Environment=ONE='one' "TWO='two two' too" THREE=
ExecStart=/bin/echo ${ONE} ${TWO} ${THREE}
ExecStart=/bin/echo $ONE $TWO $THREE

Dies ruft zweimal / bin / echo auf, zuerst mit den Argumenten 'one', ' two two 'too, "" und dann Das zweite Mal wird es mit den Argumenten "eins", "zwei zwei", "auch" aufgerufen.

Verwenden Sie $$, um das wörtliche Dollarzeichen zu übergeben. Variablen, deren Wert beim Erweitern unbekannt ist, werden als leere Zeichenfolgen behandelt. Beachten Sie, dass das erste Argument (dh das auszuführende Programm) möglicherweise keine Variable ist.

Die auf diese Weise verwendeten Variablen können in Environment angemessen und EnvironmentFile insbesondere definiert werden. Sie können auch die Variablen verwenden, die als "statische Konfiguration" gelten und im Abschnitt "Umgebungsvariablen für generierte Prozesse" von systemd.exec (5) aufgeführt sind (dies schließt "$ USER" ein). Enthält nicht $ TERM).

Bitte beachten Sie, dass Shell-Befehlszeilen nicht direkt unterstützt werden. Wenn Sie die Shell-Befehlszeile verwenden, müssen Sie sie explizit an eine Shell-Implementierung übergeben.

Beschreibungsbeispiel


ExecStart=sh -c 'dmesg | tac'

Beschreibungsbeispiel


ExecStart=echo one ; echo "two two"

Dies führt dazu, dass das Echo zweimal ausgeführt wird, jeweils mit einem Argument, "eins" bzw. "zwei zwei". Sie müssen "Type = oneshot" verwenden, da zwei Befehle angegeben sind.

Beschreibungsbeispiel


ExecStart=echo / >/dev/null & \; \
ls

In diesem Beispiel wird das Echo mit 5 Argumenten ausgeführt.

  1. /
  2. >/dev/null
  3. &
  4. ;
  5. ls

** Tabelle 3. In Befehlszeilen und Umgebungsvariablen unterstützte C-Escapezeichen **

wörtlich Tatsächlicher Wert
\a bell
\b backspace
\f form feed
\n newline
\r carriage return
\t tab
\v vertical tab
\\ backslash
\" Anführungszeichen
\' Anführungszeichen
\s space
\xxx Sechseckig codierte Zeichennummer xx
\nnn Achte Kodierungszeichennummer nnn

Beschreibungsbeispiel

Beispiel 1. Ein Dienst mit Type = simple

Die folgende Unit-Datei erstellt einen Dienst, der / usr / sbin / foo-daemon ausführt. Der Standardwert "Type = simple" wird angenommen, da Type = nicht angegeben ist. systemd erwartet, dass das Gerät kurz nach dem Start des Programms startet.

[Unit]
Description=Foo

[Service]
ExecStart=/usr/sbin/foo-daemon

[Install]
WantedBy=multi-user.target

Beachten Sie, dass in diesem Beispiel systemd davon ausgeht, dass der von systemd gestartete Prozess bis zum Ende des Dienstes bestehen bleibt. Wenn sich Ihr Programm selbst dämonisiert (z. B. eine Gabelung), verwenden Sie stattdessen Type = forking.

Da ExecStop = nicht angegeben ist, sendet systemd "SIGTERM" an alle Prozesse, die von diesem Dienst gestartet wurden, und "SIGKILL" auch nach dem Timeout. Dieses Verhalten kann geändert werden. Weitere Informationen finden Sie unter systemd.kill (5).

Dieser Einheitentyp enthält keine Benachrichtigung, wenn die Dienstinitialisierung abgeschlossen ist. Type = notify, wenn der Dienst das systemd-Benachrichtigungsprotokoll versteht, Type = forking, wenn der Dienst sich selbst im Hintergrund verarbeiten kann, und das Gerät gibt den DBus-Namen nach Abschluss der Initialisierung an. Sie müssen einen anderen Einheitentyp verwenden, z. B. "Type = dbus", um ihn abzurufen. Bitte beachten Sie Folgendes.

Beispiel 2. Ein Dienst mit Type = oneshot

Einheiten müssen möglicherweise Aktionen ausführen, ohne einen aktiven Prozess aufrechtzuerhalten, z. B. Dateisystemprüfungen und Startbereinigungsaktionen. Type = oneshot existiert für solche Fälle. Dieser Einheitentyp wartet, bis der angegebene Prozess beendet ist, bevor er inaktiv zurückfällt. Die folgenden Einheiten führen Bereinigungsaktionen aus:

[Unit]
Description=Cleanup old Foo data

[Service]
Type=oneshot
ExecStart=/usr/sbin/foo-cleanup

[Install]
WantedBy=multi-user.target

systemd betrachtet das Gerät bis zum Ende des Programms als "Start". Daher beginnen geordnete Abhängigkeiten nach Abschluss des Programms. Das Gerät kehrt nach Abschluss der Ausführung in den Zustand "inaktiv" zurück und befindet sich niemals im Zustand "aktiv". Das heißt, eine weitere Anforderung zum Starten des Geräts führt die Aktion erneut aus.

Type = oneshot ist die einzige Serviceeinheit, für die möglicherweise mehrere ExecStart = angegeben sind. Sie werden nacheinander ausgeführt, bis alle erfolgreich sind oder einer fehlschlägt.

Beispiel 3. Oneshot-Dienst, der gestoppt werden kann

Wie beim Oneshot-Dienst müssen einige Einheiten ein Programm ausführen, um etwas zu konfigurieren, und dann ein anderes Programm zum Herunterfahren ausführen, aber der Prozess ist aktiv, solange er als "gestartet" betrachtet wird. Bleibt. Netzwerkkonfigurationen können in diese Kategorie fallen. Ein weiterer Anwendungsfall ist, wenn der Oneshot-Dienst nicht ausgeführt wird, wenn er als Abhängigkeit aufgerufen wird, sondern nur zum ersten Mal.

Daher kennt systemd die Einstellung RemainAfterExit = yes. Dadurch kann systemd davon ausgehen, dass das Gerät aktiv ist, wenn die Startaktion erfolgreich abgeschlossen wurde. Diese Direktive kann mit allen Typen verwendet werden, ist jedoch am nützlichsten bei "Type = oneshot" und "Type = simple". Wenn Type = oneshot, wartet systemd auf den Abschluss der Startaktion, bevor die Einheit als aktiv betrachtet wird, sodass die Abhängigkeit erst nach erfolgreicher Startaktion gestartet wird. Wenn Type = simple, wird die Abhängigkeit sofort nach dem Auslösen der Startaktion gestartet. Das Folgende ist ein Beispiel für eine einfache statische Firewall.

[Unit]
Description=Simple 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

Nachdem die Startaktion beendet ist, wird die Einheit als ausgeführt betrachtet, sodass das erneute Aufrufen von "systemctl start" auf dieser Einheit keine Aktion ausführt.

Beispiel 4. Traditioneller Gabelservice

Viele traditionelle Daemon- / Service-Hintergründe (z. B. fork, daemonize) stellen sich beim Start in den Hintergrund. Um diesen Betriebsmodus zu unterstützen, setzen Sie "Type = Forking" in die Unit-Datei des Dienstes. systemd betrachtet den Dienst als in der Initialisierung, während das ursprüngliche Programm noch ausgeführt wird. Der Dienst gilt als gestartet, wenn er erfolgreich beendet wird und mindestens der Prozess bestehen bleibt (oder "RemainAfterExit = no").

Traditionelle Dämonen bestehen oft nur aus einem Prozess. Wenn daher nach Beendigung des ursprünglichen Prozesses nur noch ein Prozess übrig bleibt, betrachtet systemd diesen Prozess als den Hauptprozess des Dienstes. In diesem Fall kann die Variable "$ MAINPID" mit ExecReload =, ExecStop = usw. verwendet werden.

Wenn mehr als ein Prozess übrig bleibt, kann systemd den Hauptprozess nicht bestimmen und geht nicht davon aus, dass dies der Fall ist. In diesem Fall wird $ MAINPID nicht erweitert. Wenn der Prozess jedoch beschließt, eine herkömmliche PID-Datei zu schreiben, kann systemd die Haupt-PID daraus lesen. Stellen Sie PIDFile = entsprechend ein. Beachten Sie, dass der Dämon die PID-Datei schreiben muss, bevor die Initialisierung abgeschlossen werden kann. Andernfalls versucht systemd möglicherweise, die PID-Datei zu lesen, bevor sie generiert wird.

Das folgende Beispiel zeigt einen einfachen Daemon, der einen Prozess im Hintergrund verzweigt und startet:

[Unit]
Description=Some simple daemon

[Service]
Type=forking
ExecStart=/usr/sbin/my-simple-daemon -d

[Install]
WantedBy=multi-user.target

Weitere Informationen dazu, wie sich systemd auf die Beendigung des Dienstes auswirkt, finden Sie unter systemd.kill (5).

Beispiel 5. dbus service

Verwenden Sie für Dienste, die ihren Namen auf dem DBus-Systembus erhalten, Type = dbus und setzen Sie den entsprechenden BusName =. Dienste sollten nicht gegabelt (dämonisiert) werden. systemd betrachtet den Dienst als initialisiert, wenn er seinen Namen auf dem Systembus erhält. Das folgende Beispiel zeigt einen typischen DBus-Dienst.

[Unit]
Description=Simple DBus service

[Service]
Type=dbus
BusName=org.example.simple-dbus-service
ExecStart=/usr/sbin/simple-dbus-service

[Install]
WantedBy=multi-user.target

Fügen Sie für Dienste, die auf dem Bus aktiviert werden können, den Abschnitt [Install] nicht in die systemd-Servicedatei ein. Verwenden Sie stattdessen die entsprechende Option `` SystemdService in der entsprechenden DBus-Servicedatei. Zum Beispiel (/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

Weitere Informationen dazu, wie sich systemd auf die Beendigung des Dienstes auswirkt, finden Sie unter systemd.kill (5).

Beispiel 6. Ein Dienst, der systemd über die Initialisierung benachrichtigt

Dienste mit Type = simple sind sehr einfach zu schreiben, haben jedoch den Hauptnachteil, dass systemd nicht benachrichtigt werden kann, dass die Initialisierung eines bestimmten Dienstes abgeschlossen ist. Aus diesem Grund unterstützt systemd ein einfaches Benachrichtigungsprotokoll, mit dem der Dämon systemd mitteilen kann, dass die Initialisierung abgeschlossen ist. Verwenden Sie dazu Type = notify. Eine typische Servicedatei für einen solchen Daemon sieht folgendermaßen aus:

[Unit]
Description=Simple notifying service

[Service]
Type=notify
ExecStart=/usr/sbin/simple-notifying-service

[Install]
WantedBy=multi-user.target

Beachten Sie, dass der Dämon das systemd-Benachrichtigungsprotokoll unterstützen muss. Andernfalls betrachtet systemd den Dienst noch nicht als gestartet und beendet den Dienst nach einer Zeitüberschreitung. Informationen zum Aktualisieren des Dämons zur transparenten Unterstützung dieses Protokolls finden Sie unter sd_notify (3). systemd betrachtet das Gerät als im Startzustand befindlich, bis eine fertige Benachrichtigung eintrifft.

Weitere Informationen dazu, wie sich systemd auf die Beendigung des Dienstes auswirkt, finden Sie unter systemd.kill (5).

SEE ALSO

NOTES

  1. Incompatibilities with SysV
  2. USB FunctionFS

Recommended Posts

man systemd.service Japanische Übersetzung
Mann systemd japanische Übersetzung
man nftables Japanische Übersetzung
sosreport Japanische Übersetzung
stromlinienförmige Erklärung japanische Übersetzung
Streamlit Tutorial Japanische Übersetzung
Dockerfile Reference Japanische Übersetzung
docker-compose --help japanische Übersetzung
Docker helfen japanische Übersetzung
Docker Build - Hilfe japanische Übersetzung
Japanische Übersetzung des sysstat-Handbuchs
Japanische Übersetzung des Linux-Handbuchs
Docker run --help japanische Übersetzung
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.3)
Docker mysql Quick Reference Japanische Übersetzung
Japanische Übersetzung des e2fsprogs-Handbuchs
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.1)
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.5)
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.8)
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.7)
Japanische Übersetzung des man-db Handbuchs
Angemessene japanische Übersetzung von pytorch tensor_tutorial
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.9)
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.6)
Japanische Übersetzung des Util-Linux-Handbuchs
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.2)
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.4)
Japanische Übersetzung des iproute2-Handbuchs
Japanische Übersetzung des Apache Spark-Dokuments - Schnellstart
[Google App Engine] Benutzerobjekte (japanische Übersetzung)
Erste Schritte: 30 Sekunden für die japanische Übersetzung von Keras
Biopython Tutorial und Kochbuch Japanische Übersetzung (Kapitel 1, 2)
Japanische Übersetzung: PEP 20 - Das Zen von Python