Ubuntu Manpage: systemd.resource-control - Resourcensteuerungs-Unit-Einstellungen

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.

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

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.

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.

VEREINIGTE UND VERALTETE CONTROL-GRUPPENHIERARCHIEN

Die vereinigte Control-Gruppenhierarchie ist die neue Version der Schnittstelle der
Kernel-Control-Gruppenhierarchie, siehe Control-Gruppen v2[2]. Abhängig von dem
Ressourcentyp gibt es Unterschiede in den Ressourcensteuerfähigkeiten. Da auch die
Schnittstelle sich ändert, haben einige Ressourcentypen separate Gruppen von Optionen für
die vereinigte Hierarchie.

CPU
CPUWeight= und StartupCPUWeight= ersetzen CPUShares= respektive StartupCPUShares=.

Der Controller »cpuacct« existiert auf der vereinigten Hierarchie nicht separat.

Speicher
MemoryMax= ersetzt MemoryLimit=. MemoryLow= und MemoryHigh= sind nur auf der
vereinigten Hierarchie effektiv.

IO (E/A)
Die Einstellungen, denen »IO« vorangestellt ist, sind eine Obermenge von und ersetzen
die Einstellungen, denen »BlockIO« vorangestellt ist. Auf der vereinigten Hierarchie
gilt die E/A-Ressourcensteuerung auch für gepufferte Schreibvorgänge.

Um den Übergang zu erleichtern, erfolgt die Übersetzung zwischen den zwei Versionen der
Einstellungen nach besten Kräften. Falls irgendeine der Einstellungen für die vereinigte
Hierarchie vorhanden ist, werden für jeden Controller alle Einstellugnen aus der
veralteten Hierarchie ignoriert. Falls die entstehenden Einstellungen für den anderen
Hierarchietyp sind, wird die Konfiguration vor der Anwendung übersetzt.

Die veraltete Control-Gruppenhierarchie (siehe Control-Gruppen Version 1[3]), auch als
Cgroup-v1 bekannt, erlaubt keine sichere Delegation von Controllern an unprivilegierte
Prozesse. Falls das System die veraltete Control-Gruppenhierarchie benutzt, wird die
Ressourcensteuerung für die Systemd-Benutzerinstanz deaktiviert, siehe systemd(1).

OPTIONEN

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

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.

CPUWeight=Gewicht, StartupCPUWeight=Gewicht
Weist die festgelegte CPU-Zeitgewichtung den ausgeführten Prozessen zu, falls die
vereinigte Control-Gruppenhierarchie auf dem System verwandt wird. Diese Optionen
akzeptieren einen Ganzzahlwert und steuern das Control-Group-Attribut »cpu.weight«.
Der erlaubte Bereich ist 1 bis 10000. Standardmäßig 100. Für Details über dieses
Control-Gruppen-Attribut siehe Control-Gruppen v2[2] und CFS-Auftragsplaner[4]. 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.

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.

Diese Einstellungen ersetzen CPUShares= und StartupCPUShares=.

CPUQuota=
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 sched-bwc.txt[5]. 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.

CPUQuotaPeriodSec=
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[4].

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

AllowedCPUs=, StartupAllowedCPUs=
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.

AllowedMemoryNodes=, StartupAllowedMemoryNodes=
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.

MemoryAccounting=
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.

MemoryMin=Byte, MemoryLow=Byte
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[6].

Diese Einstellung wird nur unterstützt, falls die vereinigte Control-Gruppenhierarchie
verwandt wird und deaktiviert MemoryLimit=.

Durch Angabe von DefaultMemoryMin= oder DefaultMemoryLow= (hat die gleiche Semantik
wie MemoryMin= und MemoryLow=) 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.

MemoryHigh=Byte
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[6].

Diese Einstellung wird nur unterstützt, falls die vereinigte Control-Gruppenhierarchie
verwandt wird und deaktiviert MemoryLimit=.

MemoryMax=Byte
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[2].

Diese Einstellung ersetzt MemoryLimit=.

MemorySwapMax=Bytes
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. Dies steuert das Control-Gruppen-Attribut
»memory.swap.max«. Für Details über dieses Control-Gruppen-Attribut, siehe
Speicherschnittstellen-Dateien[6].

Diese Einstellung wird nur unterstützt, falls die vereinigte Control-Gruppenhierarchie
verwandt wird und deaktiviert MemoryLimit=.

TasksAccounting=
Schaltet Prozessbuchführung für diese Unit ein. Akzeptiert ein logisches Argument.
Falls aktiviert, wird der Systemverwalter die Anzahl der Prozesse in der Unit
nachverfolgen. Die Anzahl der auf diese Art buchgeführten Prozesse 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.

TasksMax=N
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 Prozessanzahl-Controller[6].

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

IOAccounting=
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.

Diese Einstellung ersetzt BlockIOAccounting= und deaktiviert Einstellungen, denen
BlockIO oder StartupBlockIO vorangestellt sind.

IOWeight=Gewicht, StartupIOWeight=Gewicht
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.

Diese Einstellungen ersetzen BlockIOWeight= und StartupBlockIOWeight= und deaktivieren
Einstellungen, die mit BlockIO oder StartupBlockIO anfangen.

IODeviceWeight=Gerät Gewicht
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].

Diese Einstellung ersetzt BlockIODeviceWeight= und deaktiviert Einstellungen, die mit
BlockIO oder StartupBlockIO beginnen.

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.

IOReadBandwidthMax=Gerät Byte, IOWriteBandwidthMax=Gerät Byte
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].

Diese Einstellung ersetzt BlockIOReadBandwidth= und BlockIOWriteBandwidth= und
deaktiviert Einstellungen, die mit BlockIO oder StartupBlockIO beginnen.

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

IOReadIOPSMax=Gerät EAPS, IOWriteIOPSMax=Gerät EAPS
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].

Diese Einstellungen werden nur unterstützt, falls die vereinigte
Control-Gruppenhierarchie verwandt wird und deaktiviert Einstellungen, die mit BlockIO
oder StartupBlockIO beginnen.

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

IODeviceLatencyTargetSec=Gerät Ziel
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.

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.

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 Name │ Definition │ Bedeutung │
├──────────────────┼──────────────────────────┼──────────────────────────┤
│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.

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.

BPFProgram=Typ:Programmpfad
Fügt ein angepasstes Cgrup-BPF-Programm hinzu.

BPFProgram= erlaubt das Anhängen von BPF-Hooks an die Cgroup einer Systemd-Unit. (Dies
verallgemeinert die mittels IPEgressFilterPath= für ausgehenden und
IPIngressFilterPath= für eingehenden Verkehr 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
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf.h.
Für allgemeine BPF-Dokumentation lesen Sie bitte
https://www.kernel.org/doc/html/latest/bpf/index.html.

Die Spezifikation eines BPF-Programms besteht aus einem Typ gefolgt von einem
Programmpfad mit einem »:« als Trenner: Typ:Programmpfad.

Typ ist der auch in bpftool verwandte Zeichenkettenname des BFP-Anhängetyps. Typ kann
sein: egress, ingress, sock_create, sock_ops, device, bind4, bind6, connect4,
connect6, post_bind4, post_bind6, sendmsg4, sendmsg6, sysctl, recvmsg4, recvmsg6,
getsockopt, setsockopt.

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

Mehrfache Zuweisungen des gleichen Werts von Typ:Programmpfad haben die gleiche
Auswirkung wie eine einzelne Zuweisung: Das Programm mit dem Pfad Programmpfad wird an
den Cgroup-Hook Typ 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

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
…

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.

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. Unter cgroup-v1 steuert dies das
Control-Gruppen-Attribut »devices.allow«. Für Details über dieses
Control-Gruppen-Attribut siehe Geräte-Positivliste-Controller[9]. In der vereinigten
Cgroup-Hierarchie ist diese Funktionalität 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
…

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

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

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

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

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.

Delegate=
Schaltet die Delegation weiterer Ressourcensteuerungspartitionierung an Prozesse der
Unit ein. Units, bei denen dies aktiviert ist, können ihre eigenen Unterhierarchien
von Control-Gruppen unterhalb der Control-Gruppe der Unit selbst erstellen und
verwalten. Für unprivilegierte Dienste (d.h. solche, die die Einstellung User=
verwenden) wird die Control-Gruppe der Unit für den relevanten Benutzer zugreifbar
gemacht. Wenn aktiviert, wird der Dienstevewalter es unterlassen, die Control-Gruppen
zu verändern oder Prozesse unterhalb der Control-Gruppe der Unit zu schieben, so dass
ein klares Konzept der Eigentümerschaft etabliert ist: der Control-Gruppenbaum
oberhalb der Control-Gruppe der Unit (d.h. in Richtung der Wurzel der Control-Gruppe)
gehört dem Diensteverwalter des Rechners, der sie auch verwaltet, während der
Control-Gruppenbaum unterhalb der Control-Gruppe der Unit der Unit selbst gehört, die
diesen auch verwaltet. Akzeptiert entweder ein logisches Argument oder eine Liste von
Control-Gruppen-Controller-Namen. Falls wahr, wird die Delegierung eingeschaltet und
alle unterstützten Controller werden für die Unit aktiviert und damit den Prozessen
der Unit zur Verwaltung verfügbar gemacht. Falls falsch, wird die Delegation komplett
ausgeschaltet (und keine zusätzlichen Controller werden aktiviert). Falls auf eine
Liste von Controllern gesetzt, wird die Delegation eingeschaltet und die angegebenen
Controller werden für die Unit aktiviert. Beachten Sie, dass abhängig von der
Konfiguration der enthaltenden Unit oder anderen, darin enthaltenen Units zusätzliche
Controller (neben den angegebenen) auch verfügbar gemacht werden könnten. Beachten
Sie, dass die Zuweisung der leeren Zeichenkette die Delegation aktivieren, die Liste
der Controller aber zurücksetzen wird; alle Zuweisungen vorher ohne Wirkung bleiben
werden. 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.

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

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 Kind-Units in die Lage versetzt werden, implizit oder explizit einen
Controller einzuschalten. Standardmäßig werden keine Controller deaktiviert.

Es mag nicht möglich sein, einen Controller erfolgreich zu deaktivieren, 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.

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.

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

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.

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.

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. Zusätzlich wird
systemd-oomd diese erweiterten Attribute ignorieren, falls die Cgroup der Unit nicht
dem Benutzer »root« gehört.

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.

MISSBILLIGTE OPTIONEN

Die folgenden Optionen werden missbilligt. Verwenden Sie stattdessen die angezeigten
Optionen:

CPUShares=Gewicht, StartupCPUShares=Gewicht
Weist dem ausgeführten Prozess die festgelegte CPU-Zeitanteilsgewichtung zu. Diese
Optionen akzeptieren einen Ganzzahlwert und steuern das Control-Gruppenattribut
»cpu.shares«. Der erlaubte Bereich ist 2 bis 262144. Standardmäßig 1024. Für Details
über dieses Control-Gruppen-Attribut siehe CFS-Auftragsplaner[4]. Die verfügbare
CPU-Zeit wird zwischen allen Units innerhalb einer Scheibe relativ zu ihren
CPU-Zeitanteilsgewichtungen aufgeteilt.

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

Impliziert »CPUAccounting=yes«.

Diese Einstellungen sind missbilligt. Verwenden Sie stattdessen CPUWeight= und
StartupCPUWeight=.

MemoryLimit=Byte
Legt die maximale Speicherbegrenzung der ausgeführten Prozesse fest. Die Begrenzung
legt fest, wieviel Prozess- und Kernelspeicher von den Prozessen in dieser Unit
verwandt werden kann. 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. Terabytes (zur Basis 1024) ausgewertet. Alternativ kann ein Prozentwert
festgelegt werden, der relativ zum installierten physischen Speicher im System
akzeptiert wird. Falls zugewiesen, besagt der besondere Wert »infinity«, dass keine
Speicherbegrenzung angewandt wird. Dies steuert das Control-Gruppenattribut
»memory.limit_in_bytes«. Für Details über dieses Control-Gruppenattribut siehe
Speicherressourcen-Controller[11].

Impliziert »MemoryAccounting=yes«.

Diese Einstellung ist missbilligt. Verwenden Sie stattdessen MemoryMax=.

BlockIOAccounting=
Schaltet Block-E/A-Buchführung für diese Unit ein, falls die veraltete
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 DefaultBlockIOAccounting= in systemd-system.conf(5)
gesteuert werden.

Diese Einstellung ist missbilligt. Verwenden Sie stattdessen IOAccounting=.

BlockIOWeight=Gewicht, StartupBlockIOWeight=Gewicht
Setzt die vorgegebene Gesamt-Block-E/A-Gewichtung für die ausgeführten Prozesse, falls
die veraltete Control-Gruppenhierarchie auf dem System verwandt wird. Akzeptiert einen
einzelnen Gewichtungswert (zwischen 10 und 10000), um die vorgegebene
Block-E/A-Gewichtung zu setzen. Dies steuert das Control-Gruppen-Attribut
»blkio.weight«, das standardmäßig 500 beträgt. Für Details über dieses
Control-Gruppen-Attribut, siehe Block-E/A-Controller[12]. Die verfügbare
E/A-Bandbreite wird zwischen allen Units innerhalb einer Scheibe relativ zu ihren
Block-E/A-Gewichtungen aufgeteilt.

Während StartupBlockIOWeight= nur für die Hoch- und Runterfahrphase des Systems gilt,
gilt BlockIOWeight= während der normalen Laufzeit des Systems und falls ersteres nicht
gesetzt ist, auch für die Hoch- und Runterfahrphasen. Dies erlaubt eine abweichende
Priorisierung bestimmter Dienste während des Hoch- und Runterfahrens des Systems im
Vergleich zur normalen Laufzeit.

Impliziert »BlockIOAccounting=yes«.

Diese Einstellungen sind missbilligt. Verwenden Sie stattdessen IOWeight= und
StartupIOWeight=.

BlockIODeviceWeight=Gerät Gewicht
Setzt die geräteabhängige Gesamt-Block-E/A-Gewichtung für die ausgeführten Prozesse,
falls die veraltete Control-Gruppenhierarchie auf dem System verwandt wird. Akzeptiert
eine Leerzeichen-getrennte Liste von Paaren von einem Dateipfad und einem
Gewichtungswert, um den geräteabhängigen Gewichtungswert, zwischen 10 und 1000,
festzulegen. (Beispiel: »/dev/sda 500«). 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 »blkio.weight_device«, das standardmäßig 1000 beträgt.
Verwenden Sie die Option mehrfach, um Gewichtungen für mehrere Geräte zu setzen. Für
Details über dieses Control-Gruppen-Attribut, siehe Block-E/A-Controller[12].

Impliziert »BlockIOAccounting=yes«.

Diese Einstellung ist missbilligt. Verwenden Sie stattdessen IODeviceWeight=.

BlockIOReadBandwidth=Gerät Byte, BlockIOWriteBandwidth=Gerät Byte
Setzt die gerätebezogene Gesamt-Block-E/A-Bandbreitenbegrenzung für den ausgeführten
Prozess, falls die veraltete Control-Gruppenhierarchie auf dem System verwandt wird.
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 die Control-Gruppen-Attribute »blkio.throttle.read_bps_device« und
»blkio.throttle.write_bps_device«. Verwenden Sie diese Option mehrfach, um
Bandbreitenbegrenzungen für mehrere Geräte zu setzen. Für Details über dieses
Control-Gruppen-Attribut siehe Block-E/A-Controller[12].

Impliziert »BlockIOAccounting=yes«.

Diese Einstellungen sind missbilligt. Verwenden Sie stattdessen IOReadBandwidthMax=
und IOWriteBandwidthMax=.

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://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

        3. Control-Gruppen Version 1
           https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/

        4. CFS-Scheduler
           https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html

        5. sched-bwc.txt
           https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt

        6. Speicherschnittstellen-Dateien
           https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-files

        7. Prozessanzahl-Controller
           https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/pids.html

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

        9. Geräte-Positivliste-Controller
           https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/devices.html

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

       11. Speicherressourcen-Controller
           https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/memory.html

       12. Block-E/A-Controller
           https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/blkio-controller.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⟩.