Provided by: manpages-de_4.21.0-2_all bug

BEZEICHNUNG

       systemd.resource-control - Resourcensteuerungs-Unit-Einstellungen

ÜBERSICHT

       Scheibe.slice, Bereich.scope, Dienst.service, Socket.socket, Einhängung.mount, Swap.swap

BESCHREIBUNG

       Unit-Konfigurationsdateien für Dienste, Scheiben, Bereiche, Sockets, Einhängepunkte und
       Swap-Geräte nutzen eine Teilmenge der Konfigurationsoptionen für die Ressourcensteuerung
       von erzeugten Prozessen gemeinsam. Intern verlässt sich dies auf das Konzept der Linux
       Control Groups (cgroups) des Kernels zur Organisation von Prozessen in einem
       hierarchischen Baum benannter Gruppen zum Zwecke der Ressourcensteuerung.

       Diese Handbuchseite listet die von diesen sechs Unit-Typen gemeinsam benutzten Optionen
       auf. Siehe systemd.unit(5) für die gemeinsamen Optionen aller Unit-Konfigurationsdateien
       und systemd.slice(5), systemd.scope(5), systemd.service(5), systemd.socket(5),
       systemd.mount(5) und systemd.swap(5) für weitere Informationen über die speziellen
       Unit-Konfigurationsdateien. Die Ressourcensteuerungskonfigurationsoptionen werden in den
       Abschnitten [Slice], [Scope], [Service], [Socket], [Mount] oder [Swap], abhängig vom
       Unit-Typ, konfiguriert.

       Zusätzlich werden Optionen, die die verfügbaren Ressourcen der von Systemd gestarteten
       Programme steuern, in systemd.exec(5) aufgeführt. Diese Optionen ergänzen die hier
       aufgeführten Optionen.

   Controller aktivieren oder deaktivieren
       Controller in der Cgroup-Hierarchie sind hierarchisch und die Ressourcensteuerung wird
       über verteilte Ressourcenzuweisungen zwischen Geschwistern in Zweigen der
       Cgroup-Hierarchie realisiert. Es besteht keine Notwendigkeit, einen Cgroup-Controller für
       eine Unit explizit zu aktivieren. systemd wird den Kernel anweisen, einen Controller für
       eine angegebene Unit zu aktivieren, wenn diese Unit über eine Konfiguration für einen
       angegebenen Controller verfügt. Wenn beispielsweise CPUWeight= gesetzt ist, wird der
       Controller cpu aktiviert und wenn TasksMax= gesetzt ist, wird der Controller pids
       aktiviert. Zusätzlich können verschiedene Controller auch über explizite Einstellungen
       MemoryAccounting=/TasksAccounting=/IOAccounting= aktiviert werden. Aufgrund der
       Arbeitsweise der Cgroup-Hierarchie werden Controller für alle Eltern-Units und für alle
       Geschwister-Units, beginnend bei der niedrigsten Stufe, auf der der Controller aktiviert
       ist, aktiviert werden. Units, für die ein Controller aktiviert ist, können der
       Ressourcensteuerung unterliegen, selbst falls sie selbst über keine explizite
       Konfiguration verfügen.

       Setzen von Delegate= aktiviert alle delegierten Controller für diese Unit (siehe unten).
       Die Delegierten können dann nach Bedarf Controller für ihre Kinder aktivieren. Falls
       insbesondere der Delegierte systemd ist (in der Unit user@.service), wird er die gleiche
       Logik wie die Systeminstanz wiederholen und Controller für Units aktivieren, bei denen
       Ressourcenbeschränkungen konfiguriert wurden, sowie deren Geschwistern und Eltern und den
       Geschwistern der Eltern.

       Controller können für Teile der Cgroup-Hierarchie mit DisableControllers= deaktiviert
       werden (siehe unten).

       Beispiel 1. Controller aktivieren und deaktivieren

                                 -.slice
                                /       \
                         /-----/         \--------------\
                        /                                \
                 system.slice                       user.slice
                   /       \                          /      \
                  /         \                        /        \
                 /           \              user@42.service  user@1000.service
                /             \             Delegate=        Delegate=yes
           a.service       b.slice                             /        \
           CPUWeight=20   DisableControllers=cpu              /          \
                            /  \                      app.slice      session.slice
                           /    \                     CPUWeight=100  CPUWeight=100
                          /      \
                  b1.service   b2.service
                               CPUWeight=1000

       In dieser Hierarchie ist der Controller cpu für alle angezeigten Units außer b1.service
       und b2.service aktiviert. Da es keine explizite Konfiguration für system.slice und
       user.slice gibt, werden die CPU-Ressourcen zwischen ihnen gleichmäßig aufgeteilt. Ähnlich
       werden Ressourcen zwischen den Kindern von user.slice und zwischen der Kind-Scheibe
       unterhalb von user@1000.service aufgeteilt. Unter der Annahme, dass es keine weitere
       Konfiguration der Ressourcen oder Delegationen unterhalb der Scheibe app.slice oder
       session.slice gibt, würde der Controller cpu nicht für Units in diesen Scheiben aktiviert
       und CPU-Ressourcen würden weiter mittels anderer Mechanismen, z.B. basierend auf den
       Nice-Stufen, zugewiesen. Der Verwalter für Benutzer 42 hat Delegation ohne Controller
       aktiviert, d.h. er kann seinen Unterbaum der Cgroup-Hierarchie verändern, aber ohne
       Ressourcensteuerung.

       In der Scheibe system.slice werden die CPU-Ressourcen 1:6 auf Dienst a.service und 5:6 auf
       Scheibe b.slice aufgeteilt, da Scheibe b.slice den Vorgabewert von 100 für cpu.weight
       erhält, wenn CPUWeight= nicht gesetzt ist.

       Die Einstellung CPUWeight= in b2.service wird durch DisableControllers= in Scheibe b.slice
       neutralisiert, so dass der Controller cpu für die Dienste b1.service und b2.service nicht
       aktiviert würde und CPU-Ressourcen weiter mittels anderer Mechanismen, z.B. basierend auf
       den Nice-Stufen, zugewiesen würden.

   Ressourcensteuerungen für eine Cgroup zugehöriger Units setzen
       Wie in systemd.unit(5) beschrieben, können die hier aufgeführten Einstellungen über die
       Hauptkonfigurationsdatei einer Unit und Ergänzungsschnipsel in *.d/-Verzeichnissen gesetzt
       werden. Die Liste der nach Ergänzungen durchsuchten Verzeichnisse enthält Namen, die durch
       wiederholtes Abschneiden des Units-Namens nach allen Gedankenstrichen geformt werden. Dies
       ist insbesondere praktisch, um Ressourcenbegrenzungen für eine Gruppe von Units mit
       ähnlichen Namen zu setzen.

       Beispielsweise erhält jeder Benutzer seine eigene Scheibe user-nnn.slice. Ergänzungen mit
       lokaler Konfiguration, die Benutzer 1000 betreffen, können in
       /etc/systemd/system/user-1000.slice, /etc/systemd/system/user-1000.slice.d/*.conf, aber
       auch in /etc/systemd/system/user-.slice.d/*.conf abgelegt werden. Das letzte Verzeichnis
       gilt für alle Benutzer-Scheiben.

       Siehe die Neue Control-Gruppen-Schnittstellen[1] für eine Einführung, wie die
       Ressourcensteuerungs-APIs von Programmen genutzt werden können.

IMPLIZITE ABHÄNGIGKEITEN

       Die folgenden Abhängigkeiten werden implizit hinzugefügt:

       •   Units mit der gesetzten Einstellung Slice= erlangen automatisch Requires=- und
           After=-Abhängigkeiten auf die festgelegte Scheiben-Unit.

OPTIONEN

       Units der oben aufgeführten Typen können Einstellungen für die
       Ressourcensteuerungskonfiguration haben:

   CPU-Buchführung und -Steuerung
       CPUAccounting=
           Schaltet die Buchführung für die CPU-Benutzung für diese Unit ein. Akzeptiert ein
           logisches Argument. Beachten Sie, dass das Einschalten der CPU-Buchführung in einer
           Unit implizit die Buchführung für alle Units in der gleichen Scheibe und für alle ihre
           Eltern-Scheiben und die darin enthaltenen Units einschaltet. Die Systemvorgabe für
           diese Einstellung kann mit DefaultCPUAccounting= in systemd-system.conf(5) gesteuert
           werden.

           Unter der vereinigten Cgroup-Hierarchie ist die CPU-Buchführung für alle Units
           verfügbar und diese Einstellung hat keine Auswirkung.

           Hinzugefügt in Version 208.

       CPUWeight=Gewicht, StartupCPUWeight=Gewicht
           Diese Einstellungen steuern den Controller cpu in der vereinigten Hierarchie.

           Diese Optionen akzeptieren einen Ganzzahlwert oder die besondere Zeichenkette »idle«:

           •   Weist, falls auf einen Ganzzahlwert gesetzt, die festgelegte CPU-Zeitgewichtung
               den ausgeführten Prozessen zu, falls die vereinigte Control-Gruppenhierarchie auf
               dem System verwandt wird. Diese Optionen steuern das Control-Group-Attribut
               »cpu.weight«. Der erlaubte Bereich ist 1 bis 10000. Standardmäßig nicht gesetzt,
               aber die Vorgabe des Kernels ist 100. Für Details über dieses
               Control-Gruppen-Attribut siehe Control-Gruppen v2[2] und CFS-Auftragsplaner[3].
               Die verfügbare CPU-Zeit wird zwischen allen Units innerhalb einer Scheibe relativ
               zu ihrer CPU-Zeitgewichtung aufgeteilt. Ein höheres Gewicht bedeutet mehr
               CPU-Zeit, ein geringeres Gewicht weniger.

           •   Falls sie auf die besondere Zeichenkette »idle« gesetzt wird, dann wird die Cgroup
               für »idle scheduling« (Leerlauf-Auftragsplanung) markiert. Das bedeutet, dass sie
               nur CPU-Ressourcen bekommt, wenn es keine Prozesse gibt, die nicht so markiert
               sind, die in dieser Cgroup oder seinen Geschwistern ausgeführt werden. Diese
               Einstellung entspricht dem Cgroup-Attribut »cpu.idle«.

               Beachten Sie, dass dieser Wert nur bei Cgroup-V2 eine Auswirkung hat, bei
               Cgroup-V1 ist sie äquivalent zu der Minimalgewichtung.

           Während StartupCPUWeight= für die Hoch- und Runterfahrphase des Systems gilt, gilt
           CPUWeight= während der normalen Laufzeit des Systems und falls ersteres nicht gesetzt
           ist, auch für die Hoch- und Runterfahrphasen. Durch Verwendung von StartupCPUWeight=
           ist eine abweichende Priorisierung bestimmter Dienste während des Hoch- und
           Runterfahrens des Systems im Vergleich zur normalen Laufzeit möglich.

           Zusätzlich zu der durch den Controller cpu durchgeführten Ressourcenbelegung kann der
           Kernel automatisch Ressourcen basierend auf der Sitzungskennungsgruppierung verteilen,
           siehe »The autogroup feature« in sched(7). Die Auswirkung dieser Funktionalität ist
           ähnlich des Controllers cpu ohne explizite Konfiguration, daher sollten Benutzer
           vorsichtig sein, nicht beide durcheinander zu bringen.

           Hinzugefügt in Version 232.

       CPUQuota=
           Diese Einstellung steuert den Controller cpu in der vereinigten Hierarchie.

           Weist die festgelegte CPU-Zeitquote den ausgeführten Prozessen zu. Akzeptiert einen
           Prozentwert, dem »%« angehängt ist. Der Prozentwert gibt an, wieviel CPU-Zeit die Unit
           maximal erhalten soll, relativ zu der gesamten CPU-Zeit, die auf einer CPU verfügbar
           ist. Verwenden Sie Werte > 100%, um CPU-Zeit auf mehr als einer CPU vorzusehen. Dies
           steuert das Attribut »cpu.max« der vereinigten Control-Gruppenhierarchie und »cpu.max«
           auf der alten. Für Details über dieses Control-Gruppen-Attribut siehe Control-Gruppen
           v2[2] und CFS-Bandweitensteuerung[4]. Durch Setzen von CPUQuota= auf einen leeren Wert
           wird keine Quote gesetzt.

           Beispiel: CPUQuota=20% stellt sicher, dass der ausgeführte Prozess niemals mehr als
           20% CPU-Zeit auf einer CPU erhält.

           Hinzugefügt in Version 213.

       CPUQuotaPeriodSec=
           Diese Einstellung steuert den Controller cpu in der vereinigten Hierarchie.

           Weist die Dauer zu, über den die durch CPUQuota= festgelegte CPU-Zeit-Kontingent
           gemessen wird. Akzeptiert einen Zeitdauerwert in Sekunden mit einer optionalen Endung
           wie »ms« für Millisekunden (oder »s« für Sekunden). Die Voreinstellung ist 100 ms. Die
           Periode wird an den durch den Kernel unterstützten Bereich, der [1ms, 1000ms] ist,
           befestigt. Zusätzlich wird die Periode angepasst, so dass das Kontingent-Intervall
           auch mindestens 1 ms ist. Wird CPUQuotaPeriodSec= auf einen leeren Wert gesetzt, so
           wird er auf die Vorgabe zurückgesetzt.

           Dies steuert das zweite Feld des Attributs »cpu.max« der vereinigten
           Control-Gruppenhierarchie und »cpu.cfs_period_us« auf der alten. Für Details über
           dieses Control-Gruppen-Attribut siehe Control-Gruppen v2[2] und CFS-Auftragsplaner[3].

           Beispiel: Mit CPUQuotaPeriodSec=10ms wird erbeten, das CPU-Kontingent in Perioden von
           10 ms zu messen.

           Hinzugefügt in Version 242.

       AllowedCPUs=, StartupAllowedCPUs=
           Diese Einstellung steuert den Controller cpuset in der vereinigten Hierarchie.

           Beschränkt die Ausführung von Prozessen auf bestimmte CPUs. Akzeptiert eine Liste von
           CPU-Indicies oder -Bereichen, getrennt durch Leerraum oder Kommata. CPU-Bereiche
           werden durch den unteren und oberen CPU-Index, getrennt durch einen Bindestrich,
           angegeben.

           Setzen von AllowedCPUs= oder StartupAllowedCPUs= garantiert nicht, dass sämtliche CPUs
           von den Prozessen verwandt werden, da es durch Eltern-Units eingeschränkt sein könnte.
           Die wirksame Konfiguration wird durch EffectiveCPUs= berichtet.

           Während StartupAllowedCPU= nur für die Hoch- und Runterfahrphasen des Systems gelten,
           gilt AllowedCPUs= während der normalen Laufzeit des Systems und falls ersteres nicht
           gesetzt ist, auch für die Hoch- und Runterfahrphasen. Durch Verwendung von
           StartupAllowedCPUs= ist eine abweichende Priorisierung bestimmter Dienste während des
           Hoch- und Runterfahrens des Systems im Vergleich zur normalen Laufzeit möglich.

           Diese Einstellung wird nur mit der vereinigten Control-Gruppenhierarchie unterstützt.

           Hinzugefügt in Version 244.

   Speicher-Buchführung und -Steuerung
       MemoryAccounting=
           Diese Einstellung steuert den Controller memory in der vereinigten Hierarchie.

           Schaltet Prozess- und Kernelspeicherbuchführung für diese Unit ein. Akzeptiert ein
           logisches Argument. Beachten Sie, dass das Einschalten der Speicherbuchführung in
           einer Unit implizit die Buchführung für alle Units in der gleichen Scheibe und für
           alle ihre Eltern-Scheiben und die darin enthaltenen Units einschaltet. Die
           Systemvorgabe für diese Einstellung kann mit DefaultMemoryAccounting= in
           systemd-system.conf(5) gesteuert werden.

           Hinzugefügt in Version 208.

       MemoryMin=Byte, MemoryLow=Byte, StartupMemoryLow=Byte, DefaultStartupMemoryLow=Byte
           Diese Einstellungen steuern den Controller memory in der vereinigten Hierarchie.

           Legt den Speicherverwendungsschutz für die ausgeführten Prozesse in dieser Unit fest.
           Wenn Speicher zurückgewonnen wird, dann wird diese Unit so behandelt, als ob sie
           weniger Speicher verwenden würde, was dazu führt, dass Speicher bevorzugt von nicht
           geschützten Units zurückgewonnen wird. Die Verwendung von MemoryLow= führt zu einem
           schwächeren Schutz, bei dem Speicher weiterhin zurückgewonnen werden kann, um den
           Aufruf des OOM-Killers zu vermeiden, falls es keinen anderen zurückgewinnbaren
           Speicher gibt.

           Damit ein Schutz wirksam wird, ist es im Allgemeinen notwendig, die entsprechende
           Zuweisung für alle Vorfahren zu setzen, die dann zwischen den Kindern verteilt wird
           (mit der Ausnahme der Wurzel-Scheibe). Jede Zuweisung MemoryMin= oder MemoryLow=, die
           nicht explizit zu den festgelegten Kindern verteilt wird, wird für einen gemeinsamen
           Schutz für alle Kinder verwandt. Da dies ein gemeinsamer Schutz ist, konkurrieren die
           Kinder frei um den Speicher.

           Akzeptiert eine Speichergröße in Byte. Falls dem Wert K, M, G oder T angehängt wird,
           wird die angegebene Speichergröße in Kilobyte, Megabyte, Gigabyte bzw. Terabyte (zur
           Basis 1024) ausgewertet. Alternativ kann ein Prozentwert festgelegt werden, der
           relativ zum installierten physischen Speicher im System ist. Falls der besondere Wert
           »infinity« zugewiesen wird, wird sämtlicher Speicher geschützt. Dies kann nützlich
           sein, um immer sämtlichen, bei den Vorgängern aufgewandten Schutz zu erben. Dies
           steuert das Control-Gruppen-Attribut »memory.min« oder »memory.low«. Für Details über
           dieses Control-Gruppen-Attribut, siehe Speicherschnittstellen-Dateien[5].

           Durch Angabe von DefaultMemoryMin= oder DefaultMemoryLow= (hat die gleiche Semantik
           wie MemoryMin= und MemoryLow=) oder DefaultStartupMemoryLow= (hat die gleiche Semantik
           wie StartupMemoryLow=) können Units ihren Kindern einen Vorgabewert für »memory..min«
           oder »memory.low« verwenden lassen. Diese Einstellung beeinflusst nicht »memory..min«
           oder »memory.low« in der Unit selbst. Die Verwendung zum Setzen einer
           Vorgabe-Zuweisung ist nur auf Kerneln vor 5.7 nützlich, die die Cgroup2-Einhängeoption
           »memory_recursiveprot« nicht unterstützen.

           Während StartupMemoryLow= für die Hoch- und Runterfahrphasen des Systems gilt, gilt
           MemoryMin= während der normalen Laufzeit des Systems und falls ersteres nicht gesetzt
           ist, auch für die Hoch- und Runterfahrphasen. Durch Verwendung von StartupMemoryLow=
           ist eine abweichende Priorisierung bestimmter Dienste während des Hoch- und
           Runterfahrens des Systems im Vergleich zur normalen Laufzeit möglich.

           Hinzugefügt in Version 240.

       MemoryHigh=Byte, StartupMemoryHigh=Byte
           Diese Einstellungen steuern den Controller memory in der vereinigten Hierarchie.

           Legt die Drosselungs-Speicherverbrauchsbegrenzung der ausgeführten Prozesse in dieser
           Unit fest. Speicherverbrauch darf diese Begrenzung überschreiten, falls es
           unvermeidbar ist, aber die Prozesse werden drastisch verlangsamt und der Speicher wird
           in solchen Fällen aggressiv fortgenommen. Dies ist der Hauptmechanismus, um den
           Speicherverbrauch einer Unit zu steuern.

           Akzeptiert eine Speichergröße in Byte. Falls dem Wert K, M, G oder T angehängt wird,
           wird die angegebene Speichergröße in Kilobyte, Megabyte, Gigabyte bzw. Terabyte (zur
           Basis 1024) ausgewertet. Alternativ kann ein Prozentwert festgelegt werden, der
           relativ zum installierten physischen Speicher im System ist. Falls der besondere Wert
           »infinity« zugewiesen wird, wird keine Speicherdrosselung angewandt. Dies steuert das
           Control-Gruppen-Attribut »memory.high«. Für Details über dieses
           Control-Gruppen-Attribut, siehe Speicherschnittstellen-Dateien[5].

           Während StartupMemoryHigh= für die Hoch- und Runterfahrphase des Systems gilt, gilt
           MemoryHigh= während der normalen Laufzeit des Systems und falls ersteres nicht gesetzt
           ist, auch für die Hoch- und Runterfahrphasen. Durch Verwendung von StartupMemoryHigh=
           ist eine abweichende Priorisierung bestimmter Dienste während des Hoch- und
           Runterfahrens des Systems im Vergleich zur normalen Laufzeit möglich.

           Hinzugefügt in Version 231.

       MemoryMax=Byte, StartupMemoryMax=Byte
           Diese Einstellungen steuern den Controller memory in der vereinigten Hierarchie.

           Legt die absolute Grenze der Speicherverwendung durch den ausgeführten Prozess in
           dieser Unit fest. Falls der Speicherverbrauch nicht unterhalb dieser Grenze gehalten
           werden kann, wird der Speicherknappheits-Killer innerhalb der Unit aufgerufen. Es wird
           empfohlen, MemoryHigh= als Hauptsteuermechanismus und MemoryMax= als letzte
           Verteidigungslinie zu verwenden.

           Akzeptiert eine Speichergröße in Byte. Falls dem Wert K, M, G oder T angehängt wird,
           wird die angegebene Speichergröße in Kilobyte, Megabyte, Gigabyte bzw. Terabyte (zur
           Basis 1024) ausgewertet. Alternativ kann ein Prozentwert festgelegt werden, der
           relativ zum installierten physischen Speicher im System ist. Falls der besondere Wert
           »infinity« zugewiesen wird, wird keine Speicherbegrenzung angewandt. Dies steuert das
           Control-Gruppen-Attribut »memory.max«. Für Details über dieses
           Control-Gruppen-Attribut, siehe Speicherschnittstellen-Dateien[5].

           Während StartupMemoryMax= für die Hoch- und Runterfahrphasen des Systems gilt, gilt
           MemoryMax= während der normalen Laufzeit des Systems und falls ersteres nicht gesetzt
           ist, auch für die Hoch- und Runterfahrphasen. Durch Verwendung von StartupMemoryMax=
           ist eine abweichende Priorisierung bestimmter Dienste während des Hoch- und
           Runterfahrens des Systems im Vergleich zur normalen Laufzeit möglich.

           Hinzugefügt in Version 231.

       MemorySwapMax=Byte, StartupMemorySwapMax=Byte
           Diese Einstellungen steuern den Controller memory in der vereinigten Hierarchie.

           Legt die absolute Begrenzung bezüglich Auslagerungsverwendung von in dieser Unit
           ausgeführten Prozessen fest.

           Akzeptiert eine Auslagerungsgröße in Byte. Falls dem Wert K, M, G oder T angehängt
           wird, wird die angegebene Speichergröße in Kilobyte, Megabyte, Gigabyte bzw. Terabyte
           (zur Basis 1024) ausgewertet. Falls der besondere Wert »infinity« zugewiesen wird,
           wird keine Auslagerungsbegrenzung angewandt. Diese Einstellungen steuern das
           Control-Gruppen-Attribut »memory.swap.max«. Für Details über dieses
           Control-Gruppen-Attribut, siehe Speicherschnittstellen-Dateien[5].

           Während StartupMemorySwapMax= für die Hoch- und Runterfahrphasen des Systems gilt,
           gilt MemorySwapMax= während der normalen Laufzeit des Systems und falls ersteres nicht
           gesetzt ist, auch für die Hoch- und Runterfahrphasen. Durch Verwendung von
           StartupMemorySwapMax= ist eine abweichende Priorisierung bestimmter Dienste während
           des Hoch- und Runterfahrens des Systems im Vergleich zur normalen Laufzeit möglich.

           Hinzugefügt in Version 232.

       MemoryZSwapMax=Byte, StartupMemoryZSwapMax=Byte
           Diese Einstellungen steuern den Controller memory in der vereinigten Hierarchie.

           Legt die absolute Begrenzung der Verwendung von Zswap der Prozesse in dieser Unit
           fest. Zswap ist ein leichtgewichtiger Zwischenspeicher für Auslagerungsseiten. Es
           akzeptiert Seiten, die gerade ausgelagert werden sollen und versucht sie in einen
           dynamisch reservierten RAM-basierten Speicherbereich zu komprimieren. Falls die
           festgelegte Begrenzung erreicht wird, werden keine Einträge von dieser Unit mehr in
           dem Bereich gespeichert, bis bestehende Einträge wieder eingelesen oder auf Platte
           geschrieben werden. Siehe die Kerneldokumentation für Zswap[6] für weitere Details.

           Akzeptiert eine Größe in Byte. Falls dem Wert K, M, G oder T angehängt wird, wird die
           angegebene Größe in Kilobyte, Megabyte, Gigabyte bzw. Terabyte (zur Basis 1024)
           ausgewertet. Falls der besondere Wert »infinity« zugewiesen wird, wird keine
           Begrenzung angewandt. Diese Einstellungen steuern das Control-Gruppen-Attribut
           »memory.zswap.max«. Für Details über dieses Control-Gruppen-Attribut siehe
           Speicherschnittstellen-Dateien[5].

           Während StartupMemoryZSwapMax= für die Hoch- und Runterfahrphasen des Systems gilt,
           gilt MemoryZSwapMax= während der normalen Laufzeit des Systems und falls ersteres
           nicht gesetzt ist, auch für die Hoch- und Runterfahrphasen. Durch Verwendung von
           StartupMemoryZSwapMax= ist eine abweichende Priorisierung bestimmter Dienste während
           des Hoch- und Runterfahrens des Systems im Vergleich zur normalen Laufzeit möglich.

           Hinzugefügt in Version 253.

       AllowedMemoryNodes=, StartupAllowedMemoryNodes=
           Diese Einstellungen steuern den Controller cpuset in der vereinigten Hierarchie.

           Beschränkt die Ausführung von Prozessen auf bestimmte Speicher-NUMA-Knoten. Akzeptiert
           eine Liste von Speicher-NUMA-Knoten oder -Bereichen, getrennt durch Leerraum oder
           Kommata. Speicher-NUMA-Knotenbereiche werden durch den unteren und oberen
           NUMA-Knotenindex, getrennt durch einen Bindestrich, angegeben.

           Setzen von AllowedMemoryNodes oder StartupAllowedMemoryNodes= garantiert nicht, dass
           sämtliche Speicher-NUMA-Knoten von den Prozessen verwandt werden, da es durch
           Eltern-Units eingeschränkt sein könnte. Die wirksame Konfiguration wird durch
           EffectiveMemoryNodes= berichtet.

           Während StartupAllowedMemoryNodes= für die Hoch- und Runterfahrphasen des Systems
           gilt, gilt AllowedMemoryNodes= während der normalen Laufzeit des Systems und falls
           ersteres nicht gesetzt ist, auch für die Hoch- und Runterfahrphasen. Durch Verwendung
           von StartupAllowedMemoryNodes= ist eine abweichende Priorisierung bestimmter Dienste
           während des Hoch- und Runterfahrens des Systems im Vergleich zur normalen Laufzeit
           möglich.

           Diese Einstellung wird nur mit der vereinigten Control-Gruppenhierarchie unterstützt.

           Hinzugefügt in Version 244.

   Prozess-Buchführung und -Steuerung
       TasksAccounting=
           Diese Einstellung steuert den Controller pids in der vereinigten Hierarchie.

           Schaltet Prozessbuchführung für diese Unit ein. Akzeptiert ein logisches Argument.
           Falls aktiviert, wird der Kernel die Gesamtanzahl der Prozesse in der Unit und ihren
           Kindern nachverfolgen. Diese Anzahl enthält sowohl Kernel-Threads als auch
           Benutzerprozesse, wobei jeder Thread einzeln zählt. Beachten Sie, dass das Einschalten
           der Prozessbuchführung für eine Unit dies implizit auch für alle Units, die in der
           gleichen Scheibe enthalten sind und für alle Elternscheiben und die darin befindlichen
           Units einschaltet. Die Systemvorgabe für diese Einstellung kann durch
           DefaultTasksAccounting= in systemd-system.conf(5) gesteuert werden.

           Hinzugefügt in Version 227.

       TasksMax=N
           Diese Einstellung steuert den Controller pids in der vereinigten Hierarchie.

           Legt die maximale Anzahl an Prozessen, die in dieser Unit erstellt werden dürfen,
           fest. Dies stellt sicher, dass die Anzahl der Prozesse, für die die Unit buchführt
           (siehe oben), unterhalb einer festgelegten Begrenzung bleibt. Dies akzeptiert entweder
           eine absolute Anzahl an Prozessen oder einen Prozentwert, der relativ zu der
           konfigurierten Maximalzahl an Prozessen im System ist. Falls der besondere Wert
           »infinity« zugewiesen wird, wird keine Prozessbegrenzung angewandt. Dies steuert das
           Control-Gruppen-Attribut »pids.max«. Für Details über dieses Control-Gruppen-Attribut
           siehe PIDs-Controller[7].

           Die Systemvorgabe für diese Einstellung kann mit DefaultTasksMax= in
           systemd-system.conf(5) gesteuert werden.

           Hinzugefügt in Version 227.

   E/A-Buchführung und -Steuerung
       IOAccounting=
           Diese Einstellung steuert den Controller io in der vereinigten Hierarchie.

           Schaltet Block-E/A-Buchführung für diese Unit ein, falls die vereinigte
           Control-Gruppenhierarchie auf dem System verwandt wird. Akzeptiert ein logisches
           Argument. Beachten Sie, dass das Einschalten der Block-E/A-Buchführung für eine Unit
           dies implizit auch für alle Units, die in der gleichen Scheibe enthalten sind und für
           alle Elternscheiben und die darin befindlichen Units einschaltet. Die Systemvorgabe
           für diese Einstellung kann durch DefaultIOAccounting= in systemd-system.conf(5)
           gesteuert werden.

           Hinzugefügt in Version 230.

       IOWeight=Gewicht, StartupIOWeight=Gewicht
           Diese Einstellungen steueren den Controller io in der vereinigten Hierarchie.

           Setzt die vorgegebene Gesamt-Block-E/A-Gewichtung für die ausgeführten Prozesse, falls
           die vereinigte Control-Gruppenhierarchie auf dem System verwandt wird. Akzeptiert
           einen einzelnen Gewichtungswert (zwischen 1 und 10000), um die vorgegebene
           Block-E/A-Gewichtung zu setzen. Dies steuert das Control-Gruppen-Attribut »io.weight«,
           das standardmäßig 100 beträgt. Für Details über dieses Control-Gruppen-Attribut, siehe
           E/A-Schnittstellen-Dateien[8]. Die verfügbare E/A-Bandbreite wird zwischen allen Units
           innerhalb einer Scheibe relativ zu ihrer Block-E/A-Gewichtung aufgeteilt. Ein höherer
           Wert bedeutet mehr E/A-Bandbreite, ein geringerer Wert weniger.

           Während StartupIOWeight= in der Hoch- und Runterfahrphase des Systems angewandt wird,
           wird IOWeight= später zur Laufzeit des Systems angewandt und falls erstere nicht
           gesetzt ist, auch während der Hoch- und Runterfahrphasen. Dies erlaubt es, bestimmte
           Dienste beim Hoch- und Runterfahren anders als zur Laufzeit zu priorisieren.

           Hinzugefügt in Version 230.

       IODeviceWeight=Gerät Gewicht
           Diese Einstellung steuert den Controller io in der vereinigten Hierarchie.

           Setzt die gerätebezogene Gesamt-Block-E/A-Gewichtung für den ausgeführten Prozess,
           falls die vereinigte Control-Gruppenhierarchie auf dem System verwandt wird.
           Akzeptiert ein Leerzeichen-getrenntes Paar eines Dateipfades und eines
           Gewichtungswertes, um den gerätespezifischen Gewichtungswert zwischen 1 und 10000
           festzulegen. (Beispiel: "/dev/sda 1000"). Der Dateipfad kann als Pfad zu einem
           Blockgeräteknoten oder zu einer anderen Datei angegeben werden. In letzterem Fall wird
           das zugrundeliegende Blockgerät des Dateisystems der Datei bestimmt. Dies steuert das
           Control-Gruppen-Attribut »io.weight«, das standardmäßig 100 ist. Verwenden Sie diese
           Option mehrfach, um Gewichtungen für mehrere Geräte zu setzen. Für Details über dieses
           Control-Gruppen-Attribut siehe E/A-Schnittstellen-Dateien[8].

           Der festgelegte Geräteknoten sollte ein Blockgerät referenzieren, der einen
           E/A-Scheduler zugeordnet hat, d.h. er sollte sich nicht auf eine Partition oder
           Loopback-Blockgeräte beziehen, sondern auf das ursprüngliche, physische Gerät. Wenn
           ein Pfad zu einer regulären Datei oder einem regulären Verzeichnis angegeben wird,
           wird versucht, das korrekte ursprüngliche, zugrundeliegende Geräte für den
           festgelegten Pfad zu entdecken. Dies funktioniert nur für die einfacheren Fälle
           korrekt, bei denen das Dateisystem direkt auf einer Partition oder einem physischen
           Blockgerät angelegt ist, oder bei denen einfache 1:1-Verschlüsselung mittels
           dm-crypt/LUKS verwandt wird. Diese Erkennung deckt komplexe Speicher und insbesondere
           RAID und Datenträger-Verwaltungs-Speichergeräte nicht ab.

           Hinzugefügt in Version 230.

       IOReadBandwidthMax=Gerät Byte, IOWriteBandwidthMax=Gerät Byte
           Diese Einstellungen steueren den Controller io in der vereinigten Hierarchie.

           Setzt die gerätebezogene maximale Gesamt-Block-E/A-Bandbreitenbegrenzung für den
           ausgeführten Prozess, falls die vereinigte Control-Gruppenhierarchie auf dem System
           verwandt wird. Diese Begrenzung ist nicht arbeitserhaltend und den ausgeführten
           Prozessen wird nicht mehr erlaubt, selbst falls das Gerät Leerlaufkapazität hat.
           Akzeptiert ein Leerzeichen-getrenntes Paar eines Dateipfades und eines
           Bandbreitenwertes (in Byte pro Sekunde), um die gerätespezifische Bandbreite
           festzulegen. Der Dateipfad kann als Pfad zu einem Blockgeräteknoten oder zu einer
           anderen Datei angegeben werden. In letzterem Fall wird das zugrundeliegende Blockgerät
           des Dateisystems der Datei bestimmt. Falls der Bandbreite K, M, G oder T angehängt
           ist, wird die Bandbreite als Kilobyte, Megabyte, Gigabyte bzw. Terabyte zu der Basis
           1000 ausgewertet. (Beispiel: »/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M«).
           Dies steuert das Control-Gruppen-Attribut »io.max«. Verwenden Sie diese Option
           mehrfach, um Bandbreitenbegrenzungen für mehrere Geräte zu setzen. Für Details über
           dieses Control-Gruppen-Attribut siehe E/A-Schnittstellen-Dateien[8].

           Ähnliche Beschränkungen für die Blockgeräte-Erkennung gelten wie bei IODeviceWeight=,
           siehe oben.

           Hinzugefügt in Version 230.

       IOReadIOPSMax=Gerät EAPS, IOWriteIOPSMax=Gerät EAPS
           Diese Einstellungen steueren den Controller io in der vereinigten Hierarchie.

           Setzt die gerätebezogene maximale Gesamt-Block-E/A-EA-Pro-Sekunden-Begrenzung für den
           ausgeführten Prozess, falls die vereinigte Control-Gruppenhierarchie auf dem System
           verwandt wird. Diese Begrenzung ist nicht arbeitserhaltend und den ausgeführten
           Prozessen wird nicht mehr als dieser Wert erlaubt, selbst falls das Gerät
           Leerlaufkapazität hat. Akzeptiert ein Leerzeichen-getrenntes Paar eines Dateipfades
           und eines EAPS-Wertes, um den gerätespezifischen EAPS festzulegen. Der Dateipfad kann
           als Pfad zu einem Blockgeräteknoten oder zu einer anderen Datei angegeben werden. In
           letzterem Fall wird das zugrundeliegende Blockgerät des Dateisystems der Datei
           bestimmt. Falls dem EAPS K, M, G oder T angehängt ist, wird der EAPS als KiloEAPS,
           MegaEAPS, GigaEAPS bzw. TeraEAPS zu der Basis 1000 ausgewertet. (Beispiel:
           »/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K«). Dies steuert das
           Control-Gruppen-Attribut »io.max«. Verwenden Sie diese Option mehrfach, um
           EAPS-Begrenzungen für mehrere Geräte zu setzen. Für Details über dieses
           Control-Gruppen-Attribut siehe E/A-Schnittstellen-Dateien[8].

           Ähnliche Beschränkungen für die Blockgeräte-Erkennung gelten wie bei IODeviceWeight=,
           siehe oben.

           Hinzugefügt in Version 230.

       IODeviceLatencyTargetSec=Gerät Ziel
           Diese Einstellung steuert den Controller io in der vereinigten Hierarchie.

           Setzt die gerätebezogene durchschnittliche Ziel-E/A-Latenz für den ausgeführten
           Prozess, falls die vereinigte Control-Gruppenhierarchie auf dem System verwandt wird.
           Akzeptiert einen Dateipfad und eine Zeitspanne, getrennt durch ein Leerzeichen, um das
           gerätespezifische Latenzziel festzulegen. (Beispiel: "/dev/sda 25ms"). Der Dateipfad
           kann als Pfad zu einem Blockgeräteknoten oder zu einer anderen Datei angegeben werden.
           In letzterem Fall wird das zugrundeliegende Blockgerät des Dateisystems der Datei
           bestimmt. Dies steuert das Control-Gruppen-Attribut »io.latency«. Verwenden Sie diese
           Option mehrfach, um Latenzziele für mehrere Geräte zu setzen. Für Details über dieses
           Control-Gruppen-Attribut siehe E/A-Schnittstellen-Dateien[8].

           Impliziert »IOAccounting=yes«.

           Diese Einstellungen werden nur unterstützt, falls die vereinigte
           Control-Gruppenhierarchie verwandt wird.

           Ähnliche Beschränkungen für die Blockgeräte-Erkennung gelten wie bei IODeviceWeight=,
           siehe oben.

           Hinzugefügt in Version 240.

   Netzwerk-Buchführung und -Steuerung
       IPAccounting=
           Akzeptiert ein logisches Argument. Falls wahr, wird die IPv4- und
           IPv6-Netzwerkverkehrsbuchführung für Pakete, die von dieser Unit gesandt oder
           empfangen werden, eingeschaltet. Wenn diese Option eingeschaltet wird, erfolgt für
           alle von einem der Prozesse der Unit erstellten IPv4- und IPv6-Sockets die
           Buchführung.

           Wenn diese Option in Socket-Units verwandt wird, wird sie auf alle hierzu zugeordneten
           IPv4- und IPv6-Socket (einschließlich der auf Anfragen wartenden und der
           Verbindugssockets, wo dies zutrifft) angewandt. Beachten Sie, dass für
           Socket-aktivierte Dienste diese Konfigurationseinstellung und die Buchuführungsdaten
           der Dienste-Unit und der Socket-Unit getrennt bleiben und getrennt dargestellt werden.
           Es erfolgt keine Weitergabe der Einstellung und der gesammelten Daten, in keine
           Richtung. Zudem wird sämtlicher Verkehr, der auf einem der Sockets der Socket-Unit
           empfangen oder gesandt wird für die Socket-Unit buchgeführt — und niemals für die
           Dienste-Unit, die sie aktiviert haben könnte, selbst falls der Socket von dieser
           verwandt wird.

           Die Systemvorgabe für diese Einstellung kann mit DefaultIPAccounting= in
           systemd-system.conf(5) gesteuert werden.

           Hinzugefügt in Version 235.

       IPAddressAllow=ADRESSE[/PRÄFIXLÄNGE]…, IPAddressDeny=ADRESSE[/PRÄFIXLÄNGE]…
           Schaltet Netzwerkverkehrsfilterung für IP-Pakete, die über AF_INET- und
           AF_INET6-Sockets gesandt oder empfangen werden, ein. Beide Anweisungen akzeptieren
           eine Leerzeichen-getrennte Liste von IPv4- oder IPv6-Adressen, an jede kann optional
           eine Adresspräfixlänge in Bits nach einem Zeichen »/« angehängt werden. Falls die
           Endung entfällt, wird die Adresse als Rechneradresse betrachtet, d.h. der Filter deckt
           die gesamte Adresse ab (32 Bit für IPv4, 128 Bit für IPv6).

           Die mit dieser Option konfigurierten Zugriffslisten werden auf allen von dieser Unit
           erstellten Sockets (oder im Falle von Socket-Units, allen der Unit zugeordneten)
           angewandt. Die Liste wird implzit mit jeder für irgendeine Elternscheibe, bei der
           diese Unit Mitglied sein könnte, kombiniert. Standardmäßig sind beide Zugriffslisten
           leer. Durch diese Einstellung wird sowohl ein- als auch ausgehender Verkehr gefiltert.
           Im Falle des eingehenden Verkehrs wird die Quell-IP-Adresse gegen diese Zugriffslisten
           geprüft, im Falle des ausgehenden Verkehrs wird die Ziel-IP-Adresse geprüft. Die
           folgenden Regeln werden nacheinander angewandt:

           •   Falls die überpüfte IP-Adresse auf einen Eintrag in der Einstellung
               IPAddressAllow= passt, wird der Zugriff erlaubt.

           •   Falls die überprüfte IP-Adresse auf einen Eintrag in der Liste IPAddressDeny=
               passt, wird andernfalls der Zugriff verweigert.

           •   Andernfalls wird der Zugriff gewährt.

           Um eine IP-Firewall mit Positivliste zu implementieren, wird empfohlen, eine
           Einstellung IPAddressDeny=any in einer höherstufigen Scheiben-Unit (wie der
           Wurzel-Scheibe -.slice oder der Scheibe, die alle Systemdienste enthält, system.slice
           – siehe systemd.special(7) für Details über diese Scheiben-Units) zu verwenden,
           ergänzt um individuelle, dienstebezogene IPAddressAllow=-Zeilen, die Netzwerkzugriff
           auf relevante Dienste, und nur diese, erlauben.

           Beachten Sie, dass für Socket-aktivierte Dienste die IP-Zugriffsliste, die in der
           Socket-Unit konfiguriert ist, auf alle direkt zugeordneten Sockets angewandt wird,
           aber nicht auf irgendein Socket, das von den dafür schließlich aktivierten Diensten
           erstellt wurde. Umgekehrt werden die für die Dienste konfigurierten IP-Zugriffslisten
           nicht auf irgendein Socket angewandt, das dem Dienst über Socket-Aktivierung
           weitergegeben wird. Daher ist es im Allgemeinen eine gute Idee, die IP-Zugriffsliste
           sowohl in der Socket- als auch der Dienste-Unit zu replizieren. Es kann sinnvoll sein,
           eine Liste offener und eine Liste beschränkter zu verwalten, abhängig vom Einsatzfall.

           Falls diese Einstellungen mehrfach in der gleichen Unit verwandt werden, werden die
           angegebenen Listen kombiniert. Falls diesen Einstellungen eine leere Zeichenkette
           zugewiesen wird, werden die angegebenen Zugriffslisten zurückgesetzt und alle
           vorherigen Einstellungen aufgehoben.

           Anstelle expliziter IPv4- oder IPv6-Adressen und Präfixlängenfestlegungen kann auch
           eine kleine Gruppe von symbolischen Namen verwandt werden. Die folgenden Namen sind
           definiert:

           Tabelle 1. Besondere Adress-/Netzwerknamen
           ┌──────────────────┬──────────────────────────┬──────────────────────────┐
           │Symbolischer NameDefinitionBedeutung                │
           ├──────────────────┼──────────────────────────┼──────────────────────────┤
           │any               │ 0.0.0.0/0 ::/0           │ jeder Rechner            │
           ├──────────────────┼──────────────────────────┼──────────────────────────┤
           │localhost         │ 127.0.0.0/8 ::1/128      │ alle Adressen auf dem    │
           │                  │                          │ lokalen Loopback         │
           ├──────────────────┼──────────────────────────┼──────────────────────────┤
           │link-local        │ 169.254.0.0/16 fe80::/64 │ alle linklokalen         │
           │                  │                          │ IP-Adressen              │
           ├──────────────────┼──────────────────────────┼──────────────────────────┤
           │multicast         │ 224.0.0.0/4 ff00::/8     │ alle                     │
           │                  │                          │ IP-multicasting-Adressen │
           └──────────────────┴──────────────────────────┴──────────────────────────┘
           Beachten Sie, dass diese Einstellungen auf einigen Systemen nicht unterstützt werden
           könnten (beispielsweise falls eBPF-Control-Gruppen-Unterstützung nicht im
           unterliegenden Kernel oder Container-Verwalter aktiviert ist). Diese Einstellungen
           haben in diesem Fall keine Auswirkung. Falls Kompatibilität mit solchen Systemen
           gewünscht ist, wird daher empfohlen, sich nicht exklusiv auf sie für IP-Sicherheit zu
           verlassen.

           Diese Option kann nicht durch Voranstellen von »+« vor den Ausführungspfad in der
           Dienste-Unit umgangen werden, da sie für die gesamte Control-Gruppe gilt.

           Hinzugefügt in Version 235.

       SocketBindAllow=Binderegel, SocketBindDeny=Binderegel
           Erlaubt oder verweigert das Anbinden einer Socket-Adresse an ein Socket durch
           Vergleich mit der Binderegel und Anwendung der entsprechenden Aktion, falls ein
           Treffer vorliegt

           Binderegel beschreibt Socket-Eigenschaften wie Adressfamilie, Transportprotokoll und
           IP-Ports.

           Binderegel := { [Adressfamilie:][Transportprotokoll:][IP-Ports] | any }

           Adressfamilie := { ipv4 | ipv6 }

           Transportprotokoll := { tcp | udp }

           IP-Ports:= { IP-Port | IP-Port-Bereich }

           Eine optionale Adressfamilie erwartet die Werte ipv4 oder ipv6. Falls nicht angegeben,
           passt eine Regel auf sowohl IPv4- als auch IPv6-Adressen und wird abhängig von anderen
           Socket-Felder angewendet, z.B. Transportprotokoll, IP-Port.

           Ein optionales Transportprotokoll erwartet den Transportprotokollnamen tcp oder udp.
           Falls nicht festgelegt, passt eine Regel auf jedes Transportprotokoll.

           Ein optionaler Wert IP-Port muss innerhalb des Intervalls 1…65535 (einschließlich)
           liegen, d.h. der dynamische Port 0 ist nicht erlaubt. Ein Bereich von fortlaufenden
           Ports wird durch IP-Port-Bereich IP-Port-niedrig-IP-Port-hoch beschrieben, wobei
           IP-Port-niedrig kleiner oder gleich IP-Port-hoch ist und beide innerhalb von 1…65535
           (einschließlich) liegen.

           Ein besonderer Wert any kann zum Anwenden einer Regel für jede Adressfamilie, jedes
           Transportprotokoll und jeden Port mit einem positiven Wert verwandt werden.

           Um mehrere Regeln zu erlauben, weisen Sie SocketBindAllow= oder SocketBindDeny=
           mehrfach zu. Um eine Zuweisung zurückzusetzen, übergeben Sie eine leere Zuweisung
           SocketBindAllow= oder SocketBindDeny=.

           Für sowohl SocketBindAllow= als auch SocketBindDeny= ist die maximale Anzahl an
           Zuweisungen 128.

           •   Anbinden an ein Socket wird erlaubt, wenn die Socket-Adresse auf einen Eintrag in
               der Liste SocketBindAllow= passt.

           •   Andernfalls wir das Anbinden verweigert, falls die Socket-Adresse auf einen
               Eintrag in der Liste SocketBindDeny= passt.

           •   Andernfalls wird das Anbinden erlaubt.

           Die Funktionalität ist mit Cgroup-BPF-Hooks cgroup/bind4 und cgroup/bind6
           implementiert.

           Beispiele:

               ...
               # Erlaubt das Anbinden von IPv6-Socket-Adressen mit Ports größer oder gleich 10000.
               [Service]
               SocketBindAllow=ipv6:10000-65535
               SocketBindDeny=any
               …
               # Erlaubt das Anbinden von IPv4- und IPv6-Socket-Adressen mit 1234 und 4321 Ports.
               [Service]
               SocketBindAllow=1234
               SocketBindAllow=4321
               SocketBindDeny=any
               …
               # Verweigert das Anbinden von IPv6-Socket-Adressen.
               [Service]
               SocketBindDeny=ipv6
               …
               # Verweigert das Anbinden von IPv4- und IPv6-Socket-Adressen.
               [Service]
               SocketBindDeny=any
               …
               # Erlaubt das Anbinden nur über TCP
               [Service]
               SocketBindAllow=tcp
               SocketBindDeny=any
               …
               # Erlaubt das Anbinden nur über IPv6/TCP
               [Service]
               SocketBindAllow=ipv6:tcp
               SocketBindDeny=any
               …
               # Erlaubt das Anbinden von Ports innerhalb des Bereichs 10000-65535 über IPv4/UDP.
               [Service]
               SocketBindAllow=ipv4:udp:10000-65535
               SocketBindDeny=any
               …

           Diese Option kann nicht durch Voranstellen von »+« vor den Ausführungspfad in der
           Dienste-Unit umgangen werden, da sie für die gesamte Control-Gruppe gilt.

           Hinzugefügt in Version 249.

       RestrictNetworkInterfaces=
           Akzeptiert eine Leerzeichen-getrennte Liste von Netzwerkschnittstellennamen. Diese
           Option beschränkt die Netzwerkschnittstellen, die Prozesse dieser Unit verwenden
           können. Standardmäßig können Prozesse nur die aufgeführten Netzwerknamen verwenden
           (Erlaubnisliste). Falls das erste Zeichen der Regel eine »~« ist, dann wird die
           Auswirkung invertiert: die Prozesse können nur Netzwerkschnittstellen verwenden, die
           nicht aufgeführt sind (Verbotsliste).

           Diese Option kann mehrfach aufauchen, dann werden die Netzwerkschnittstellennamen
           vereinigt. Falls die leere Zeichenkette zugewiesen wird, wird die Gruppe
           zurückgesetzt, alle vorherigen Zuweisungen haben keine Wirkung.

           Falls Sie beide Typen dieser Option festlegen (d.h. Erlaubnisliste und Verbotsliste),
           wird die zuerst vorkommende Vorrang haben und die Standardaktion vorgeben (erlauben
           oder verbieten). Dann wird das nächste Vorkommen dieser Option die aufgeführten
           Netzwerkschnittstellennamen zu der Menge hinzufügen oder sie daraus entfernen,
           abhängig von seinem Typ und der Vorgabeaktion.

           Die Loopback-Schnittstelle (»lo«) wird auf keine Weise besonders behandelt, Sie müssen
           sie explizit in der Unit-Datei konfigurieren.

           Beispiel 1: Erlaubnisliste

               RestrictNetworkInterfaces=eth1
               RestrictNetworkInterfaces=eth2

           Programme in dieser Unit-Datei werden nur in der Lage sein, die Netzwerkschnittstellen
           eth1 und eth2 zu verwenden.

           Beispiel 2: Verbotsliste

               RestrictNetworkInterfaces=~eth1 eth2

           Programme in dieser Unit-Datei werden in der Lage sein, alle Netzwerkschnittstellen
           außer eth1 und eth2 zu verwenden.

           Beispiel 3: gemischt

               RestrictNetworkInterfaces=eth1 eth2
               RestrictNetworkInterfaces=~eth1

           Programme in der Unit-Datei werden nur in der Lage sein, die Netzwerkschnittstelle
           eth2 zu verwenden.

           Diese Option kann nicht durch Voranstellen von »+« vor den Ausführungspfad in der
           Dienste-Unit umgangen werden, da sie für die gesamte Control-Gruppe gilt.

           Hinzugefügt in Version 250.

       NFTSet=Familie:Tabelle:Gruppe
           This setting provides a method for integrating dynamic cgroup, user and group IDs into
           firewall rules with NFT[9] sets. The benefit of using this setting is to be able to
           use the IDs as selectors in firewall rules easily and this in turn allows more fine
           grained filtering. NFT rules for cgroup matching use numeric cgroup IDs, which change
           every time a service is restarted, making them hard to use in systemd environment
           otherwise. Dynamic and random IDs used by DynamicUser= can be also integrated with
           this setting.

           This option expects a whitespace separated list of NFT set definitions. Each
           definition consists of a colon-separated tuple of source type (one of "cgroup", "user"
           or "group"), NFT address family (one of "arp", "bridge", "inet", "ip", "ip6", or
           "netdev"), table name and set name. The names of tables and sets must conform to
           lexical restrictions of NFT table names. The type of the element used in the NFT
           filter must match the type implied by the directive ("cgroup", "user" or "group") as
           shown in the table below. When a control group or a unit is realized, the
           corresponding ID will be appended to the NFT sets and it will be be removed when the
           control group or unit is removed. systemd only inserts elements to (or removes from)
           the sets, so the related NFT rules, tables and sets must be prepared elsewhere in
           advance. Failures to manage the sets will be ignored.

           Tabelle 2. Definierte Quelltyp-Werte
           ┌─────────┬─────────────────────────┬────────────────┐
           │QuelltypBeschreibungEntsprechender │
           │         │                         │ NFT-Typname    │
           ├─────────┼─────────────────────────┼────────────────┤
           │"cgroup" │ Control-Gruppen-Kennung │ "cgroupsv2"    │
           ├─────────┼─────────────────────────┼────────────────┤
           │"user"   │ Benutzerkennung         │ "meta skuid"   │
           ├─────────┼─────────────────────────┼────────────────┤
           │"group"  │ Gruppenkennung          │ "meta skgid"   │
           └─────────┴─────────────────────────┴────────────────┘
           If the firewall rules are reinstalled so that the contents of NFT sets are destroyed,
           command systemctl daemon-reload can be used to refill the sets.

           Beispiel:

               [Unit]
               NFTSet=cgroup:inet:filter:my_service user:inet:filter:serviceuser

           Entsprechende NFT-Regeln:

               table inet filter {
                       set my_service {
                               type cgroupsv2
                       }
                       set serviceuser {
                               typeof meta skuid
                       }
                       chain x {
                               socket cgroupv2 level 2 @my_service accept
                               drop
                       }
                       chain y {
                               meta skuid @serviceuser accept
                               drop
                       }
               }

           Hinzugefügt in Version 255.

   BPF-Programme
       IPIngressFilterPath=BPF_FS_PROGRAM_PATH, IPEgressFilterPath=BPF_FS_PROGRAM_PATH
           Fügt angepasste Netzwerkverkehrsfilter hinzu, die als BPF-Programme implementiert und
           auf alle über AF_INET- und AF_INET6-Sockets gesandten und empfangenen IP-Pakete
           angewandt werden. Akzeptiert einen absoluten Pfad zu einem im virtuellen
           BPF-Dateisystem ((/sys/fs/bpf/) verankerten BPF-Programm.

           Die mit dieser Option konfigurierten Filter werden auf allen von dieser Unit
           erstellten Sockets (oder im Falle von Socket-Units, allen der Unit zugeordneten)
           angewandt. Die Filter werden zusätzlich zu den Filter aller Eltern-Scheiben-Units, bei
           denen diese Unit ein Mitglied sein könnte, sowie sämtlichen IPAddressAllow=- und
           IPAddressDeny=-Filtern in jeden dieser Units geladen. Standardmäßig sind keine Filter
           festgelegt.

           Falls diese Einstellungen mehrfach in der gleichen Unit verwandt werden, werden alle
           angegebenen Programme angehängt. Falls diesen Einstellungen eine leere Zeichenkette
           zugewiesen wird, wird die Programmliste zurückgesetzt und alle vorher angegebenen
           Programme ignoriert.

           Falls der Pfad BPF_FS_PROGRAM_PATH in der Zuweisung IPIngressFilterPath= bereits durch
           einen Eingangs-Hook BPFProgram= gehandhabt wird, z.B.
           BPFProgram=ingress:BPF_FS_PROGRAM_PATH, dann wird die Zuweisung immer noch als gültig
           betrachtet und das Programm an eine Cgroup angehängt. Genauso für den Pfad
           IPEgressFilterPath= und den Hook egress.

           Beachten Sie, dass für Socket-aktivierte Dienste die IP-Filterprogramme, die in der
           Socket-Unit konfiguriert sind, auf alle direkt zugeordneten Sockets angewandt werden,
           aber nicht auf irgendein Socket, das von den dafür schließlich aktivierten Diensten
           erstellt wurde. Umgekehrt werden die für die Dienste konfigurierten IP-Filterprogramme
           nicht auf irgendein Socket angewandt, das dem Dienst über Socket-Aktivierung
           weitergegeben wird. Daher ist es im Allgemeinen eine gute Idee, die IP-Filterprogramme
           sowohl in der Socket- als auch der Dienste-Unit zu replizieren, allerdings ergibt es
           oft Sinn, eine Konfiguration offener und eine andere beschränkter zu verwalten,
           abhängig vom Einsatzfall.

           Beachten Sie, dass diese Einstellungen auf einigen Systemen nicht unterstützt werden
           könnten (beispielsweise falls eBPF-Control-Gruppen-Unterstützung nicht im
           unterliegenden Kernel oder Container-Verwalter aktiviert ist). Diese Einstellungen
           führen in diesem Fall zu einem Fehlschlag des Dienstes. Falls Kompatibilität mit
           solchen Systemen gewünscht ist, wird daher empfohlen, ihre Filter manuell (benötigt
           Delegate=yes) anzuhängen, statt diese Einstellung zu verwenden.

           Hinzugefügt in Version 243.

       BPFProgram=Typ:Programmpfad
           BPFProgram= erlaubt das Anhängen von angepassten BPF-Programmen an die Cgroup einer
           Unit. (Dies verallgemeinert die mittels IPEgressFilterPath= und IPIngressFilterPath=
           für andere Hooks offengelegte Funktionalität.) Cgroup-bpf-Hooks in der Form von
           BPF-Programmen, die in das BPF-Dateisystem geladen werden, werden mit den durch die
           Unit ermittelten Cgroup-Bpf-Anhänge-Schaltern angehängt. Für Details über
           Anhänge-Typen und Schalter siehe bpf.h[10]. Schauen Sie auch in die allgemeine
           BPF-Dokumentation[11].

           Die Spezifikation eines BPF-Programms besteht aus einem Paar aus BPF-Programmtyp und
           -Programmpfad im Dateisystem, wobei »:« der Trenner ist: Typ:Programmpfad.

           Der BPF-Programmtyp ist äquivalent zu dem in bpftool(8) verwandten BPF-Anhängetyp. Er
           kann sein: egress, ingress, sock_create, sock_ops, device, bind4, bind6, connect4,
           connect6, post_bind4, post_bind6, sendmsg4, sendmsg6, sysctl, recvmsg4, recvmsg6,
           getsockopt oder setsockopt.

           Der festgelegte Programmpfad muss ein absoluter Pfad sein, der eine BPF-Programm-Inode
           in dem bpffs-Dateisystem referenziert (dies bedeutet im Allgemeinen, dass er mit
           »/sys/fs/bpf/« beginnt). Falls ein festgelegtes Programm nicht existiert (d.h. es noch
           nicht in das BPF-Subsystem des Kernels hochgeladen wurde), wird es nicht installiert,
           aber mit der Unit-Aktivierung wird fortgefahren (in die Protokolle wird eine Warnung
           ausgegeben).

           Durch Setzen von BPFProgram= auf einen leeren Wert werden vorherige Zuweisungen
           unwirksam.

           Mehrfache Zuweisungen des gleichen Werts Programmtyp/Pfad-Paar haben die gleiche
           Auswirkung wie eine einzelne Zuweisung: Das Programm wird nur einmal angehängt.

           Falls das auf Programmpfad befestigte BPF-egress bereits durch IPEgressFilterPath=
           behandelt wird, wird die Zuweisung BPFProgram= als gültig betrachtet und BPFProgram=
           an eine Cgroup angehängt. Ähnlich für den Hook ingress die Zuweisung
           IPIngressFilterPath=.

           Mit BPFProgram= übergebene BPF-Programme werden an die Cgroup einer Unit mit dem
           BFP-Anhängeschalter multi angehängt, der weitere Anhängungen des gleichen Typs
           innerhalb der Cgroup-Hierarchie mit der Unit-Cgroup an der Spitze erlaubt.

           Beispiele:

               BPFProgram=egress:/sys/fs/bpf/egress-hook
               BPFProgram=bind6:/sys/fs/bpf/sock-addr-hook

           Hinzugefügt in Version 249.

   Gerätezugriff
       DeviceAllow=
           Steuert Zugriff auf bestimmte Geräteknoten durch ausgeführte Prozesse. Akzeptiert zwei
           Leerzeichen-getrennte Zeichenketten: einen Geräteknotenkennzeichner, gefolgt von einer
           Kombination aus r, w, m, um das Lesen, Schreiben bzw. Erstellen von bestimmten
           Geräteknoten der Unit (mit mknod) zu steuern. Diese Funktionalität ist mittels
           eBPF-Filterung implementiert.

           Wenn der Zugriff auf alle physischen Geräte verboten werden soll, kann stattdessen
           PrivateDevices= verwandt werden. Siehe systemd.exec(5).

           Der Geräteknotenkennzeichner ist entweder ein Pfad zu einem Geräteknoten in dem
           Dateisystem, beginnend mit /dev/, oder eine Zeichenkette, die entweder mit »char-«
           oder »block-« beginnt und von einem Gerätegruppennamen, wie in /proc/devices
           aufgeführt, gefolgt wird. Letzteres ist nützlich, um eine Positivliste aller aktuellen
           und zukünftigen Geräte, die zu einer bestimmten Gerätegruppe gehören, auf einmal
           anzulegen. Die Gerätegruppe wird entsprechend der Dateinamen-Glob-Muster-Regeln
           abgeglichen, Sie können daher die Metazeichen »*« und »?« verwenden. (Beachten Sie,
           dass solche Glob-Metazeichen nicht für Geräteknotenpfadspezifikationen verfügbar sind)
           Um Geräteknoten gemäß Major-/Minor-Nummern abzugleichen, verwenden Sie
           Geräteknotenpfade in den Verzeichnissen /dev/char/ und /dev/block/. Allerdings wird
           das Abgleichen von Geräten mittels Major-/Minor-Nummer im Allgemeinen nicht empfohlen,
           da die Zuweisungen zwischen Systemen oder verschiedenen Kernelversionen weder stabil
           noch portierbar sind.

           Beispiel: /dev/sda5 ist ein Pfad zu einem Geräteknoten, der sich auf ein ATA- oder
           SCSI-Blockgerät bezieht. »char-pts« und »char-alsa« sind Kennzeichner für alle
           Pseudo-TTY- bzw. alle ALSA-Sound-Geräte. »char-cpu/*« ist ein Kennzeichner, der auf
           alle Gerätegruppen mit CPU-Bezug passt.

           Beachten Sie, dass auf diese Weise definierte Positivlisten nur Gerätegruppen
           referenzieren sollten, die zum Startzeitpunkt der Unit auflösbar sind. Sämtliche
           Geräte, die zu diesem Zeitpunkt nicht auflösbar sind, werden nicht zur Positivliste
           hinzugefügt. Um diese Einschränkung zu umgehen, können Sie Dienste-Units um eine Paar
           von After=modprobe@xyz.service- und Wants=modprobe@xyz.service-Zeilen ergänzen, die
           die notwendigen Kernelmodule laden, die die Gerätegruppe implementieren, falls sie
           fehlen. Beispiel:

               ...
               [Unit]
               Wants=modprobe@loop.service
               After=modprobe@loop.service

               [Service]
               DeviceAllow=block-loop
               DeviceAllow=/dev/loop-control
               …

           Diese Option kann nicht durch Voranstellen von »+« vor den Ausführungspfad in der
           Dienste-Unit umgangen werden, da sie für die gesamte Control-Gruppe gilt.

           Hinzugefügt in Version 208.

       DevicePolicy=auto|closed|strict
           Steuert die Richtlinien zum Erlauben des Gerätezugriffs:

           strict
               bedeutet, nur Zugriffstypen zu erlauben, die explizit festgelegt wurden.

               Hinzugefügt in Version 208.

           closed
               erlaubt zusätzlich Zugriff auf die Standard-Pseudo-Geräte einschließlich
               /dev/null, /dev/zero, /dev/full, /dev/random und /dev/urandom.

               Hinzugefügt in Version 208.

           auto
               erlaubt zusätzlich Zugriff auf alle Geräte, falls kein explizites DeviceAllow=
               vorhanden ist. Dies ist die Vorgabe.

               Hinzugefügt in Version 208.

           Diese Option kann nicht durch Voranstellen von »+« vor den Ausführungspfad in der
           Dienste-Unit umgangen werden, da sie für die gesamte Control-Gruppe gilt.

           Hinzugefügt in Version 208.

   Control-Gruppen-Verwaltung
       Slice=
           Der Name der Scheiben-Unit, in die die Unit hineingelegt werden soll. Standardmäßig
           system.slice für alle noch nicht instanziierten Units aller Unit-Typen (außer für
           Scheiben-Units selbst, siehe unten). Instanzen-Units werden standardmäßig in eine
           Unterscheibe von system.slice gelegt, die nach dem Vorlagennamen benannt ist.

           Diese Option kann zur Anordnung von Systemd-Units in einer Hierarchie von Scheiben
           verwandt werden, bei der bei jeder Scheibe Ressourceneinstellungen angewandt werden
           können.

           Für Units vom Typ »Scheibe« ist der einzige für diese Einstellung akzeptierte Wert die
           Elternscheibe. Da der Name einer Scheiben-Unit die Elternscheibe impliziert, ist es
           daher immer redundant, diesen Parameter direkt für Scheiben-Units zu setzen.

           Besondere Vorsicht sollten Sie walten lassen, wenn Sie sich auf die
           Vorgabe-Scheibenzuweisung in vorlagenbasierten Dienste-Units, die
           DefaultDependencies=no gesetzt haben, verlassen, siehe systemd.service(5) Abschnitt
           »Standardabhängigkeiten« für Details.

           Hinzugefügt in Version 208.

       Delegate=
           Schaltet die Delegierung weiterer Ressourcensteuereinteilung auf die Prozesse der Unit
           ein. Units, bei denen dieses aktiviert ist, können ihre eigene private Unterhierarchie
           von Control-Gruppen unterhalb der Control-Gruppe der Unit selbst einrichten und
           verwalten. Für nicht privilegierte Dienste (d.h. solchen, die die Einstellung User=
           verwenden), erhält der relevante Benutzer Zugriff auf die Control-Gruppe der Unit.

           Wenn dies aktiviert ist, wird der Diensteverwalter es unterlassen, die Control-Gruppen
           zu verändern oder Prozesse unterhalb der Control-Gruppe der Unit zu verschieben, so
           dass ein klares Konzept der Eigentümerschaft etabliert wird: der Control-Gruppenbaum
           auf der Ebene der Control-Gruppe der Unit ond oberhalb (d.h. in Richtung der
           Wurzel-Control-Gruppe) gehört dem Diensteverwalter des Rechners und wird von ihm
           verwaltet, während der Control-Gruppenbaum unterhalb der Control-Gruppe der Unit der
           Unit selbst gehört und von dieser verwaltet wird.

           Akzeptiert entweder ein logisches Argument oder eine (möglicherweise leere) Liste von
           Namen von Control-Gruppen-Controllern. Falls wahr, wird die Delegierung eingeschaltet
           und alle für die Unit unterstützten Controller werden aktiviert, wodurch sie für die
           Verwaltung der Prozesse der Unit verfügbar werden. Falls falsch, wird die Delegierung
           komplett ausgeschaltet (und keine zusätzlichen Controller werden aktiviert). Falls auf
           eine Liste von Controllern gesetzt, wird die Delegierung eingeschaltet und die
           festgelegten Controller werden für die Unit aktiviert. Zuweisung der leeren Liste wird
           Delegierung aktivieren, aber die Liste der Controller zurücksetzen, und alle
           vorherigen Zuweisungen haben keine Auswirkung. Beachten Sie, dass andere als die
           festgelegten Controller auch verfügbar gemacht werden können, abhängig von der
           Konfiguration der enthaltenen Scheibe oder anderer, darin enthaltener Units.
           Standardmäßig falsch.

           Beachten Sie, dass Controller-Delegation an weniger privilegierten Code nur auf der
           vereinigten Control-Gruppenhierarchie sicher ist. Entsprechend wird der Zugriff auf
           die angegebenen Controller nicht an unprivilegierte Dienste auf der veralteten
           Hierarchie gewährt, selbst falls dies angefragt wurde.

           Die folgenden Controller-Namen können festgelegt werden: cpu, cpuacct, cpuset, io,
           blkio, memory, devices, pids, bpf-firewall, und bpf-devices.

           Nicht alle dieser Controller sind allerdings auf allen Kerneln verfügbar und einige
           sind spezifisch für die vereinigte Hierarchie, während andere für die veraltete
           Hierarchie spezifisch sind. Beachten Sie auch, dass der Kernel weitere Controller
           unterstützen könnte, die hier noch nicht berücksichtigt sind, da Delegation hierfür
           überhaupt noch nicht unterstützt wird oder noch nicht sauber definiert ist.

           Beachten Sie, dass aufgrund der hierarchischen Natur der Cgroup-Hierarchie alle
           delegierten Controller für die Eltern- und Geschwister-Units der Units der Delegierung
           aktiviert werden.

           Für weitere Details über das Delegationsmodell ziehen Sie bitte Control-Gruppen-APIs
           und Delegierung[12] heran.

           Hinzugefügt in Version 218.

       DelegateSubgroup=
           Legt Unit-Prozesse in die festgelegte Untergruppe der Control-Gruppe der Unit ab.
           Akzeptiert den Namen einer gültigen Control-Gruppe (nicht den Pfad!) als Parameter
           oder eine leere Zeichenkette, um diese Funktionalität abzuschalten. Standardmäßig
           abgeschaltet. Der Name der Control-Gruppe muss als Dateiname benutzbar sein und
           Konflikte mit den Control-Gruppen-Attributdateien des Kernels vermeiden (d.h.
           cgroup.procs kann nicht als Name akzeptiert werden, da der kernel eine native
           Control-Gruppen-Attributdatei mit dem Namen offenlegt). Diese Option hat nur
           Auswirkungen, wenn die Control-Gruppendelegation mittels Delegate= eingeschaltet ist,
           siehe oben. Beachten Sie, dass diese Einstellung nur für den »Haupt«-Prozess einer
           Unit gilt, d.h. für Dienste auf ExecStart=, aber nicht für ExecReload= und ähnliche.
           Falls Delegierung aktiviert ist, wird letztere immer innerhalb einer Untergruppe
           namens ».control« abgelegt. Die festgelegte Untergruppe wird automatisch erstellt (und
           möglicherweise die Eigentümerschaft an die für die Unit konfigurierten
           Benutzer/Gruppen abgegeben), wenn darin ein Prozess gestartet wird.

           Diese Option ist nützlich, um das manuelle Verschieben des aufgerufenen Prozesses in
           eine Untergruppe zu vermeiden, nachdem dieser gestartet wurde. Da kein Prozess in den
           inneren Inodes der Control-Gruppenbaumes leben sollte, ist es fast immer notwendig,
           den Hauptprozess (»Überwacher«) einer Unit, bei der Delegierung eingeschaltet ist, in
           einer Untergruppe auszuführen.

           Hinzugefügt in Version 254.

       DisableControllers=
           Deaktiviert Controller, so dass sie für die Kinder einer Unit nicht eingeschaltet
           werden können. Falls ein aufgeführter Controller bereits in seinem Unterbaum in
           Verwendung ist, wird der Controller aus dem Unterbaum entfernt. Damit können Sie
           vermeiden, dass Konfiguration in Kind-Units in die Lage versetzt wird, implizit oder
           explizit einen Controller einzuschalten. Standardmäßig leer.

           Es können mehrere Controller durch Leerzeichen getrennt angegeben werden. Sie können
           auch DisableControllers= mehrfach angeben, dann wird jede neue Instanz einen anderen
           Controller zum Deaktivieren hinzufügen. Wird DisableControllers= selbst ohne
           vorhandenen Controller-Namen übergeben, dann wird die Liste der deaktivierten
           Controller zurückgesetzt.

           Es mag nicht möglich sein, einen Controller zu deaktivieren, nachdem die Units
           gestartet wurden, falls die Unit oder eines der Kinder dieser Unit Controller an seine
           Kinder delegiert, da kein delegierter Unterbaum der Control-Gruppenhierarchie durch
           Systemd verwaltet wird.

           Die folgenden Controller-Namen können festgelegt werden: cpu, cpuacct, cpuset, io,
           blkio, memory, devices, pids, bpf-firewall, und bpf-devices.

           Hinzugefügt in Version 240.

   Speicherdruck-Steuerung
       ManagedOOMSwap=auto|kill, ManagedOOMMemoryPressure=auto|kill
           Gibt an, wie systemd-oomd.service(8) mit den Cgroups dieser Unit umgeht. Standardmäßig
           auto.

           Wird dies auf kill gesetzt, dann wird die Unit ein Kandidat für die Überwachung durch
           systemd-oomd. Falls die Cgroup die durch oomd.conf(5) oder die Unit-Konfiguration
           gesetzten Beschränkungen überschreitet, dann wird systemd-oomd eine Nachkommens-Cgroup
           auswählen und SIGKILL an alle darunter befindlichen Prozesse senden. Sie erhalten
           weitere Details über Kandidaten und das Tötenverhalten unter systemd-oomd.service(8)
           und oomd.conf(5).

           Wird eine dieser Eigenschaften auf kill gesetzt, führt dies zu Abhängigkeiten After=
           und Wants= auf systemd-oomd.service außer DefaultDependencies=no.

           Wird dies auf auto gesetzt, dann wird systemd-oomd nicht aktiv diese Cgroup-Daten zur
           Überwachung und Erkennung verwenden. Falls allerdings eine Vorfahr-Cgroup eine dieser
           Eigenschaften auf kill gesetzt hat, dann kann eine Unit mit auto weiterhin ein
           Kandidat für systemd-oomd zum Beenden sein.

           Hinzugefügt in Version 247.

       ManagedOOMMemoryPressureLimit=
           Setzt die durch oomd.conf(5) für diese Unit (Cgroup) gesetzte
           Standard-Speicher-Belastungsgrenze außer Kraft. Akzeptiert einen Prozentwert zwischen
           (einschließlich) 0% und 100%. Diese Eigenschaft wird ignoriert, außer
           ManagedOOMMemoryPressure=kill. Standardmäßig 0%, was bedeutet, dass die in
           oomd.conf(5) gesetzte Vorgabe verwandt wird.

           Hinzugefügt in Version 247.

       ManagedOOMPreference=none|avoid|omit
           Erlaubt das Herunterpriorisieren oder Überspringen der Cgroup dieser Unit als
           Kandidat, wenn systemd-oomd agieren muss. Benötigt Unterstützung für erweiterte
           Attribute (siehe xattr(7)), um avoid oder omit zu verwenden.

           Bei der Berechnung von Kandidaten, um die Verwendung des Auslagerungsspeichers zu
           reduzieren, wird systemd-oomd diese erweiterten Attribute nur respektieren, falls die
           Cgroup der Unit root gehört.

           Bei der Berechnung von Kandidaten, um Speicherdruck zu reduzieren, wird systemd-oomd
           diese erweiterten Attribute nur respektieren, falls der Eigentümer der Cgroup root ist
           oder falls der Eigentümber der Cgrop und der des Vorgängers identisch sind. Falls
           beispielsweise systemd-oomd Kandiaten für -.slice berechnet, werden die auf die
           Nachfahren von /user.slice/user-1000.slice/user@1000.service/ gesetzten erweiterten
           Attribute ignoriert, da die Nachfahren UID 1000 gehören und -.slice UID 0 gehört.
           Falls aber Kandidaten für /user.slice/user-1000.slice/user@1000.service/ berechnet
           werden, dann werden auf die Nachfahren gesetzte erweiterte Attribute respektiert.

           Falls diese Eigenschaft auf avoid gesetzt ist, wird der Diensteverwalter dies
           systemd-oomd mitteilen, der diese Cgroup nur auswählen wird, wenn es keinen anderen
           brauchbaren Kandidaten gibt.

           Falls diese Eigenschaft auf omit gesetzt ist, wird der Diensteverwalter dies
           systemd-oomd mitteilen, der diese Cgroup als Kandidat ignorieren und keinerlei Aktion
           auf ihr ausführen wird.

           Es wird empfohlen, avoid und omit nur vereinzelt zu verwenden, da es das
           Kill-Verhalten von systemd-oomd negativ beeinflussen kann. Beachten Sie auch, dass
           diese erweiterten Attribute nicht rekursiv auf Cgroups unterhalb der Cgroup dieser
           Unit angewandt werden.

           Standardmäßig none, was bedeutet, dass systemd-oomd die Cgroup dieser Unit wie in
           systemd-oomd.service(8) und oomd.conf(5) definiert einordnen wird.

           Hinzugefügt in Version 248.

       MemoryPressureWatch=
           Steuert die Überwachung von Speicherdruck für aufgerufene Prozesse. Akzeptiert
           entweder »off«, »on«, »auto« oder »skip«. Falls »off«, wird dem Dienst mitgeteilt,
           nicht auf Speicherdruckereignisse zu beobachten, indem die Umgebungsvariable
           $MEMORY_PRESSURE_WATCH auf die wörtliche Zeichenkette »/dev/null« gesetzt wird. Falls
           »on«, wird dem Dienst mitgeteilt, auf Speicherdruckereignisse zu beobachten. Dies
           aktiviert die Speicherbuchführung für den Dienst und stellt sicher, dass die
           Cgroup-Attributdatei memory.pressure für den Benutzer des Dienstes zum Lesen und
           Schreiben verfügbar ist. Es setzt dann die Umgebungsvariable $MEMORY_PRESSURE_WATCH
           für Prozesse, die von der Unit aufgerufen werden, auf den Dateisystempfad auf diese
           Datei. Die mittels MemoryPressureThresholdSec= konfigurierte Schwellwertinformation
           wird in der Umgebungsvariable $MEMORY_PRESSURE_WRITE kodiert. Falls der Wert »auto«
           gesetzt ist, wird das Protokoll immer aktiviert, falls Speicherbuchführung für die
           Unit sowieso aktiviert ist und andernfalls deaktiviert. Falls auf »skip« gesetzt, wird
           die Logik weder aktiviert noch deaktiviert, und die zwei Umgebungsvariablen werden
           nicht gesetzt.

           Beachten Sie, dass Dienste die Freiheit haben, die zwei Umgebungsvariablen zu
           verwenden, aber es unproblematisch ist, wenn sie sie ignorieren. Der Umgang mit
           Speicherdruck muss in jedem Dienst individuell implementiert werden und bedeutet
           normalerweise verschiedene Dinge für verschiedene Software. Weitere Details zum Umgang
           mit Speicherdruck finden Sie in Umgang mit Speicherdruck in Systemd[13].

           Mittels sd-event(3) implementierte Dienste können sd_event_add_memory_pressure(3)
           verwenden, um auf Speicherdruckereignisse zu beobachten und damit umzugehen.

           Falls nicht explizit gesetzt ist die Vorgabe für die Einstellung
           DefaultMemoryPressureWatch= in systemd-system.conf(5).

           Hinzugefügt in Version 254.

       MemoryPressureThresholdSec=
           Setzt die Speicherdruck-Schwellwertzeit für den Speicherdruck-Überwacher, wie mittels
           MemoryPressureWatch= konfiguriert. Legt die maximale Belegungsverzögerung fest, bevor
           ein Speicherdruckereignis an den Dienst signalisiert wird, pro 2s-Fenster. Falls nicht
           angegeben, ist die Vorgabe die Einstellung DefaultMemoryPressureThresholdSec= in
           systemd-system.conf(5) (die wiederum standardmäßig 200ms ist). Der festgelegte Wert
           erwartet eine Zeiteinheit wie »ms« oder »µs«, siehe systemd.time(7) zu Details für die
           erlaubte Syntax.

           Hinzugefügt in Version 254.

   Speicherauszugs-Steuerung
       CoredumpReceive=
           Takes a boolean argument. This setting is used to enable coredump forwarding for
           containers that belong to this unit's cgroup. Units with CoredumpReceive=yes must also
           be configured with Delegate=yes. Defaults to false.

           When systemd-coredump is handling a coredump for a process from a container, if the
           container's leader process is a descendant of a cgroup with CoredumpReceive=yes and
           Delegate=yes, then systemd-coredump will attempt to forward the coredump to
           systemd-coredump within the container.

           Hinzugefügt in Version 255.

GESCHICHTE

       systemd 252
           Optionen für die Steuerung der veralteten Control-Group-Hierarchie (Control-Gruppen
           Version 1[14]) sind jetzt vollständig veraltet: CPUShares=Gewicht,
           StartupCPUShares=Gewicht, MemoryLimit=Byte, BlockIOAccounting=, BlockIOWeight=Gewicht,
           StartupBlockIOWeight=Gewicht, BlockIODeviceWeight=Gerät Gewicht,
           BlockIOReadBandwidth=device Byte, BlockIOWriteBandwidth=Gerät Byte. Bitte stellen Sie
           auf die vereinigte Cgroup-Hierarchie um.

           Hinzugefügt in Version 252.

SIEHE AUCH

       systemd(1), systemd-system.conf(5), systemd.unit(5), systemd.service(5), systemd.slice(5),
       systemd.scope(5), systemd.socket(5), systemd.mount(5), systemd.swap(5), systemd.exec(5),
       systemd.directives(7), systemd.special(7), systemd-oomd.service(8), Die Dokumentation für
       Control-Gruppen und bestimmte Controller im Linux-Kernel: Control-Gruppen v2[2].

ANMERKUNGEN

        1. Neue Control-Gruppen-Schnittstellen
           https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface

        2. Control-Gruppen v2
           https://docs.kernel.org/admin-guide/cgroup-v2.html

        3. CFS-Scheduler
           https://docs.kernel.org/scheduler/sched-design-CFS.html

        4. CFS-Bandbreitensteuerung
           https://docs.kernel.org/scheduler/sched-bwc.html

        5. Speicherschnittstellen-Dateien
           https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files

        6. Zswap
           https://www.kernel.org/doc/html/latest/admin-guide/mm/zswap.html

        7. PIDS-Controller
           https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid

        8. E/A-Schnittstellen-Dateien
           https://docs.kernel.org/admin-guide/cgroup-v2.html#io-interface-files

        9. NFT
           https://netfilter.org/projects/nftables/index.html

       10. bpf.h
           https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf.h

       11. BPF-Dokumentation
           https://docs.kernel.org/bpf/

       12. Control-Gruppen-APIs und Delegierung
           https://systemd.io/CGROUP_DELEGATION

       13. Umgang mit Speicherdruck in Systemd
           https://systemd.io/MEMORY_PRESSURE

       14. Control-Gruppen Version 1
           https://docs.kernel.org/admin-guide/cgroup-v1/index.html

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
       <debian@helgefjell.de> erstellt.

       Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
       Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-
       Bedingungen. Es wird KEINE HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
       Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.