Alle Optionen werden im Abschnitt »[Manager]« konfiguriert:
LogColor=, LogLevel=, LogLocation=, LogTarget=, LogTime=, DumpCore=yes, CrashChangeVT=no, CrashShell=no, CrashReboot=no, ShowStatus=yes, DefaultStandardOutput=journal, DefaultStandardError=inherit
Konfigurieren verschiedene Parameter grundlegender Verwaltungsaktionen. Diese Optionen können durch die Befehlszeilenargumente des betreffenden Prozesses und des Kernels außer Kraft gesetzt werden. Siehe
systemd(1) für Details.
Hinzugefügt in Version 198.
CtrlAltDelBurstAction=
Definiert, welche Aktionen ausgeführt werden, falls der Benutzer Strg-Alt-Entf mehr als sieben Mal in 2 s drückt. Kann auf »reboot-force«, »poweroff-force«, »reboot-immediate«, »poweroff-immediate« gesetzt oder mittels »none« deaktiviert werden. Standardmäßig »reboot-force«.
Hinzugefügt in Version 232.
CPUAffinity=
Konfiguriert die CPU-Affinität für den Diensteverwalter sowie die Vorgabe-CPU-Affinität für alle mit Fork erstellten Prozesse. Erhält eine Liste von CPU-Indizes oder Bereichen, die entweder durch Leerraum oder Kommata getrennt sind. CPU-Bereiche werden durch den unteren und oberen CPU-Index, getrennt durch einen Bindestrich, festgelegt. Diese Option kann mehr als einmal angegeben werden, in diesem Fall werden die CPU-Affinitätsmasken zusammengeführt. Falls die leere Zeichenkette zugewiesen wird, wird die Maske zurückgesetzt, alle vorherigen Zuweisungen haben keine Wirkung. Individuelle Dienste können die CPU-Affinität für ihre Prozesse mit der Einstellung
CPUAffinity= in Unit-Dateien außer Kraft setzen, siehe
systemd.exec(5).
Hinzugefügt in Version 198.
NUMAPolicy=
Konfiguriert die NUMA-Speicherrichtlinie für den Diensteverwalter und die Vorgabe-NUMA-Speicherrichtlinie für alle mit Fork gestarteten Prozesse. Individuelle Dienste können die Vorgaberichtlinie mit der Einstellung
NUMAPolicy= in Unit-Dateien außer Kraft setzen, siehe
systemd.exec(5).
Hinzugefügt in Version 243.
NUMAMask=
Konfiguriert die NUMA-Knotenmaske, die der ausgewählten NUMA-Richtlinie zugeordnet wird. Beachten Sie, dass die NUMA-Richtlinien
default und
local keine expliziten NUMA-Knotenmasken benötigen und der Wert dieser Option leer sein kann. Ähnlich zu
NUMAPolicy= kann dieser Wert durch individuelle Dienste in Unit-Dateien außer Kraft gesetzt werden, siehe
systemd.exec(5).
Hinzugefügt in Version 243.
RuntimeWatchdogSec=, RebootWatchdogSec=, KExecWatchdogSec=
Konfiguriert den Hardware-Watchdog zur Laufzeit und beim Systemstart. Akzeptiert einen Zeitüberschreitungswert in Sekunden (oder anderen Zeiteinheiten, falls »ms«, »min«, »h«, »d«, »w« angehängt wird) oder die besondere Zeichenkette »off« oder »default«. Falls auf »off« gesetzt (alternativ »0«), wird die Watchdog-Logik deaktiviert: Es wird kein Watchdog-Gerät geöffnet, konfiguriert oder angesprochen. Falls auf die besondere Zeichenkette »default« gesetzt, wird der Watchdog geöffnet und in regelmäßigen Intervallen angesprochen, aber die Zeitüberschreitung wird nicht von der Vorgabe geändert. Falls auf einen anderen Zeitwert gesetzt, wird die Watchdog-Zeitüberschreitung auf den festgelegten Werte konfiguriert (oder einen Wert in der Nähe, abhängig von den Hardware-Fähigkeiten).
Falls RuntimeWatchdogSec= auf einen von Null verschiedenen Wert gesetzt wird, wird die Watchdog-Hardware (/dev/watchdog0 oder der mit WatchdogDevice= oder der mit der Kerneloption systemd.watchdog-device= festgelegte Pfad) programmiert, das System automatisch neu zu starten, falls sie nicht innerhalb des festgelegten Zeitüberschreitungsintervalls kontaktiert wird. Diese Funktionalität benötigt die Existenz eines Watchdog-Gerätes, wie dies bei eingebetteten und Server-Systemen häufig der Fall ist. Nicht alle Hardware-Watchdogs erlauben die Konfiguration aller möglichen Neustart-Zeitüberschreitungswerte – dann wird der naheste verfügbare Zeitüberschreitungswert ausgewählt.
RebootWatchdogSec= kann zur Konfiguration des Hardware-Watchdogs verwandt werden, wenn das System um einen Neustart gebeten wird. Es funtioniert als Sicherheitsnetz, um sicherzustellen, dass der Neustart sogar dann stattfindet, falls ein sauberer Neustartversuch wegen einer Zeitüberschreitung nicht stattfindet. Beachten Sie, dass die Zeitüberschreitung RebootWatchdogSec= nur für die zweite Phase des Systemneustarts angewandt wird, d.h. nachdem alle regulären Dienste bereits beendet wurden und nachdem der System- und Diensteverwalterprozess (PID 1) durch das System-Herunterfahrprogramm ersetzt wurde, siehe bootup(7) für Details. Während der ersten Phase der Herunterfahr-Aktion bleibt der System- und Diensteverwalter am Laufen und daher wird RuntimeWatchdogSec= weiterhin gewürdigt. Um eine Zeitüberschreitung in dieser ersten Phase des System-Herunterfahrens zu definieren, konfigurieren Sie JobTimeoutSec= und JobTimeoutAction= in dem Abschnitt »[Unit]« von shutdown.target unit. Standardmäßig beträgt RuntimeWatchdogSec= 0 (off) und RebootWatchdogSec= 10min.
KExecWatchdogSec= kann zur zusätzlichen Aktivierung des Watchdogs verwandt werden, wenn kexec statt eines Systemneustarts ausgeführt wird. Beachten Sie, dass in diesem Fall der Watchdog nicht nach dem kexec deaktiviert werden könnte, falls der Kernel den Watchdog beim kexec nicht zurücksetzt (abhängig von der spezifischen Hardware und/oder Treiber) und daher das System neu gestartet werden könnte, außer wenn RuntimeWatchdogSec= gleichzeitig auch aktiviert ist. Aus diesem Grund wird empfohlen, KExecWatchdogSec= nur zu aktivieren, falls RuntimeWatchdogSec= auch aktiviert ist.
Diese Einstellungen haben keine Auswirkungen, falls kein Hardware-Watchdog verfügbar ist.
Hinzugefügt in Version 198.
RuntimeWatchdogPreSec=
Konfiguriert den Hardware-Watchdog-Vorzeitüberschreitungswert. Akzeptiert einen Zeitüberschreitungswert in Sekunden (oder in anderen Zeiteinheiten, ähnlich wie
RuntimeWatchdogSec=). Eine Vorzeitüberschreitung ist eine durch den Watchdog erzeugte Benachrichtigung, bevor eine Watchdog-Zurücksetzung erfolgen könnte, falls der Watchdog nicht bedient wurde. Diese Benachrichtigung wird vom Kernel bedient und kann so mit
RuntimeWatchdogPreGovernor= konfiguriert werden, dass eine Aktion erfolgt (d.h. eine Kernel-Panik erzeugt wird). Nicht alle Watchdog-Hardware oder -Treiber unterstützen die Erstellung einer Vorzeitüberschreitung und abhängig vom Zustand des Systems könnte der Kernel nicht in der Lage sein, die konfigurierte Aktion vorzunehmen, bevor sich der Watchdog neu startet. Der Watchdog wird so konfiguriert, dass er die Vorzeitüberschreitung die in
RuntimeWatchdogPreSec= festgelegte Zeit vor der Laufzeitüberschreitung des Watchdogs erstellt (gesetzt über
RuntimeWatchdogSec=). Ist beispielsweise
RuntimeWatchdogSec=30 und
RuntimeWatchdogPreSec=10, dann wird das Vorzeitüberschreitungsereignis auftreten, falls 20 Sekunden lang kein Ping zum Watchdog erfolgte (10 Sekunden bevor der Watchdog auslösen würde). Standardmäßig ist 0 (ausgeschaltet) die Vorgabe für
RuntimeWatchdogPreSec=. Der für
RuntimeWatchdogPreSec= gesetzte Wert muss kleiner als der Zeitüberschreitungswert für
RuntimeWatchdogSec= sein. Diese Einstellung hat keine Auswirkung, falls kein Hardware-Watchdog verfügbar ist oder der Hardware-Watchdog keine Vorzeitüberschreitung unterstützt und wird vom Kernel ignoriert, falls die Einstellung größer als die tatsächliche Watchdog-Zeitüberschreitung ist.
Hinzugefügt in Version 251.
RuntimeWatchdogPreGovernor=
Konfiguriert die vom Hardware-Watchdog-Gerät vorzunehmende Aktion, wenn die Vorzeitüberschreitung abläuft. Die Vorgabeaktion für das Vorzeitüberschreitungsereignis hängt von der Kernelkonfiguration ab, aber normalerweise wird eine Kernelmeldung protokolliert. Lesen Sie den Inhalt der Datei /sys/class/watchdog/watchdog
X/pretimeout_available_governors für eine Liste gültiger, für ein Watchdog-Gerät verfügbarer Aktionen. Typischerweise sind die Regulierungstypen
noop und
panic verfügbar. Verfügbarkeit, Namen und Funktionalität könnten sich, abhängig vom konkret verwandten Gerätetreiber, unterscheiden. Falls die Sysfs-Datei pretimeout_available_governors leer ist, könnte der Regulierer als Kernelmodul gebaut worden sein und könnte manuell zu laden sein (z.B.
pretimeout_noop.ko) oder das Watchdog-Gerät könnte Vorzeitüberschreitung nicht unterstützen.
Hinzugefügt in Version 251.
WatchdogDevice=
Konfiguriert das Hardware-Watchdog-Gerät, das die Laufzeit- und Herunterfahr-Watchdog-Timer öffnen und benutzen wird. Standardmäßig /dev/watchdog0. Diese Einstellung hat keinen Effekt, falls kein Hardware-Watchdog verfügbar ist.
Hinzugefügt in Version 236.
CapabilityBoundingSet=
Steuert, welche Capabilities in der Capability-Begrenzungsmenge für PID 1 und seine Kindprozesse aufgenommen werden sollen. Siehe
capabilities(7) für Details. Akzeptiert eine durch Leerraumzeichen getrennte Liste von Capability-Namen, wie sie von
cap_from_name(3) eingelesen werden. Die aufgeführten Capabilities werden in die Begrenzungsmenge aufgenommen, alle anderen werden entfernt. Falls der Liste der Capabilities ein ~ vorangestellt wird, werden alle außer den aufgeführten Capabilities aufgenommen, der Effekt der Zuweisung ist invertiert. Beachten Sie, dass diese Option auch die respektiven Capabilities in der effektiven, erlaubten und vererbbaren Capability-Menge betrifft. Die Capability-Begrenzungsmenge kann auch für Units auch individuell mittels der Anweisung
CapabilityBoundingSet= für diese Unit konfiguriert werden. Beachten Sie aber, dass Capabilities, die für PID 1 ausgeschlossen wurden, nicht für individuelle Units wiedererlangt werden können, sie sind auf Dauer verloren.
Hinzugefügt in Version 198.
NoNewPrivileges=
Akzeptiert ein logisches Argument. Falls wahr, stellt sie sicher, dass PID 1 und alle seine Kinder niemals Privilegien durch
execve(2) erhalten können (d.h. mittels der Bits setuid oder setgid oder Dateisystem-Capabilities). Standardmäßig falsch. Allzweckdistributionen benötigen typischerweise Programme mit gesetzten Setuid- oder Setgid-Bits und werden daher nicht korrekt funktionieren, wenn diese Option aktiviert ist. Individuelle Units können diese Option nicht deaktivieren. Siehe auch
Schalter »Keine neuen Privilegien«[1].
Hinzugefügt in Version 239.
SystemCallArchitectures=
Akzeptiert eine durch Leerzeichen getrennte Liste von Architekturkennzeichnern. Wählt aus, von welchen Architekturen auf diesem System Systemaufrufe aufgerufen werden dürfen. Dies kann als effektive systemweite Art zur Deaktivierung von Aufrufen von nicht-nativen Programmen verwandt werden, um beispielsweise die Ausführung von 32-Bit-x86-Programmen auf 64-Bit-x86-64-Systemen zu verbieten. Diese Option agiert systemweit und arbeitet ähnlich der Einstellung
SystemCallArchitectures= von Unit-Dateien, siehe
systemd.exec(5) für Details. Diese Einstellung ist standardmäßig die leere Liste, d.h. dass in diesem Fall keine Filterung der Systemaufrufe basierend auf der Architektur angewandt wird. Bekannte Architekturkennzeichner sind »x86«, »x86-64«, »x32«, »arm« und der besondere Kennzeichner »native«. Letzterer wird implizit auf die native Architektur des Systems abgebildet (oder genauer, der Architektur, für die der Systemverwalter kompiliert wurde). Setzen Sie diese Einstellung auf »native«, um die Ausführung nicht nativer Programme zu verbieten. Wenn ein Programm einen Systemaufruf einer Architektur ausführt, die nicht in dieser Einstellung aufgeführt ist, wird sie sofort mit dem Signal SIGSYS beendet.
Hinzugefügt in Version 209.
TimerSlackNSec=
Setzt den Timer-Spielraum in Nanosekunden für PID 1, der von allen ausgeführten Prozessen geerbt wird, außer er wird individuell außer Kraft gesetzt, beispielsweise mit der Einstellung
TimerSlackNSec= in Dienste-Units (für Details siehe
systemd.exec(5)). Der Timer-Spielraum steuert die Genauigkeit der durch Systemd-Timer ausgelösten Aufwachaktionen. Siehe
prctl(2)EN für weitere Informationen. Beachten Sie, dass im Gegensatz zu den meisten anderen Zeitdauerdefinitionen dieser Parameter einen Ganzzahlwert in Nanosekunden akzeptiert, falls keine Einheit angegeben ist. Es werden auch die normalen Zeiteinheiten verstanden.
Hinzugefügt in Version 198.
StatusUnitFormat=
Akzeptiert
name,
description oder
combined als Wert. Falls
name, wird der Systemverwalter Unit-Namen (z.B. »systemd-journald.service«) statt der längeren und aussagefähigeren, mit
Description= gesetzten Beschreibungen (z.B. »Journal Logging Service«) in Statusmeldungen verwenden. Falls
combined, wird der Systemverwalter sowohl Unit-Namen als auch Beschreibungen in Stausmeldungen verwenden (z.B. »systemd-journald.service - Journal Logging Service«).
Siehe systemd.syntax(5) für Details über Unit-Namen und Description=.
Hinzugefügt in Version 243.
DefaultTimerAccuracySec=
Setzt die Standardgenauigkeit der Timer-Units. Dies steuert die globale Voreinstellung für die Einstellung
AccuracySec= von Timer-Units, siehe
systemd.timer(5) für Details.
AccuracySec=-Einstellungen in individuellen Units setzen die globale Vorgabe für die bestimmte Unit außer Kraft. Standardmäßig 1 Minute. Beachten Sie, dass die Genauigkeit der Timer-Units auch von dem Timer-Spielraum beeinflusst wird, siehe
TimerSlackNSec= oben.
Hinzugefügt in Version 212.
DefaultTimeoutStartSec=, DefaultTimeoutStopSec=, DefaultTimeoutAbortSec=, DefaultRestartSec=
Konfiguriert die Standardzeitüberschreitung zum Starten, Beenden und Abbrechen von Units sowie die Standardzeit, die zwischen automatischen Neustarts von Units geschlafen wird, wie dies pro Unit in
TimeoutStartSec=,
TimeoutStopSec=,
TimeoutAbortSec= und
RestartSec= konfiguriert ist (für Dienste, siehe
systemd.service(5) für Details über die Einstellungen pro Unit). Für Units, die keine Dienste sind, setzt
DefaultTimeoutStartSec= den Standardwert von
TimeoutSec=.
DefaultTimeoutStartSec= und DefaultTimeoutStopSec= sind standardmäßig 90 s im Systemverwalter und 90 s im Benutzerverwalter. DefaultTimeoutAbortSec= ist standardmäßig nicht gesetzt, so dass alle Units auf TimeoutStopSec= zurückfallen. DefaultRestartSec= ist standardmäßig 100 ms.
Hinzugefügt in Version 209.
DefaultDeviceTimeoutSec=
Konfiguriert die standardmäßige Zeitüberschreitung zum Warten auf Geräte. Sie kann gerätebezogen mittels der Option
x-systemd.device-timeout= in /etc/fstab und /etc/crypttab geändert werden (siehe
systemd.mount(5),
crypttab(5)). Standardmäßig 90 s im Systemverwalter und 90 s im Benutzerverwalter.
Hinzugefügt in Version 252.
DefaultStartLimitIntervalSec=, DefaultStartLimitBurst=
Konfiguriert die Standard-Startratenbegrenzung von Units, wie dies pro Dienst in
StartLimitIntervalSec= und
StartLimitBurst= konfiguriert ist. Siehe
systemd.service(5) für Details über die Einstellungen pro Dienst.
DefaultStartLimitIntervalSec= ist standardmäßig 10 s.
DefaultStartLimitBurst= ist standardmäßig 5.
Hinzugefügt in Version 209.
DefaultEnvironment=
Konfiguriert Umgebungsvariablen, die an alle ausgeführten Prozesse weitergegeben werden. Erhält eine Liste von durch Leerzeichen getrennten Variablenzuweisungen. Siehe
environ(7) für Details über Umgebungsvariablen.
Einfache »%«-Kennzeichner-Expansion wird unterstützt, siehe unten für eine Liste der unterstützten Kennzeichner.
Beispiel:
DefaultEnvironment="VAR1=Wort1 Wort2" VAR2=Wort3 "VAR3=Wort 5 6"
Setzt drei Variablen "VAR1", "VAR2", "VAR3".
Hinzugefügt in Version 205.
ManagerEnvironment=
Akzeptiert die gleichen Argumente wie
DefaultEnvironment=, siehe oben. Setzt Umgebungsvariablen nur für den Verwalterprozess selbst. Im Gegensatz zu Benutzerverwaltern werden diese Variablen nicht von Prozessen ererbt, die vom Systemverwalter erzeugt werden, verwenden Sie dafür
DefaultEnvironment=. Beachten Sie, dass diese Variablen mit dem bestehenden Umgebungsblock zusammengeführt werden. Insbesondere im Falle des Systemverwalters schließt dies Variablen ein, die vom Kernel — basierend auf der Kernelbefehlszeile — gesetzt werden.
Das Setzen von Umgebungsvariablen für den Verwalterprozess kann zu Veränderung dessen Verhaltens nützlich sein. Siehe Bekannte Umgebungsvariablen[2] für eine Beschreibung über einige der von systemd verstandenen Variablen.
Einfache »%«-Kennzeichner-Expansion wird unterstützt, siehe unten für eine Liste der unterstützten Kennzeichner.
Hinzugefügt in Version 248.
DefaultCPUAccounting=, DefaultMemoryAccounting=, DefaultTasksAccounting=, DefaultIOAccounting=, DefaultIPAccounting=
Konfiguriert die Vorgabe-Ressourcen-Buchhaltungseinstellungen, wie Unit-bezogen mittels
CPUAccounting=,
MemoryAccounting=,
TasksAccounting=,
IOAccounting= und
IPAccounting= konfiguriert. Siehe
systemd.resource-control(5) zu Details Unit-bezogener Einstellungen.
DefaultCPUAccounting= ist bei der Ausführung auf Kerneln ≥4.15 standardmäßig »yes« und »no« auf älteren Versionen. DefaultMemoryAccounting= ist standardmäßig »yes«. DefaultTasksAccounting= ist standardmäßig »yes«. Die anderen Einstellungen sind standardmäßig »no«.
Hinzugefügt in Version 211.
DefaultTasksMax=
Konfiguriert die Vorgabewerte der
TasksMax=-Einstellungen für jede Unit. Siehe
systemd.resource-control(5) für Details. Diese Einstellung wird auf alle Unit-Typen, die Ressourcensteuerungseinstellungen unterstützen, mit der Ausnahme von Scheiben-Units, angewandt. Standardmäßig 15% der minimalen
kernel.pid_max=,
kernel.threads-max= und der Wurzel-Cgroup
pids.max. Der Kernel hat einen Vorgabewert für
kernel.pid_max= und einen Zählalgorithmus, falls er mehr als 32 Kerne antrifft. Mit der standardmäßigen
kernel.pid_max= ist die Vorgabe für
DefaultTasksMax= 4915, aber sie kann auf anderen Systemen größer und in Betriebssystem-Containern kleiner sein.
Hinzugefügt in Version 228.
DefaultLimitCPU=, DefaultLimitFSIZE=, DefaultLimitDATA=, DefaultLimitSTACK=, DefaultLimitCORE=, DefaultLimitRSS=, DefaultLimitNOFILE=, DefaultLimitAS=, DefaultLimitNPROC=, DefaultLimitMEMLOCK=, DefaultLimitLOCKS=, DefaultLimitSIGPENDING=, DefaultLimitMSGQUEUE=, DefaultLimitNICE=, DefaultLimitRTPRIO=, DefaultLimitRTTIME=
Diese Einstellungen steuern verschiedene Vorgaberessourcenbeschränkungen für von Units ausgeführte Prozesse. Siehe
setrlimit(2)EN für Details. Diese Einstellungen können in individuellen Units mittels der entsprechenden
LimitXXX=-Direktiven außer Kraft gesetzt werden und sie akzeptieren die gleiche Parametersyntax, siehe
systemd.exec(5) für Details. Beachten Sie, dass diese Ressourcenbeschränkungen nur die Vorgaben für die Units sind, sie werden nicht auf den Diensteverwalterprozess (d.h. PID 1) selbst angewandt.
Die meisten dieser Einstellungen sind nicht gesetzt, was bedeutet, dass Ressourcenbegrenzungen von dem Kernel oder, falls innerhalb eines Containers, vom Container-Verwalter ererbt werden. Die Folgenden haben allerdings Standardwerte:
•DefaultLimitNOFILE= ist standardmäßig »1024:524288«.
•DefaultLimitMEMLOCK= ist standardmäßig 8M.
•DefaultLimitCORE= hat keine Vorgabe, aber es lohnt sich zu erwähnen, dass RLIMIT_CORE durch PID1 auf »infinity« gesetzt wird, was von seinen Kindprogrammen ererbt wird.
Beachten Sie, dass der Diensteverwalter intern in PID 1 RLIMIT_NOFILE und RLIMIT_MEMLOCK auf höhere Werte erhöht; die Beschränkung wird allerdings für alle per Fork erzeugten Kindprozesse auf die angegeben Vorgaben zurückgesetzt.
Hinzugefügt in Version 198.
DefaultOOMPolicy=
Konfiguriert die Standardrichtlinie für die Reaktion auf Prozesse, die durch den Speicherknappheits- (OOOM-)Killer von Linux oder
systemd-oomd getötet werden. Dies kann zur Auswahl einer globalen Vorgabe für die Unit-bezogene Einstellung
OOMPolicy= verwandt werden. Siehe
systemd.service(5) für Details. Beachten Sie, dass diese Vorgabe für Dienste, die
Delegate= eingeschaltet haben, nicht verwandt wird.
Hinzugefügt in Version 243.
DefaultOOMScoreAdjust=
Konfiguriert die Standard-OOM-Bewertungsanpassung für vom Diensteverwalter ausgeführte Prozesse. Standardmäßig nicht gesetzt (was bedeutet, dass mit Fork gestartete Prozesse die OOM-Bewertungsanpassung vom Diensteverwalter erben), außer falls der Diensteverwalter für einen nichtprivilegierten Benutzer ausgeführt wird, dann ist die Vorgabe die OOM-Bewertungsanpassung vom Diensteverwalter plus 100 (wodurch der Diensteprozess etwas wahrscheinlicher unter Speicherdruck beendet wird als der Verwalter selbst). Dies kann zum Auswählen einer globalen Vorgabe für die Unit-bezogene Einstellung
OOMScoreAdjust= verwandt werden. Siehe
systemd.exec(5) für Details. Beachten Sie, dass diese Einstellung keine Auswirkung auf den Standard-OOM-Bewertungsanpassungswert des Diensteverwalters selbst hat, er behält den ursprünglichen Wert, der während des Aufrufs gesetzt wurde.
Hinzugefügt in Version 250.
DefaultSmackProcessLabel=
Akzeptiert einen
SMACK64-Sicherheits-Label als Argument. Der durch eine Unit ausgeführte Prozess wird unter diesem Label gestartet, falls
SmackProcessLabel= nicht in der Unit gesetzt ist. Siehe
systemd.exec(5) für Details.
Falls der Wert »/« ist, werden nur mit SmackProcessLabel= festgelegte Label zugewiesen und die Vorgabe aus der Kompilierung wird ignoriert.
Hinzugefügt in Version 252.
ReloadLimitIntervalSec=, ReloadLimitBurst=
Ratenbegrenzung für Daemon-Neulade-Anforderungen. Standardmäßig nicht gesetzt und jede Anzahl an Daemon-Neuladeanforderungen kann zu jeder Zeit erbeten werden.
ReloadLimitIntervalSec= akzeptiert einen Wert in Sekunden, um das Ratenbegrenzungsfenster zu konfigurieren und
ReloadLimitBurst= akzeptiert eine positive Ganzzahl, um die maximal erlaubte Anzahl von Neuladungen innerhalb des konfigurierten Zeitfensters zu konfigurieren.
Hinzugefügt in Version 253.
DefaultMemoryPressureWatch=, DefaultMemoryPressureThresholdSec=
Konfiguriert die Standardeinstellungen für die Unit-bezogenen Einstellungen
MemoryPressureWatch= und
MemoryPressureThresholdSec=. Siehe
systemd.resource-control(5) zu Details. Standardmäßig »auto« bzw. »200ms«. Dies setzt auch den Schwellwert für die Überwachung des Speicherdrucks für den Diensteverwalter selbst.
Hinzugefügt in Version 254.