Es wird im Allgemeinen empfohlen, Type=simple wann immer möglich für langlaufende Dienste zu verwenden, da es die einfachste und schnellste Option ist. Da dieser Dienstetyp allerdings Fehler beim Starten nicht weiterleitet und keine Ordnung von anderen Units nach Abschluss der Initialisierung des Dienstes erlaubt (was beispielsweise für Clients sinnvoll ist, die sich mittels irgendeiner Art von IPC mit dem Dienst verbinden und der IPC-Kanal nur durch den Dienst selbst errichtet wird (statt dies vorab mittels Socket- oder Bus-Aktivierung oder ähnlichem zu erledigen)), könnte er in vielen Fällen nicht ausreichend sein. Dann sind notify oder dbus (Letzteres nur in dem Fall, in dem der Dienst eine D-Bus-Schnittstelle bereitstellt) die bevorzugten Optionen, da sie dem Dienstprogramm genau einzuplanen erlauben, wann der Dienst als erfolgreich gestartet betrachtet werden soll und wann mit den nachfolgenden Units fortgefahren werden soll. Der Dienstetyp notify benötigt explizite Unterstützung im Programmcode des Dienstes (da sd_notify() oder eine äquivalente API zum geeigneten Zeitpunkt durch den Dienst aufgerufen werden muss) — falls dies nicht unterstützt wird, ist forking eine Alternative: es unterstützt das Startprotokoll traditioneller UNIX-Dienste. Schließlich kann exec eine Option für die Fälle sein, in denen es ausreicht, sicherzustellen, dass das Dienstprogramm aufgerufen wurde und in denen das Dienstprogramm selbst keine oder nur sehr geringe Initialisierungen durchführt (und diese höchstwahrscheinlich erfolgreich sind). Beachten Sie, dass die Verwendung aller von simple verschiedenen Typen möglicherweise den Systemstartprozess verzögert, da der Diensteverwalter darauf warten muss, dass die Diensteinitialisierung abgeschlossen ist. Es wird daher empfohlen, nicht unnötigerweise von simple verschiedene Typen zu verwenden. (Es wird im Allgemeinen auch nicht empfohlen, idle oder oneshot für langlaufende Dienste zu verwenden.)

Im allgemeinen wird empfohlen, ExitType=main zu verwenden, wenn ein Dienst ein bekanntes Modell zur Erzeugung von Prozessen mit Fork hat und ein Hauptprozess zuverlässig bestimmt werden kann. ExitType= cgroup ist für Anwendungen gedacht, deren Modell zur Erzeugung von Prozessen mit Fork vorab unbekannt ist und die keinen bestimmten Hauptprozess haben könnten. Es ist gut für flüchtige oder automatisch erstellte Dienste, wie graphische Anwendungen innerhalb einer Desktop-Umgebung, geeignet.

Beachten Sie, dass PID-Dateien in modernen Projekten vermieden werden sollten. Verwenden Sie, wo möglich, Type=notify oder Type=simple, die keinen Einsatz von PID-Dateien benötigen, um den Hauptprozess des Dienstes zu bestimmen, und unnötige Aufrufe von Fork vermeiden.

Es muss genau ein Befehl angegeben werden, außer Type= ist auf oneshot gesetzt. Wenn Type=oneshot verwandt wird, dürfen Null oder mehr Befehle festgelegt werden. Befehle können durch Angabe mehrerer Befehlszeilen in der gleichen Anweisung angegeben werden oder alternativ kann diese Anweisung mehr als einmal mit der gleichen Wirkung angegeben werden. Falls dieser Option die leere Zeichenketten zugewiesen wird, wird die Liste der zu startenden Befehle zurückgesetzt und vorhergehende Zuweisungen zu dieser Option haben keinen Effekt. Falls kein ExecStart= angegeben ist, dann muss der Dienst RemainAfterExit=yes und mindestens eine gesetzte ExecStop=-Zeile haben. (Dienste, denen sowohl ExecStart= als auch ExecStop= fehlt, sind nicht gültig.)

Für jeden der festgelegten Befehle muss das erste Argument entweder ein absoluter Pfad zu einem Programm oder ein einfacher Dateiname ohne Schrägstriche sein. Optional kann dem Dateinamen eine Reihe von besonderen Zeichen vorangestellt werden:

Tabelle 1. Besondere Präfixe für Programme

»@«, »-«, »:« und eines aus »+«/»!«/»!!« können zusammen verwandt werden und in jeder Reihenfolge auftauchen. Allerdings darf nur einer von »+«, »!«, »!!« gleichzeitig benutzt werden. Beachten Sie, dass diese Zeichen auch den anderen Befehlzeileneinstellungen vorangestellt werden dürfen, d.h. ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop= und ExecStopPost=.

Falls mehr als ein Befehl angegeben ist, werden die Befehle der Reihe nach in der Reihenfolge, in der sie in der Unit-Datei auftauchen, ausgeführt. Falls einer der Befehle fehlschlägt (und ihm kein »-« vorangestellt ist) werden die anderen Zeilen nicht ausgeführt und die Unit wird als fehlgeschlagen betrachtet.

Außer falls Type=forking gesetzt ist, wird der über die Befehlszeile gestartete Prozess als Hauptprozess des Daemons betrachtet.

Falls einer dieser Befehle (dem nicht »-« vorangestellt ist) fehlschlägt, wird der Rest nicht ausgeführt und die Unit als fehlgeschlagen betrachtet.

ExecStart=-Befehle werden nur ausgeführt, nachdem alle ExecStartPre=-Befehle, denen kein »-« vorangestellt wurde, sich erfolgreich beendet haben.

ExecStartPost=-Befehle werden nur ausgeführt, nachdem die in ExecStart= festgelegten Befehle erfolgreich gestartet wurden, wie durch Type= festgelegt (d.h. der Prozess wurde für Type=simple oder Type=idle gestartet, der letzte ExecStart=-Prozess hat sich erfolgreich für Type=oneshot beendet, der anfängliche Prozess hat sich für Type=forking erfolgreich beendet, »READY=1« ist für Type=notify gesetzt oder der BusName= ist für Type=dbus genommen worden.

Beachten Sie, dass ExecStartPre= nicht zum Starten von langlaufenden Prozessen verwandt werden darf. Alle von mittels ExecStartPre= aufgerufenen Prozesse mittels Fork gestarteten Prozesse werden getötet, bevor der nächste Diensteprozess ausgeführt wird.

Beachten Sie, dass falls einer der in ExecStartPre=, ExecStart= oder ExecStartPost= festgelegten Prozesse fehlschlägt (und ihm kein »-« vorangestellt wurde, siehe oben) oder seine Zeit abgelaufen ist, bevor der Dienst vollständig hochgekommen ist, die Ausführung mit den in ExecStopPost= festgelegten Komponenten fortgefahren wird und die Befehle in ExecStop= übersprungen werden.

Beachten Sie, dass die Ausführung von ExecStartPost= zum Zwecke der Before=/After= Ordnungsbeschränkungen berücksichtigt wird.

Das Verhalten ist wie ein ExecStartPre= und die Bedingungsprüfung erfolgt hybrid: wenn sich ein ExecCondition=-Befehl mit Exit-Code 1 bis 254 (einschließlich) beendet, werden die verbleibenden Befehle übersprungen und die Unit wird nicht als fehlgeschlagen markiert. Falls sich allerdings ein ExecCondition=-Befehl mit 255 oder unnormal (z.B. wegen einer Zeitüberschreitung, durch ein Signal getötet) beendet, wird die Unit als fehlgeschlagen betrachtet (und die verbliebenen Befehle übersprungen). Exit-Code 0 oder solche, die auf SuccessExitStatus= passen, führen zur Ausführung der nächsten Befehle.

Die gleiche Empfehlung, keine langlaufenden Prozesse in ExecStartPre= auszuführen, gilt auch für ExecCondition=. ExecCondition= wird, falls eine Beendigung nicht Null oder unnormal erfolgt, beim Stoppen des Dienstes auch die in ExecStopPost= aufgeführten Befehle ausführen, wie die oben beschriebenen.

Eine zusätzliche, besondere Umgebungsvariable wird gesetzt: falls bekannt, wird $MAINPID auf den Hauptprozess des Daemons gesetzt und kann für Befehlszeilen wie der folgenden benutzt werden:

ExecReload=kill -HUP $MAINPID

Beachten Sie, dass das Neuladen eines Daemons durch Senden eines Signals (wie in dem obigen Beispiel) normalerweise keine gute Wahl ist, da dies eine asynchrone Aktion und daher nicht dazu geeigent ist, das Neuladen von mehreren Diensten untereinander zu sortieren. Es wird nachdrücklich empfohlen, ExecReload= auf einen Befehl zu setzen, der nicht nur das Neuladen des Daemons auslöst, sondern auch synchron darauf wartet, dass dies abgeschlossen wird. Beispielsweise verwendet dbus-broker(1) Folgendes:

ExecReload=busctl call org.freedesktop.DBus \


        /org/freedesktop/DBus org.freedesktop.DBus \


        ReloadConfig

Beachten Sie, dass es normalerweise nicht ausreicht, einen Befehl für diese Einstellung festzulegen, der nur um das Beenden des Dienstes bittet (beispielsweise durch Senden einer Art von Signal an es), aber dann nicht darauf wartet, dass es auch passiert. Da die verbleibenden Prozesse des Dienstes, direkt nachdem der Befehl sich beendet hat, gemäß den oben beschriebenen KillMode= und KillSignal= oder RestartKillSignal= getötet werden, kann dies zu einem unsauberen Stopp führen. Der angegebene Befehl sollte daher eine synchrone Aktion und nicht eine asynchrone sein.

Beachten Sie, dass die in ExecStop= festgelegten Befehle nur ausgeführt werden, wenn der Dienst zuerst erfolgreich gestartet wird. Sie werden nicht aufgerufen, falls der Dienst überhaupt nie gestartet wurde oder im Falle, dass das Starten fehlschlug, beispielsweise weil einer der in ExecStart=, ExecStartPre= oder ExecStartPost= festgelegten Befehle fehlschlug (oder ihm kein »-« vorangestellt wurde, siehe oben) oder eine Zeitüberschreitung erfolgte. Verwenden Sie ExecStopPost=, um Befehle aufzurufen, wenn ein Dienst nicht korrekt startete und wieder heruntergefahren wird. Beachten Sie auch, dass die Stopp-Aktion immer durchgeführt wird, wenn der Dienst erfolgreich startete, selbst falls die Prozesse in dem Dienst sich von alleine beendeten oder getötet wurden. Der Stopp-Befehl muss für diesen Fall vorbereitet sein. $MAINPID wird nicht gesetzt sein, falls Systemd weiß, das sich der Hauptprozess zum Zeitpunkt des Aufrufs des Stopp-Befehls beendet hat.

Diensteneustartanfragen sind als Stopp-Aktionen gefolgt von Start-Aktionen implementiert. Dies bedeutet, dass während einer Diensteneustartaktion ExecStop= und ExecStopPost= ausgeführt werden.

Es wird empfohlen, diese Einstellung für Befehle zu verwenden, die mit dem Dienst kommunizieren, die das saubere Beenden erbitten. Für Post-mortem-Bereinigungsschritte verwenden Sie stattdessen ExecStopPost=.

Es wird empfohlen, diese Einstellung für Aufräumaktionen zu verwenden, die ausgeführt werden sollen, selbst wenn das korrekte Starten des Dienstes fehlschlug. Befehle, die mit dieser Einstellung konfiguriert sind, müssen in der Lage sein, zu funktionieren, selbst falls der Dienst mitten im Starten fehlschlug und unvollständig initialisierte Daten hinterließ. Da alle Prozesse des Dienstes bereits beendet wurden, wenn die mit dieser Einstellung festgelegten Befehle ausgeführt werden, sollten sie nicht versuchen, mit ihnen zu kommunizieren.

Beachten Sie, dass alle mit dieser Einstellung konfigurierten Befehle mit dem Ergebnis-Code des Dienstes sowie dem Exit-Code und -Status des Hauptprozesses, gesetzt auf die Umgebungsvariablen $SERVICE_RESULT, $EXIT_CODE und $EXIT_STATUS, aufgerufen werden, siehe systemd.exec(5) für Details.

Beachten Sie, dass die Ausführung von ExecStopPost= zum Zwecke der Before=/After= Ordnungsbeschränkungen berücksichtigt wird.

Falls ein Dienst vom Type=notify »EXTEND_TIMEOUT_USEC=…« sendet, kann dies dazu führen, dass die Startzeit sich über TimeoutStartSec= hinauszieht. Der erste Empfang dieser Nachricht muss auftreten, bevor TimeoutStartSec= überschritten wird und sobald die Startzeit sich über TimeoutStartSec= hinausgezogen hat, wird der Diensteverwalter dem Dienst die Weiterführung des Startens erlauben, vorausgesetzt, der Dienst wiederholt »EXTEND_TIMEOUT_USEC=…« innerhalb des festgelegten Intervalls, bis der Dienstestart durch »READY=1« abgeschlossen ist (siehe sd_notify(3)).

Falls ein Dienst vom Type=notify »EXTEND_TIMEOUT_USEC=…« sendet, kann dies dazu führen, dass die Stoppzeit sich über TimeoutStopSec= hinauszieht. Der erste Empfang dieser Nachricht muss auftreten, bevor TimeoutStopSec= überschritten wird und sobald die Stoppzeit sich über TimeoutStopSec= hinausgezogen hat, wird der Diensteverwalter dem Dienst die Weiterführung des Stoppens erlauben, vorausgesetzt, der Dienst wiederholt »EXTEND_TIMEOUT_USEC=…« innerhalb des festgelegten Intervalls oder beendet sich (siehe sd_notify(3)).

Akzeptiert einen Wert ohne Einheit in Sekunden oder einen Zeitdauerwert wie »5min 20s«. Übergeben Sie einen leeren Wert, um die Handhabung der zugeordneten Watchdog-Zeitüberschreitung zu überspringen und auf TimeoutStopSec= zurückzufallen. Übergeben Sie »infinity«, um die Zeitüberschreitungslogik zu überspringen. Standardmäßig DefaultTimeoutAbortSec= aus der Verwalterkonfigurationsdatei (siehe systemd-system.conf(5)).

Falls ein Dienst vom Type=notify SIGABRT selber handhabt (statt sich auf den Kernel zum Schreiben eines Speicherauszuges zu verlassen), kann er »EXTEND_TIMEOUT_USEC=…« senden, um die Abbruchzeit über TimeoutAbortSec= hinaus zu verlängern. Der erste Empfang dieser Nachricht muss auftreten, bevor TimeoutAbortSec= überschritten wird und sobald die Abbruchzeit sich über TimeoutAbortSec= hinausgezogen hat, wird der Diensteverwalter dem Dienst die Weiterführung des Abbrechens erlauben, vorausgesetzt, der Dienst wiederholt »EXTEND_TIMEOUT_USEC=…« innerhalb des festgelegten Intervalls oder beendet sich (siehe sd_notify(3)).

Falls terminate gesetzt ist, wird der Dienst sauber beendet, indem ihm das in KillSignal= festgelegte Signal (standardmäßig SIGTERM, siehe systemd.kill(5)) gesandt wird. Falls sich der Dienst nicht beendet, dann wird FinalKillSignal= nach TimeoutStopSec= gesendet. Falls abort gesetzt ist, wird stattdessen WatchdogSignal= gesandt und TimeoutAbortSec= gilt bevor FinalKillSignal= gesandt wird. Diese Einstellung kann zur Analyse von Diensten verwandt werden, die beim Hoch- oder Runterfahren zeitweilig fehlschlagen. Durch Verwendung von kill wird der Dienst sofort durch Senden von FinalKillSignal= beendet, ohne weitere Zeitüberschreitungen. Diese Einstellung kann zur Beschleunigung des Herunterfahrens von fehlgeschlagenen Diensten verwandt werden.

Falls ein Dienst vom Type=notify »EXTEND_TIMEOUT_USEC=…« sendet, kann dies dazu führen, dass die Laufzeit sich über RuntimeMaxSec= hinauszieht. Der erste Empfang dieser Nachricht muss auftreten, bevor RuntimeMaxSec= überschritten wird und sobald die Laufzeit sich über RuntimeMaxSec= hinausgezogen hat, wird der Diensteverwalter dem Dienst die Weiterführung des Laufens erlauben, vorausgesetzt, der Dienst wiederholt »EXTEND_TIMEOUT_USEC=…« innerhalb des festgelegten Intervalls, bis das Herunterfahren durch »STOPPING=1« (oder die Beendigung) erreicht wird (siehe sd_notify(3)).

Akzeptiert entweder no, on-success, on-failure, on-abnormal, on-watchdog, on-abort oder always. Falls auf no gesetzt (die Vorgabe), wird der Dienst nicht neu gestartet. Falls auf on-success gesetzt, wird er nur neu gestartet, wenn sich der Diensteprozess sauber beendet. In diesem Zusammenhang bedeutet ein sauberes Beenden folgendes:

Falls auf on-failure gesetzt, wird der Dienst neu gestartet, wenn der Prozess sich mit einem von Null verschiedenen Exit-Code beendet, durch ein Signal beendet wird (einschließlich eines Speicherauszuges, aber ausschließlich der vorher genannten Signale), wenn eine Aktion (wie das Neuladen eines Dienstes) in eine Zeitüberschreitung läuft und wenn die konfigurierte Watchdog-Zeitüberschreitung ausgelöst wird. Falls auf on-abnormal gesetzt, wird der Dienst neu gestartet, wenn der Prozess durch ein Signal beendet wird (einschließlich eines Speicherauszuges, aber ausschließlich der vorher genannten Signale), wenn eine Aktion in eine Zeitüberschreitung läuft und wenn die konfigurierte Watchdog-Zeitüberschreitung ausgelöst wird. Falls auf on-abort gesetzt, wird der Dienst nur neu gestartet, falls sich der Dienst aufgrund eines nicht abgefangenen Signals, das nicht als sauberer Exit-Status festgelegt ist, beendet hat. Falls auf on-watchdog gesetzt, wird der Dienst nur neu gestartet, wenn die Watchdog-Zeitüberschreitung für den Dienst abläuft. Falls auf always gesetzt, wird der Dienst neu gestartet, unabhängig davon, ob er sauber beendet wurde oder nicht, abnormal durch ein Signal beendet wurde oder in eine Zeitüberschreitung lief.

Tabelle 2. Exit-Gründe und der Effekt der Einstellung Restart=

Als Ausnahme zu den obigen Einstellungen wird der Dienst nicht neu gestartet, falls der Exit-Code oder das Exit-Signal in RestartPreventExitStatus= (siehe unten) festgelegt ist oder der Dienst mit systemctl stop oder einer äquivalenten Aktion gestoppt wird. Auch wird der Dienst immer neu gestartet, falls der Exit-Code oder das Exit-Signal in RestartForceExitStatus= (siehe unten) festgelegt ist.

Beachten Sie, dass der Diensteneustart der mit StartLimitIntervalSec= und StartLimitBurst= konfigurierten Unit-Startratenbegrenzung unterliegt, siehe systemd.unit(5) für Details. Ein neugestarteter Dienst tritt in den Fehlerzustand nur ein, nachdem die Startratenbegrenzungen erreicht wurden.

Für langlaufende Dienste wird empfohlen, dies auf on-failure zu setzen, um die Zuverlässigkeit zu erhöhen, indem die automatische Wiederherstellung bei Fehlern versucht wird. Für Dienste, die sich nach eigenen Kriterien beenden (und sofortige Neustarts vermeiden) können, ist on-abnormal eine alternative Wahl.

Beachten Sie, dass diese Einstellung nicht die Zuordnung zwischen numerischen Exit-Stati und ihren Namen ändert, d.h. unabhängig von der Verwendung dieser Einstellung wird 0 immer »SUCCESS« (und in der Ausgabe von Werkzeugen typischerweise als »0/SUCCESS« angezeigt) und 1 »FAILURE« zugeordnet (und daher typischerweise als »1/FAILURE« angezeigt) wird, und so weiter. Dies steuert nur, was als Auswirkung auf diese Exit-Stati passiert, und wie sie zum Zustand des Dienstes als Ganzes weitergeleitet wird.

Falls diese Option mehr als einmal auftaucht, wird die Liste der erfolgreichen Exit-Stati zusammengeführt. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird diese Liste zurückgesetzt und alle vorherigen Zuweisungen zu dieser Option haben keinen Effekt.

Beispiel 1. Ein Dienst mit der Einstellung SuccessExitStatus=

SuccessExitStatus=TEMPFAIL 250 SIGKILL

Exit-Status 75 (TEMPFAIL), 250 und das Beendigungssignal wird SIGKILL als saubere Dienstebeendigung betrachtet.

Beachten Sie: systemd-analyze exit-codes kann zur Auflistung der Exit-Stati und zur Übersetzung zwischen numerischen Code-Werten und Namen verwandt werden.

RestartPreventExitStatus=1 6 SIGABRT

Dies stellt sicher, dass die Exit-Codes 1 und 6 und das Beendigungssignal SIGABRT nicht zu einem automatischen Diensteneustart führen. Wenn diese Option mehr als einmal auftaucht, werden die Neustart-verhindernden Status zusammengeführt. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird diese Liste zurückgesetzt und alle vorherigen Zuweisungen zu dieser Option haben keinen Effekt.

Beachten Sie, dass diese Einstellung keine Auswirkung auf mittels ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost= oder ExecReload= konfigurierte Prozesse hat, sondern nur auf den Hauptdiensteprozess, d.h. entweder den mittels ExecStart= aufgerufenen oder (abhängig von Type=, PIDFile=, …) den anderweitig konfigurierten Hauptprozess.

Beachten Sie, dass sd_notify()-Benachrichtigungen nur Units korrekt zugeordnet werden können, falls entweder der sendende Prozess noch zu dem Zeitpunkt vorhanden ist, zu dem PID 1 die Nachricht verarbeitet oder falls der sendende Prozess explizit vom Diensteverwalter laufzeitverfolgt ist. Letzteres ist der Fall, falls der Diensteverwalter den Prozess ursprünglich mit fork erzeugte, d.h. bei allen Prozessen, die auf NotifyAccess=main oder NotifyAccess=exec passen. Umgekehrt, falls ein Hilfsprozess einer Unit eine sd_notify()-Nachricht sendet und sich sofort beendet, könnte der Diensteverwalter nicht in der Lage sein, die Nachricht korrekt der Unit zuzuordnen und wird sie daher ignorieren, selbst falls NotifyAccess=all für sie gesetzt ist.

Um daher alle Ressourcenwettläufe, die mit Nachschlagen von Units des Clients verknüpft sind, zu beseitigen und Benachrichtigungen Units richtig zuzuordnen, kann sd_notify_barrier() verwandt werden. Dieser Aufruf dient als Synchronisationspunkt und stellt sicher, dass alle Benachrichtigungen gesendete werden, bevor dieser Aufruf vom Diensteverwalter aufgenommen wird, wenn er erfolgreich zurückkehrt. Die Verwendung von sd_notify_barrier() wird für Clients benötigt, die nicht durch den Diensteverwalter aufgerufen werden, andernfalls ist dieser Synchronisationsmechanismus zur Zuordnung von Benachrichtigungen zu Units unnötig.

Beachten Sie, dass der gleiche Socket-Dateideskriptor simultan an mehrere Prozesse übergeben werden kann. Beachten Sie auch, dass ein anderer Dienst auf eingehenden Socket-Verkehr aktiviert werden kann als derjenige, der schließlich konfiguriert ist, den Socket-Dateideskriptor zu erben. Oder mit anderen Worten: Die Einstellung Service= von .socket-Units muss nicht auf das Inverse der Einstellung Sockets= von .service, auf die es sich bezieht, passen.

Falls diese Option mehr als einmal auftaucht, wird die Liste der Socket-Units zusammengeführt. Beachten Sie, dass das Bereinigen der Liste (beispielsweise durch Zuweisung der leeren Zeichenkette zu dieser Option) nicht unterstützt wird, sobald die Option einmal gesetzt wurde.

Wenn unter Linux der Speicher so knapp wird, dass der Kernel Schwierigkeiten bekommt, Speicher für sich selbst zu reservieren, dann kann er sich entscheiden, laufende Prozesse zu beenden, um Speicher freizugeben und den Speicherdruck zu reduzieren. Diese Einstellung akzeptiert entweder continue, stop oder kill. Falls auf continue gesetzt und ein Prozess des Dienstes vom OOM-Killer beendet wird, wird dies protokolliert aber die Unit läuft weiter. Falls auf stop gesetzt, wird das Ereignis protokolliert, aber die Unit wird sauber durch den Diensteverwalter beendet. Falls auf kill gesetzt und einer der Prozesse der Unit wird durch den OOM-Killer beendet, wird der Kernel angewiesen, auch alle verbleibenden Prozesse der Unit durch Setzen des Attributes memory.oom.group auf 1 durch den OOM-Killer zu beenden; siehe auch die Kerneldokumentation[2].

Standardmäßig der Wert, auf den die Einstellung DefaultOOMPolicy= in systemd-system.conf(5) gesetzt ist, außer bei Units, bei denen Delegate= eingeschaltet ist, wo die Vorgabe continue ist.

Verwenden Sie die Einstellung OOMScoreAdjust=, um zu konfigurieren, ob Prozesse der Unit als bevorzugte oder weniger bevorzugte Kandidaten für Prozessbeendigungen durch die Logik des OOM-Killers von Linux betrachtet werden sollen. Siehe systemd.exec(5) für Details.

Diese Einstellung gilt auch für systemd-oomd(8). Ähnlich wie beim Kernel-OOM-Killer bestimmt diese Einstellung den Zustand der Unit, nachdem systemd-oomd(8) eine ihr zugeordnete Cgroup beendet hat.

Environment="EINS=eins" 'ZWEI=zwei zwei'
ExecStart=echo $EINS $ZWEI ${ZWEI}

Environment=EINS='eins' "ZWEI='zwei zwei' auch" DREI=
ExecStart=/bin/echo ${EINS} ${ZWEI} ${DREI}
ExecStart=/bin/echo $EINS $ZWEI $DREI

ExecStart=sh -c 'dmesg | tac'

ExecStart=echo eins ; echo "zwei zwei"

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

[Unit]
Description=Foo
[Service]
ExecStart=/usr/sbin/foo-daemon
[Install]
WantedBy=multi-user.target

[Unit]
Description=Bereinigung alter Foo-Daten
[Service]
Type=oneshot
ExecStart=/usr/sbin/foo-cleanup
[Install]
WantedBy=multi-user.target

[Unit]
Description=Einfache Firewall
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/simple-firewall-start
ExecStop=/usr/local/sbin/simple-firewall-stop
[Install]
WantedBy=multi-user.target

[Unit]
Description=Ein einfacher Daemon
[Service]
Type=forking
ExecStart=/usr/sbin/my-simple-daemon -d
[Install]
WantedBy=multi-user.target

[Unit]
Description=Einfacher DBus-Dienst
[Service]
Type=dbus
BusName=org.example.simple-dbus-service
ExecStart=/usr/sbin/simple-dbus-service
[Install]
WantedBy=multi-user.target

[D-BUS Service]
Name=org.example.simple-dbus-service
Exec=/usr/sbin/simple-dbus-service
User=root
SystemdService=simple-dbus-service.service

[Unit]
Description=Einfacher Benachrichtigungsdienst
[Service]
Type=notify
ExecStart=/usr/sbin/simple-notifying-service
[Install]
WantedBy=multi-user.target