Provided by: manpages-de_2.16-1_all bug

BEZEICHNUNG

       systemd.resource-control - Resourcensteuerungs-Unit-Einstellungen

ÜBERSICHT

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

BESCHREIBUNG

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

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

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

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

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