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.

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 cgroup-v2.txt[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.

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

IO
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-Ressourcensteeurung 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 cgroups.txt[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 Systemd-Benutzerinstanzen
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 cgroup-v2.txt[2] und
sched-design-CFS.txt[4]. Die verfügbare CPU-Zeit wird zwischen allen Units innerhalb einer Scheibe
relativ zu ihrer CPU-Zeitgewichtung aufgeteilt.

Während StartupCPUWeight= nur für die Hochfahrphase des Systems gilt, gilt CPUWeight= während der
normalen Laufzeit des Systems und falls ersteres nicht gesetzt ist, auch für die Hochfahrphase. Durch
Verwendung von StartupCPUWeight= ist eine abweichende Priorisierung bestimmter Dienste während des
Hochfahrens 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 legt fest, 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 cgroup-v2.txt[2] und sched-bwc.txt[5].

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-Quota 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
Quota-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
cgroup-v2.txt[2] und sched-design-CFS.txt[4].

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

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
Legt den Speicherbenutzungsschutz für die in dieser Unit ausgeführten Prozesse fest. Falls der
Speicherverbrauch dieser Unit und sämtlicher seiner Nachkommen unter der minimalen Grenze sind, wird
der Speicher dieser Unit nicht zurückgefordert.

Akzeptiert eine Speichergröße in Byte. Falls dem Wert K, M, G oder T angehängt wird, wird die
festgelegte Speichergröße in Kilobyte, Megabyte, Gigabyte bzw. Terabyte (mit der 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«. Für Details
über dieses Control-Gruppen-Attribut, siehe cgroup-v2.txt[2].

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

Durch Angabe von DefaultMemoryMin= (hat die gleiche Semantik wie MemoryMin=) können Units ihren
Kindern einen Vorgabewert für »memory.min« verwenden lassen. Diese Einstellung beeinflusst nicht
»memory.min« in der Unit selbst.

MemoryLow=Byte
Legt fest, dass der Speicherbenutzungsschutz für die in dieser Unit ausgeführten Prozesse mit
größtmöglichem Aufwand realisiert werden soll. Falls der Speicherverbrauch dieser Unit und sämtlicher
seiner Nachkommen unter der unteren Grenze sind, wird der Speicher dieser Unit nicht zurückgefordert,
solange Speicher noch nicht geschützter Units zurückgefordert werden kann.

Akzeptiert eine Speichergröße in Byte. Falls dem Wert K, M, G oder T angehängt wird, wird die
festgelegte Speichergröße in Kilobyte, Megabyte, Gigabyte bzw. Terabyte (mit der 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.low«. Für Details
über dieses Control-Gruppen-Attribut, siehe cgroup-v2.txt[2].

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

Durch Angabe von DefaultMemoryLow= (hat die gleiche Semantik wie MemoryLow=) können Units ihren
Kindern einen Vorgabewert für »memory.low« verwenden lassen. Diese Einstellung beeinflusst nicht
»memory.low« in der Unit selbst.

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
festgelegte Speichergröße in Kilobyte, Megabyte, Gigabyte bzw. Terabyte (mit der 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 cgroup-v2.txt[2].

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
festgelegte Speichergröße in Kilobyte, Megabyte, Gigabyte bzw. Terabyte (mit der 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 cgroup-v2.txt[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
festgelegte Speichergröße in Kilobyte, Megabyte, Gigabyte bzw. Terabyte (mit der 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 cgroup-v2.txt[2].

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
pids.txt[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 cgroup-v2.txt[2]. Die verfügbare E/A-Bandbreite wird zwischen allen
Units innerhalb einer Scheibe relativ zu ihrer Block-E/A-Gewichtung aufgeteilt.

Während StartupIOWeight= nur in der Hochfahrphase des Systems angewandt wird, wird IOWeight= später
zur Laufzeit des Systems angewandt und falls erstere nicht gesetzt ist, auch während der
Hochfahrphase. Dies erlaubt es, bestimmte Dienste beim Hochfahren 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 festgelegt 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
cgroup-v2.txt[2].

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

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 festgelegt 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 cgroup-v2.txt[2].

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

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 festgelegt 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 cgroup-v2.txt[2].

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

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 festgelegt 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 cgroup-v2.txt[2].

Impliziert »IOAccounting=yes«.

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

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 anhand des Adressbereichs 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 (getrennt durch das Zeichen »/«) angehängt werden. Falls Letztere entfällt,
wird die Adresse als Rechneradresse betrachtet, d.h. der Präfix deckt die gesamte Adresse ab (32 für
IPv4, 128 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 alle 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.
Wenn konfiguriert, werden die Listen wie folgt durchgesetzt:

• Falls die Ziel-/Quelladresse eines IP-Pakets auf einen Eintrag in der Einstellung IPAddressAllow=
passt, wird der Zugriff erlaubt.

• Falls seine Ziel-/Quelladresse auf einen Eintrag in der Einstellung 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, allerdings ergibt es
oft Sinn, 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 festgelegten
Listen kombiniert. Falls diesen Einstellungen eine leere Zeichenkette zugewiesen wird, werden die
festgelegten 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_PROGRAMM_PATH, IPEgressFilterPath=BPF_FS_PROGRAMM_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 festgelegten
Programme angehängt. Falls diesen Einstellungen eine leere Zeichenkette zugewiesen wird, wird die
Programmliste zurückgesetzt und alle vorher festgelegten Programme ignoriert.

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.

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 devices.txt[7]. Unter cgroup-v2 ist diese Funktionalität
mittels eBPF-Filterung implementiert.

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 Zeile »ExecStartPre=/sbin/modprobe…« ergänzen, die die notwendigen
Kernelmodule lädt, die die Gerätegruppe implementieren, falls sie fehlen. Beispiel:

\[u2026]
[Service]
ExecStartPre=-/sbin/modprobe -abq loop
DeviceAllow=block-loop
DeviceAllow=/dev/loop-control
\[u2026]

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 festgelegten 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 festgelegten) 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 festgelegten 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, io, blkio, memory, devices,
pids. 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[8] 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.

Gültige Controller sind cpu, cpuacct, io, blkio, memory, devices und pids.

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
sched-design-CFS.txt[4]. Die verfügbare CPU-Zeit wird zwischen allen Units innerhalb einer Scheibe
relativ zu ihren CPU-Zeitanteilsgewichtungen aufgeteilt.

Während StartupCPUShares= nur für die Hochfahrphase des Systems gilt, gilt CPUShares= während der
normalen Laufzeit des Systems und falls ersteres nicht gesetzt ist, auch für die Hochfahrphase. Durch
Verwendung von StartupCPUShares= ist eine abweichende Priorisierung bestimmter Dienste während des
Hochfahrens 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 festgelegte
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 memory.txt[9].

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 blkio-controller.txt[10]. 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 Hochfahrphase des Systems gilt, gilt BlockIOWeight= während
der normalen Laufzeit des Systems und falls ersteres nicht gesetzt ist, auch für die Hochfahrphase.
Dies erlaubt eine abweichende Priorisierung bestimmter Dienste während des Hochfahrens 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 festgelegt 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 blkio-controller.txt[10].

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 festgelegt 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 blkio-controller.txt[10].

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), Die Dokumentation für Control-Gruppen und bestimmte Controller
       im Linux-Kernel: cgroups.txt[3], cpuacct.txt[11], memory.txt[9], blkio-controller.txt[10],
       sched-bwc.txt[5].

ANMERKUNGEN

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

        2. cgroup-v2.txt
           https://www.kernel.org/doc/Documentation/cgroup-v2.txt

        3. cgroups.txt
           https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt

        4. sched-design-CFS.txt
           https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt

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

        6. pids.txt
           https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt

        7. devices.txt
           https://www.kernel.org/doc/Documentation/cgroup-v1/devices.txt

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

        9. memory.txt
           https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

       10. blkio-controller.txt
           https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt

       11. cpuacct.txt
           https://www.kernel.org/doc/Documentation/cgroup-v1/cpuacct.txt

Ü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 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
       <debian-l10n-german@lists.debian.org>.

systemd 243                                                                          SYSTEMD.RESOURCE-CONTROL(5)