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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Diese Einstellung ersetzt MemoryLimit=.

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

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

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

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

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.

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

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

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

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

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

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

Impliziert »IOAccounting=yes«.

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

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

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.

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

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

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

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

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

Tabelle 1. Besondere Adress-/Netzwerknamen

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.

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

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

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.

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

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

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

...
[Unit]
Wants=modprobe@loop.service
After=modprobe@loop.service
[Service]
DeviceAllow=block-loop
DeviceAllow=/dev/loop-control
…

strict

closed

auto

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.

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

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

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

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

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

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

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

Wird dies auf kill gesetzt, dann wird systemd-oomd aktiv die Cgroup-Metriken dieser Unit überwachen, um zu entscheiden, ob es handeln muss. Falls die Cgroup die durch oomd.conf(5) oder seine Außerkraftsetzungen gesetzten Beschränkungen überschreitet, wird systemd-oomd ein SIGKILL an alle Prozesse unter der ausgewählten Kandidaten-Cgroup senden. Beachten Sie, dass nur Nachfahr-Cgroups als Kandidaten zum Töten in Frage kommen; die Unit, die ihre Eigenschaft auf kill setzt, ist kein Kandidat (außer einer ihrer Vorfahren setzt seine Eigenschaft auf kill). Weitere Details über Kandidaten und ihr Tötungs-Verhalten können Sie in systemd-oomd.service(8) und oomd.conf(5) finden. Wird eine dieser Eigenschaften auf kill und DefaultDependencies nicht auf no gesetzt, dann wird auch automatisch eine Abhängigkeit After= und Wants= auf systemd-oomd.service erlangt.

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

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

Impliziert »MemoryAccounting=yes«.

Diese Einstellung ist missbilligt. Verwenden Sie stattdessen MemoryMax=.

Diese Einstellung ist missbilligt. Verwenden Sie stattdessen IOAccounting=.

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

Impliziert »BlockIOAccounting=yes«.

Diese Einstellung ist missbilligt. Verwenden Sie stattdessen IODeviceWeight=.

Impliziert »BlockIOAccounting=yes«.

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