systemd forking vs simple?

Ich schreibe meine erste systemdEinheitendatei.

Für Typegibt es einige Möglichkeiten : forking, simpleusw. Ich habe die Redhat-Dokumentation zu diesem Thema gelesen (Tabelle 9.9), bin mir aber immer noch nicht sicher, wann ich welche Option verwenden soll.

Irgendwelche Richtlinien?

Was passiert, wenn Sie den Dienst manuell über die Befehlszeile starten (ohne den nohupPräfixbefehl oder das &Suffix zu verwenden, um ihn im Hintergrund auszuführen, oder mit anderen Worten, führen Sie einfach den Befehl aus, den Sie in die ExecStart=Zeile der .serviceDatei einfügen würden)?

a) Wenn der Dienst gestartet wird und weiter ausgeführt wird und die Eingabeaufforderung erst zurückkehrt, wenn Sie Strg-C drücken oder den Dienst auf andere Weise beenden, Type = simpleist dies die richtige Wahl.

b) Wenn die Eingabeaufforderung zurückgegeben wird, der Dienst jedoch weiterhin im Hintergrund ausgeführt wird (dh der Dienst dämonisiert sich selbst), Type = forkingist dies die richtige Wahl.

c) Wenn der Dienst seine Arbeit erledigt und zur Eingabeaufforderung zurückkehrt, ohne dass etwas ausgeführt wird (dh der Dienst passt nur einige Kerneleinstellungen an, sendet einen Befehl an etwas anderes oder führt etwas Ähnliches aus), Type = oneshotist dies wahrscheinlich die richtige Wahl. In diesem Fall ExecStartkönnte der Dienst der Befehl sein, etwas zu "setzen", und ExecStopder entsprechende Befehl, um es zu "deaktivieren". Dieser Typ profitiert normalerweise von RemainAfterExit=true, sodass systemd den "Status" dieses Dienstes nachverfolgt, je nachdem, ob das Objekt zuletzt "gesetzt" oder "nicht gesetzt" wurde.

Die anderen TypeWerte sind Sonderfälle. Wenn der Dienst beispielsweise eine D-Bus-Verbindung verwendet, ist dies Type = dbusmöglicherweise die beste Wahl. Es macht systemdsich der Tatsache bewusst, und dann verfolgt systemd diesen Dienst (und alles, was davon abhängt) durch das Vorhandensein dieses Dienstes auf dem D-Bus.

Zur Verwendung Type = notifymuss der Prozess in der Lage sein, eine Verbindung zum in der Umgebungsvariablen angegebenen Unix-Socket herzustellen $NOTIFY_SOCKETund seinen Status zu melden, indem bei Bedarf Nachrichten an diesen Socket geschrieben werden. Außerdem sollte in der Servicedatei die NotifyAccessOption angegeben werden, den entsprechenden Zugriff auf den Benachrichtigungssocket zu gewähren.

Es gibt ein Befehlszeilenprogramm systemd-notifyund eine C-Bibliotheksfunktion, mit der sd_notify(3)Sie diese Nachrichten senden können. Wenn jedoch keine dieser Funktionen Ihren Anforderungen entspricht, können Sie einfach Ihren eigenen Nachrichtensender implementieren. Die erforderlichen Nachrichten sind sehr einfach und sehen aus wie Zuweisungen von Shell-Variablen: Um beispielsweise zu benachrichtigen, dass der Dienst den Start erfolgreich abgeschlossen hat und bereit ist, eingehende Anforderungen zu bearbeiten, sollte der Dienst die Zeichenfolge senden, die der Ausgabe von printf "READY=1\n"an den Socket entspricht. Sehen Sie man 3 sd_notifyfür weitere Informationen über die erkannten Nachrichten.

Hinweis: Viele Dienstanwendungen, die für viele Unix-Systeme portierbar sind, verhalten sich möglicherweise standardmäßig wie b), können jedoch wie folgt funktionieren: a) Durch Hinzufügen einer Option (normalerweise als "Nicht gabeln" bezeichnet), "Weiter ausführen" im Vordergrund "," nicht dämonisieren "oder ähnliches). In diesem Fall wäre es vorzuziehen, die Option hinzuzufügen und das Verhalten vom Typ a) zu verwenden, wenn die Option keine anderen Nebenwirkungen hat systemd.