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

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

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

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

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.

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.

Weist das festgelegte CPU-Zeitgewicht den ausgeführten Prozessen zu, falls die vereinigte Control-Group-Hierarchie 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-Group-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 ihrem CPU-Zeitgewicht 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.

Impliziert »CPUAccounting=true«.

Diese Einstellungen ersetzen CPUShares= und StartupCPUShares=.

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-Group-Hierarchie und »cpu.max« auf der alten. Für Details über dieses Control-Group-Attribute siehe cgroup-v2.txt[2] und sched-design-CFS.txt[4].

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

Impliziert »CPUAccounting=true«.

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.

Legt den größtaufwandsmöglichen Speicherbenutzungsschutz für die in dieser Unit ausgeführten Prozesse fest. 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. Dies steuert das Control-Gruppen-Attribut »memory.low«. Für Details über dieses Control-Gruppen-Attribut, siehe cgroup-v2.txt[2].

Impliziert »MemoryAccounting=true«.

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

Legt die obere 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 Speicherbegrenzung angewandt. Dies steuert das Control-Gruppen-Attribut »memory.high«. Für Details über dieses Control-Gruppen-Attribut, siehe cgroup-v2.txt[2].

Impliziert »MemoryAccounting=true«.

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

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].

Impliziert »MemoryAccounting=true«.

Diese Einstellung ersetzt MemoryLimit=.

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].

Impliziert »MemoryAccounting=true«.

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

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.

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[5].

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

Schaltet Block-E/A-Buchführung für diese Unit ein, falls die vereinigte Control-Gruppen-Hierarchie 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.

Setzt das Vorgabe-Gesamt-Block-E/A-Gewicht für die ausgeführten Prozesse, falls die vereinigte Control-Gruppen-Hierarchie auf dem System verwandt wird. Akzeptiert einen einzelnen Gewichtswert (zwischen 1 und 10000), um das Vorgabe-Block-E/A-Gewicht 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 ihrem Block-E/A-Gewicht 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.

Impliziert »IOAccounting=true«.

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

Setzt das gerätebezogene Gesamt-Block-E/A-Gewicht für den ausgeführten Prozess, falls die vereinigte Control-Gruppen-Hiererachie auf dem System verwandt wird. Akzeptiert ein Leerzeichen getrenntes Paar eines Dateipfades und eines Gewichtwertes, um den gerätespezifischen Gewichtswert 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 Gewichte für mehrere Geräte zu setzen. Für Details über dieses Control-Gruppen-Attribut siehe cgroup-v2.txt[2].

Impliziert »IOAccounting=true«.

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

Setzt die gerätebezogene maximale Gesamt-Block-E/A-Bandbreitebegrenzung für den ausgeführten Prozess, falls die vereinigte Control-Gruppen-Hierarchie 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 diese Control-Gruppen-Attribut siehe cgroup-v2.txt[2].

Impliziert »IOAccounting=true«.

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

Setzt die gerätebezogene maximale Gesamt-Block-E/A-EA-Pro-Sekunden-Begrenzung für den ausgeführten Prozess, falls die vereinigte Control-Gruppen-Hierarchie 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 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 diese Control-Gruppen-Attribut siehe cgroup-v2.txt[2].

Impliziert »IOAccounting=true«.

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

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 Proezsse 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.

Schaltet Adressbereichnetzwerkverkehrsfilterung für Pakete, die über AF_INET- und AF_INET6-Sockets gesandt oder empfangen werden, ein. Beide Anweisungen akzeptieren ein Leerzeichen getrennte Liste von IPv4- oder IPv6-Adressen, an jede kann optional eine Adresspräfixlänge (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. Wenn konfiguriert, werden die Listen wie folgt durchgesetzt:

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, das 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 eine leere Zeichenkette diesen Einstellungen zugewiesen wird, werden die festgelegten Zugriffslisten zurückgesetzt und alle vorherigen Einstellungen aufgehoben.

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

Tabelle 1. Besondere Adress-/Netzwerknamen

Symbolic Name	Definition	Meaning
any	0.0.0.0/0 ::/0	Any host
localhost	127.0.0.0/8 ::1/128	All addresses on the local loopback
link-local	169.254.0.0/16 fe80::/64	All link-local IP addresses
multicast	224.0.0.0/4 ff00::/8	All IP multicasting addresses

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.

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. Dies steuert die Control-Gruppen-Attribute »devices.allow« und »devices.deny«. Für Details über diese Control-Gruppen-Attribute siehe devices.txt[6].

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. 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ätegruppn mit CPU-Bezug passt.

Steuert die Richtlinien zum Erlauben von Gerätezugriff:

strict

closed

auto

Der Name der Scheiben-Unit, in der 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-Unit 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 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 sollte walten gelassen werden, wenn sich auf die Vorgabe-Scheibenzuweisung in vorlagenbasierten Dienste-Units, die DefaultDependencies=no gesetzt haben, verlassen wird, siehe systemd.service(5) Abschnitt »Standardabhängigkeiten« für Details.

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 unprivilegiert Dienste (d.h. solchen, 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 der 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.

Bechten Sie, dass Controller-Delegation an weniger privilegierten Code nur auf der vereinigten Control-Gruppen-Hierarchie 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.

Weist dem asugeführten Prozess das festgelegten CPU-Zeitanteilsgewicht 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-Zeitanteilsgewichten 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=true«.

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

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[7].

Impliziert »MemoryAccounting=true«.

Diese Einstellung ist missbilligt. Verwenden Sie stattdessen MemoryMax=.

Schaltet Block-E/A-Buchführung für diese Unit ein, falls die veraltete Control-Gruppen-Hierarchie 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=.

Setzt das Vorgabe-Gesamt-Block-E/A-Gewicht für die ausgeführten Prozesse, falls die veraltete Control-Gruppen-Hierarchie auf dem System verwandt wird. Akzeptiert einen einzelnen Gewichtswert (zwischen 10 und 10000), um das Vorgabe-Block-E/A-Gewicht 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[2]. Die verfügbare E/A-Bandbreite wird zwischen allen Units innerhalb einer Scheibe relativ zu ihrem Block-E/A-Gewicht 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=true«.

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

Setzt das geräteabhängige Gesamt-Block-E/A-Gewicht für die ausgeführten Prozesse, falls die veraltete Control-Gruppen-Hierarchie auf dem System verwandt wird. Akzeptiert eine Leerzeichen-getrennte Liste von Paaren von einem Dateipfad und einem Gewichtswert, um den geräteabhängigen Gewichtswert, 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 Gewichte für mehrere Geräte zu setzen. Für Details über dieses Control-Gruppen-Attribut, siehe blkio-controller.txt[2].

Impliziert »BlockIOAccounting=true«.

Diese Einstellung ist missbilligt. Verwenden Sie stattdessen IODeviceWeight=.

Setzt die gerätebezogene Gesamt-Block-E/A-Bandbreitebegrenzung für den ausgeführten Prozess, falls die veraltete Control-Gruppen-Hierarchie 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 diese Control-Gruppen-Attribut siehe blkio-controller.txt[8].

Impliziert »BlockIOAccounting=true«.

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