SYSTEMD.RESOURCE-CONTROL(5) systemd.resource-control BEZEICHNUNG systemd.resource-control - Resourcensteuerungs-Unit-Einstellungen UBERSICHT Scheibe.slice, Bereich.scope, Dienst.service, Socket.socket, Einhangung.mount, Swap.swap BESCHREIBUNG Unit-Konfigurationsdateien fur Dienste, Scheiben, Bereiche, Sockets, Einhangepunkte und Swap-Gerate nutzen eine Teilmenge der Konfigurationsoptionen fur die Ressourcensteuerung von erzeugten Prozessen gemeinsam. Intern verlasst 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) fur 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) fur weitere Informationen uber die speziellen Unit-Konfigurationsdateien. Die Ressourcensteuerungskonfigurationsoptionen werden in den Abschnitten [Slice], [Scope], [Service], [Socket], [Mount] oder [Swap], abhangig vom Unit-Typ, konfiguriert. Zusatzlich werden Optionen, die die verfugbaren Ressourcen der von Systemd gestarteten Programme steuern, in systemd.exec(5) aufgefuhrt. Diese Optionen erganzen die hier aufgefuhrten Optionen. Controller aktivieren oder deaktivieren Controller in der Cgroup-Hierarchie sind hierarchisch und die Ressourcensteuerung wird uber verteilte Ressourcenzuweisungen zwischen Geschwistern in Zweigen der Cgroup-Hierarchie realisiert. Es besteht keine Notwendigkeit, einen Cgroup-Controller fur eine Unit explizit zu aktivieren. systemd wird den Kernel anweisen, einen Controller fur eine angegebene Unit zu aktivieren, wenn diese Unit uber eine Konfiguration fur einen angegebenen Controller verfugt. Wenn beispielsweise CPUWeight= gesetzt ist, wird der Controller cpu aktiviert und wenn TasksMax= gesetzt ist, wird der Controller pids aktiviert. Zusatzlich konnen verschiedene Controller auch uber explizite Einstellungen MemoryAccounting=/TasksAccounting=/IOAccounting= aktiviert werden. Aufgrund der Arbeitsweise der Cgroup-Hierarchie werden Controller fur alle Eltern-Units und fur alle Geschwister-Units, beginnend bei der niedrigsten Stufe, auf der der Controller aktiviert ist, aktiviert werden. Units, fur die ein Controller aktiviert ist, konnen der Ressourcensteuerung unterliegen, selbst falls sie selbst uber keine explizite Konfiguration verfugen. Setzen von Delegate= aktiviert alle delegierten Controller fur diese Unit (siehe unten). Die Delegierten konnen dann nach Bedarf Controller fur ihre Kinder aktivieren. Falls insbesondere der Delegierte systemd ist (in der Unit user@.service), wird er die gleiche Logik wie die Systeminstanz wiederholen und Controller fur Units aktivieren, bei denen Ressourcenbeschrankungen konfiguriert wurden, sowie deren Geschwistern und Eltern und den Geschwistern der Eltern. Controller konnen fur Teile der Cgroup-Hierarchie mit DisableControllers= deaktiviert werden (siehe unten). Beispiel 1. Controller aktivieren und deaktivieren -.slice / \ /-----/ \--------------\ / \ system.slice user.slice / \ / \ / \ / \ / \ user@42.service user@1000.service / \ Delegate= Delegate=yes a.service b.slice / \ CPUWeight=20 DisableControllers=cpu / \ / \ app.slice session.slice / \ CPUWeight=100 CPUWeight=100 / \ b1.service b2.service CPUWeight=1000 In dieser Hierarchie ist der Controller cpu fur alle angezeigten Units ausser b1.service und b2.service aktiviert. Da es keine explizite Konfiguration fur system.slice und user.slice gibt, werden die CPU-Ressourcen zwischen ihnen gleichmassig aufgeteilt. Ahnlich werden Ressourcen zwischen den Kindern von user.slice und zwischen der Kind-Scheibe unterhalb von user@1000.service aufgeteilt. Unter der Annahme, dass es keine weitere Konfiguration der Ressourcen oder Delegationen unterhalb der Scheibe app.slice oder session.slice gibt, wurde der Controller cpu nicht fur Units in diesen Scheiben aktiviert und CPU-Ressourcen wurden weiter mittels anderer Mechanismen, z.B. basierend auf den Nice-Stufen, zugewiesen. Der Verwalter fur Benutzer 42 hat Delegation ohne Controller aktiviert, d.h. er kann seinen Unterbaum der Cgroup-Hierarchie verandern, aber ohne Ressourcensteuerung. In der Scheibe system.slice werden die CPU-Ressourcen 1:6 auf Dienst a.service und 5:6 auf Scheibe b.slice aufgeteilt, da Scheibe b.slice den Vorgabewert von 100 fur cpu.weight erhalt, wenn CPUWeight= nicht gesetzt ist. Die Einstellung CPUWeight= in b2.service wird durch DisableControllers= in Scheibe b.slice neutralisiert, so dass der Controller cpu fur die Dienste b1.service und b2.service nicht aktiviert wurde und CPU-Ressourcen weiter mittels anderer Mechanismen, z.B. basierend auf den Nice-Stufen, zugewiesen wurden. Ressourcensteuerungen fur eine Cgroup zugehoriger Units setzen Wie in systemd.unit(5) beschrieben, konnen die hier aufgefuhrten Einstellungen uber die Hauptkonfigurationsdatei einer Unit und Erganzungsschnipsel in *.d/-Verzeichnissen gesetzt werden. Die Liste der nach Erganzungen durchsuchten Verzeichnisse enthalt Namen, die durch wiederholtes Abschneiden des Units-Namens nach allen Gedankenstrichen geformt werden. Dies ist insbesondere praktisch, um Ressourcenbegrenzungen fur eine Gruppe von Units mit ahnlichen Namen zu setzen. Beispielsweise erhalt jeder Benutzer seine eigene Scheibe user-nnn.slice. Erganzungen mit lokaler Konfiguration, die Benutzer 1000 betreffen, konnen in /etc/systemd/system/user-1000.slice, /etc/systemd/system/user-1000.slice.d/*.conf, aber auch in /etc/systemd/system/user-.slice.d/*.conf abgelegt werden. Das letzte Verzeichnis gilt fur alle Benutzer-Scheiben. Siehe die Neue Control-Gruppen-Schnittstellen[1] fur eine Einfuhrung, wie die Ressourcensteuerungs-APIs von Programmen genutzt werden konnen. IMPLIZITE ABHANGIGKEITEN Die folgenden Abhangigkeiten werden implizit hinzugefugt: o Units mit der gesetzten Einstellung Slice= erlangen automatisch Requires=- und After=-Abhangigkeiten auf die festgelegte Scheiben-Unit. OPTIONEN Units der oben aufgefuhrten Typen konnen Einstellungen fur die Ressourcensteuerungskonfiguration haben: CPU-Buchfuhrung und -Steuerung CPUAccounting= Schaltet die Buchfuhrung fur die CPU-Benutzung fur diese Unit ein. Akzeptiert ein logisches Argument. Beachten Sie, dass das Einschalten der CPU-Buchfuhrung in einer Unit implizit die Buchfuhrung fur alle Units in der gleichen Scheibe und fur alle ihre Eltern-Scheiben und die darin enthaltenen Units einschaltet. Die Systemvorgabe fur diese Einstellung kann mit DefaultCPUAccounting= in systemd-system.conf(5) gesteuert werden. Unter der vereinigten Cgroup-Hierarchie ist die CPU-Buchfuhrung fur alle Units verfugbar und diese Einstellung hat keine Auswirkung. Hinzugefugt in Version 208. CPUWeight=Gewicht, StartupCPUWeight=Gewicht Diese Einstellungen steuern den Controller cpu in der vereinigten Hierarchie. Diese Optionen akzeptieren einen Ganzzahlwert oder die besondere Zeichenkette >>idle<<: o Weist, falls auf einen Ganzzahlwert gesetzt, die festgelegte CPU-Zeitgewichtung den ausgefuhrten Prozessen zu, falls die vereinigte Control-Gruppenhierarchie auf dem System verwandt wird. Diese Optionen steuern das Control-Group-Attribut >>cpu.weight<<. Der erlaubte Bereich ist 1 bis 10000. Standardmassig nicht gesetzt, aber die Vorgabe des Kernels ist 100. Fur Details uber dieses Control-Gruppen-Attribut siehe Control-Gruppen v2[2] und CFS-Auftragsplaner[3]. Die verfugbare CPU-Zeit wird zwischen allen Units innerhalb einer Scheibe relativ zu ihrer CPU-Zeitgewichtung aufgeteilt. Ein hoheres Gewicht bedeutet mehr CPU-Zeit, ein geringeres Gewicht weniger. o Falls sie auf die besondere Zeichenkette >>idle<< gesetzt wird, dann wird die Cgroup fur >>idle scheduling<< (Leerlauf-Auftragsplanung) markiert. Das bedeutet, dass sie nur CPU-Ressourcen bekommt, wenn es keine Prozesse gibt, die nicht so markiert sind, die in dieser Cgroup oder seinen Geschwistern ausgefuhrt werden. Diese Einstellung entspricht dem Cgroup-Attribut >>cpu.idle<<. Beachten Sie, dass dieser Wert nur bei Cgroup-V2 eine Auswirkung hat, bei Cgroup-V1 ist sie aquivalent zu der Minimalgewichtung. Wahrend StartupCPUWeight= fur die Hoch- und Runterfahrphase des Systems gilt, gilt CPUWeight= wahrend der normalen Laufzeit des Systems und falls ersteres nicht gesetzt ist, auch fur die Hoch- und Runterfahrphasen. Durch Verwendung von StartupCPUWeight= ist eine abweichende Priorisierung bestimmter Dienste wahrend des Hoch- und Runterfahrens des Systems im Vergleich zur normalen Laufzeit moglich. Zusatzlich zu der durch den Controller cpu durchgefuhrten Ressourcenbelegung kann der Kernel automatisch Ressourcen basierend auf der Sitzungskennungsgruppierung verteilen, siehe >>The autogroup feature<< in sched(7). Die Auswirkung dieser Funktionalitat ist ahnlich des Controllers cpu ohne explizite Konfiguration, daher sollten Benutzer vorsichtig sein, nicht beide durcheinander zu bringen. Hinzugefugt in Version 232. CPUQuota= Diese Einstellung steuert den Controller cpu in der vereinigten Hierarchie. Weist die festgelegte CPU-Zeitquote den ausgefuhrten Prozessen zu. Akzeptiert einen Prozentwert, dem >>%<< angehangt ist. Der Prozentwert gibt an, wieviel CPU-Zeit die Unit maximal erhalten soll, relativ zu der gesamten CPU-Zeit, die auf einer CPU verfugbar 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. Fur Details uber dieses Control-Gruppen-Attribut siehe Control-Gruppen v2[2] und CFS-Bandweitensteuerung[4]. Durch Setzen von CPUQuota= auf einen leeren Wert wird keine Quote gesetzt. Beispiel: CPUQuota=20% stellt sicher, dass der ausgefuhrte Prozess niemals mehr als 20% CPU-Zeit auf einer CPU erhalt. Hinzugefugt in Version 213. CPUQuotaPeriodSec= Diese Einstellung steuert den Controller cpu in der vereinigten Hierarchie. Weist die Dauer zu, uber den die durch CPUQuota= festgelegte CPU-Zeit-Kontingent gemessen wird. Akzeptiert einen Zeitdauerwert in Sekunden mit einer optionalen Endung wie >>ms<< fur Millisekunden (oder >>s<< fur Sekunden). Die Voreinstellung ist 100 ms. Die Periode wird an den durch den Kernel unterstutzten Bereich, der [1ms, 1000ms] ist, befestigt. Zusatzlich wird die Periode angepasst, so dass das Kontingent-Intervall auch mindestens 1 ms ist. Wird CPUQuotaPeriodSec= auf einen leeren Wert gesetzt, so wird er auf die Vorgabe zuruckgesetzt. Dies steuert das zweite Feld des Attributs >>cpu.max<< der vereinigten Control-Gruppenhierarchie und >>cpu.cfs_period_us<< auf der alten. Fur Details uber dieses Control-Gruppen-Attribut siehe Control-Gruppen v2[2] und CFS-Auftragsplaner[3]. Beispiel: Mit CPUQuotaPeriodSec=10ms wird erbeten, das CPU-Kontingent in Perioden von 10 ms zu messen. Hinzugefugt in Version 242. AllowedCPUs=, StartupAllowedCPUs= Diese Einstellung steuert den Controller cpuset in der vereinigten Hierarchie. Beschrankt die Ausfuhrung von Prozessen auf bestimmte CPUs. Akzeptiert eine Liste von CPU-Indicies oder -Bereichen, getrennt durch Leerraum oder Kommata. CPU-Bereiche werden durch den unteren und oberen CPU-Index, getrennt durch einen Bindestrich, angegeben. Setzen von AllowedCPUs= oder StartupAllowedCPUs= garantiert nicht, dass samtliche CPUs von den Prozessen verwandt werden, da es durch Eltern-Units eingeschrankt sein konnte. Die wirksame Konfiguration wird durch EffectiveCPUs= berichtet. Wahrend StartupAllowedCPU= nur fur die Hoch- und Runterfahrphasen des Systems gelten, gilt AllowedCPUs= wahrend der normalen Laufzeit des Systems und falls ersteres nicht gesetzt ist, auch fur die Hoch- und Runterfahrphasen. Durch Verwendung von StartupAllowedCPUs= ist eine abweichende Priorisierung bestimmter Dienste wahrend des Hoch- und Runterfahrens des Systems im Vergleich zur normalen Laufzeit moglich. Diese Einstellung wird nur mit der vereinigten Control-Gruppenhierarchie unterstutzt. Hinzugefugt in Version 244. Speicher-Buchfuhrung und -Steuerung MemoryAccounting= Diese Einstellung steuert den Controller memory in der vereinigten Hierarchie. Schaltet Prozess- und Kernelspeicherbuchfuhrung fur diese Unit ein. Akzeptiert ein logisches Argument. Beachten Sie, dass das Einschalten der Speicherbuchfuhrung in einer Unit implizit die Buchfuhrung fur alle Units in der gleichen Scheibe und fur alle ihre Eltern-Scheiben und die darin enthaltenen Units einschaltet. Die Systemvorgabe fur diese Einstellung kann mit DefaultMemoryAccounting= in systemd-system.conf(5) gesteuert werden. Hinzugefugt in Version 208. MemoryMin=Byte, MemoryLow=Byte, StartupMemoryLow=Byte, DefaultStartupMemoryLow=Byte Diese Einstellungen steuern den Controller memory in der vereinigten Hierarchie. Legt den Speicherverwendungsschutz fur die ausgefuhrten Prozesse in dieser Unit fest. Wenn Speicher zuruckgewonnen wird, dann wird diese Unit so behandelt, als ob sie weniger Speicher verwenden wurde, was dazu fuhrt, dass Speicher bevorzugt von nicht geschutzten Units zuruckgewonnen wird. Die Verwendung von MemoryLow= fuhrt zu einem schwacheren Schutz, bei dem Speicher weiterhin zuruckgewonnen werden kann, um den Aufruf des OOM-Killers zu vermeiden, falls es keinen anderen zuruckgewinnbaren Speicher gibt. Damit ein Schutz wirksam wird, ist es im Allgemeinen notwendig, die entsprechende Zuweisung fur 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 fur einen gemeinsamen Schutz fur alle Kinder verwandt. Da dies ein gemeinsamer Schutz ist, konkurrieren die Kinder frei um den Speicher. Akzeptiert eine Speichergrosse in Byte. Falls dem Wert K, M, G oder T angehangt wird, wird die angegebene Speichergrosse 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 samtlicher Speicher geschutzt. Dies kann nutzlich sein, um immer samtlichen, bei den Vorgangern aufgewandten Schutz zu erben. Dies steuert das Control-Gruppen-Attribut >>memory.min<< oder >>memory.low<<. Fur Details uber dieses Control-Gruppen-Attribut, siehe Speicherschnittstellen-Dateien[5]. Durch Angabe von DefaultMemoryMin= oder DefaultMemoryLow= (hat die gleiche Semantik wie MemoryMin= und MemoryLow=) oder DefaultStartupMemoryLow= (hat die gleiche Semantik wie StartupMemoryLow=) konnen Units ihren Kindern einen Vorgabewert fur >>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 nutzlich, die die Cgroup2-Einhangeoption >>memory_recursiveprot<< nicht unterstutzen. Wahrend StartupMemoryLow= fur die Hoch- und Runterfahrphasen des Systems gilt, gilt MemoryMin= wahrend der normalen Laufzeit des Systems und falls ersteres nicht gesetzt ist, auch fur die Hoch- und Runterfahrphasen. Durch Verwendung von StartupMemoryLow= ist eine abweichende Priorisierung bestimmter Dienste wahrend des Hoch- und Runterfahrens des Systems im Vergleich zur normalen Laufzeit moglich. Hinzugefugt in Version 240. MemoryHigh=Byte, StartupMemoryHigh=Byte Diese Einstellungen steuern den Controller memory in der vereinigten Hierarchie. Legt die Drosselungs-Speicherverbrauchsbegrenzung der ausgefuhrten Prozesse in dieser Unit fest. Speicherverbrauch darf diese Begrenzung uberschreiten, falls es unvermeidbar ist, aber die Prozesse werden drastisch verlangsamt und der Speicher wird in solchen Fallen aggressiv fortgenommen. Dies ist der Hauptmechanismus, um den Speicherverbrauch einer Unit zu steuern. Akzeptiert eine Speichergrosse in Byte. Falls dem Wert K, M, G oder T angehangt wird, wird die angegebene Speichergrosse 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<<. Fur Details uber dieses Control-Gruppen-Attribut, siehe Speicherschnittstellen-Dateien[5]. Wahrend StartupMemoryHigh= fur die Hoch- und Runterfahrphase des Systems gilt, gilt MemoryHigh= wahrend der normalen Laufzeit des Systems und falls ersteres nicht gesetzt ist, auch fur die Hoch- und Runterfahrphasen. Durch Verwendung von StartupMemoryHigh= ist eine abweichende Priorisierung bestimmter Dienste wahrend des Hoch- und Runterfahrens des Systems im Vergleich zur normalen Laufzeit moglich. Hinzugefugt in Version 231. MemoryMax=Byte, StartupMemoryMax=Byte Diese Einstellungen steuern den Controller memory in der vereinigten Hierarchie. Legt die absolute Grenze der Speicherverwendung durch den ausgefuhrten 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 Speichergrosse in Byte. Falls dem Wert K, M, G oder T angehangt wird, wird die angegebene Speichergrosse 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<<. Fur Details uber dieses Control-Gruppen-Attribut, siehe Speicherschnittstellen-Dateien[5]. Wahrend StartupMemoryMax= fur die Hoch- und Runterfahrphasen des Systems gilt, gilt MemoryMax= wahrend der normalen Laufzeit des Systems und falls ersteres nicht gesetzt ist, auch fur die Hoch- und Runterfahrphasen. Durch Verwendung von StartupMemoryMax= ist eine abweichende Priorisierung bestimmter Dienste wahrend des Hoch- und Runterfahrens des Systems im Vergleich zur normalen Laufzeit moglich. Hinzugefugt in Version 231. MemorySwapMax=Byte, StartupMemorySwapMax=Byte Diese Einstellungen steuern den Controller memory in der vereinigten Hierarchie. Legt die absolute Begrenzung bezuglich Auslagerungsverwendung von in dieser Unit ausgefuhrten Prozessen fest. Akzeptiert eine Auslagerungsgrosse in Byte. Falls dem Wert K, M, G oder T angehangt wird, wird die angegebene Speichergrosse in Kilobyte, Megabyte, Gigabyte bzw. Terabyte (zur Basis 1024) ausgewertet. Falls der besondere Wert >>infinity<< zugewiesen wird, wird keine Auslagerungsbegrenzung angewandt. Diese Einstellungen steuern das Control-Gruppen-Attribut >>memory.swap.max<<. Fur Details uber dieses Control-Gruppen-Attribut, siehe Speicherschnittstellen-Dateien[5]. Wahrend StartupMemorySwapMax= fur die Hoch- und Runterfahrphasen des Systems gilt, gilt MemorySwapMax= wahrend der normalen Laufzeit des Systems und falls ersteres nicht gesetzt ist, auch fur die Hoch- und Runterfahrphasen. Durch Verwendung von StartupMemorySwapMax= ist eine abweichende Priorisierung bestimmter Dienste wahrend des Hoch- und Runterfahrens des Systems im Vergleich zur normalen Laufzeit moglich. Hinzugefugt in Version 232. MemoryZSwapMax=Byte, StartupMemoryZSwapMax=Byte Diese Einstellungen steuern den Controller memory in der vereinigten Hierarchie. Legt die absolute Begrenzung der Verwendung von Zswap der Prozesse in dieser Unit fest. Zswap ist ein leichtgewichtiger Zwischenspeicher fur Auslagerungsseiten. Es akzeptiert Seiten, die gerade ausgelagert werden sollen und versucht sie in einen dynamisch reservierten RAM-basierten Speicherbereich zu komprimieren. Falls die festgelegte Begrenzung erreicht wird, werden keine Eintrage von dieser Unit mehr in dem Bereich gespeichert, bis bestehende Eintrage wieder eingelesen oder auf Platte geschrieben werden. Siehe die Kerneldokumentation fur Zswap[6] fur weitere Details. Akzeptiert eine Grosse in Byte. Falls dem Wert K, M, G oder T angehangt wird, wird die angegebene Grosse in Kilobyte, Megabyte, Gigabyte bzw. Terabyte (zur Basis 1024) ausgewertet. Falls der besondere Wert >>infinity<< zugewiesen wird, wird keine Begrenzung angewandt. Diese Einstellungen steuern das Control-Gruppen-Attribut >>memory.zswap.max<<. Fur Details uber dieses Control-Gruppen-Attribut siehe Speicherschnittstellen-Dateien[5]. Wahrend StartupMemoryZSwapMax= fur die Hoch- und Runterfahrphasen des Systems gilt, gilt MemoryZSwapMax= wahrend der normalen Laufzeit des Systems und falls ersteres nicht gesetzt ist, auch fur die Hoch- und Runterfahrphasen. Durch Verwendung von StartupMemoryZSwapMax= ist eine abweichende Priorisierung bestimmter Dienste wahrend des Hoch- und Runterfahrens des Systems im Vergleich zur normalen Laufzeit moglich. Hinzugefugt in Version 253. AllowedMemoryNodes=, StartupAllowedMemoryNodes= Diese Einstellungen steuern den Controller cpuset in der vereinigten Hierarchie. Beschrankt die Ausfuhrung von Prozessen auf bestimmte Speicher-NUMA-Knoten. Akzeptiert eine Liste von Speicher-NUMA-Knoten oder -Bereichen, getrennt durch Leerraum oder Kommata. Speicher-NUMA-Knotenbereiche werden durch den unteren und oberen NUMA-Knotenindex, getrennt durch einen Bindestrich, angegeben. Setzen von AllowedMemoryNodes oder StartupAllowedMemoryNodes= garantiert nicht, dass samtliche Speicher-NUMA-Knoten von den Prozessen verwandt werden, da es durch Eltern-Units eingeschrankt sein konnte. Die wirksame Konfiguration wird durch EffectiveMemoryNodes= berichtet. Wahrend StartupAllowedMemoryNodes= fur die Hoch- und Runterfahrphasen des Systems gilt, gilt AllowedMemoryNodes= wahrend der normalen Laufzeit des Systems und falls ersteres nicht gesetzt ist, auch fur die Hoch- und Runterfahrphasen. Durch Verwendung von StartupAllowedMemoryNodes= ist eine abweichende Priorisierung bestimmter Dienste wahrend des Hoch- und Runterfahrens des Systems im Vergleich zur normalen Laufzeit moglich. Diese Einstellung wird nur mit der vereinigten Control-Gruppenhierarchie unterstutzt. Hinzugefugt in Version 244. Prozess-Buchfuhrung und -Steuerung TasksAccounting= Diese Einstellung steuert den Controller pids in der vereinigten Hierarchie. Schaltet Prozessbuchfuhrung fur diese Unit ein. Akzeptiert ein logisches Argument. Falls aktiviert, wird der Kernel die Gesamtanzahl der Prozesse in der Unit und ihren Kindern nachverfolgen. Diese Anzahl enthalt sowohl Kernel-Threads als auch Benutzerprozesse, wobei jeder Thread einzeln zahlt. Beachten Sie, dass das Einschalten der Prozessbuchfuhrung fur eine Unit dies implizit auch fur alle Units, die in der gleichen Scheibe enthalten sind und fur alle Elternscheiben und die darin befindlichen Units einschaltet. Die Systemvorgabe fur diese Einstellung kann durch DefaultTasksAccounting= in systemd-system.conf(5) gesteuert werden. Hinzugefugt in Version 227. TasksMax=N Diese Einstellung steuert den Controller pids in der vereinigten Hierarchie. Legt die maximale Anzahl an Prozessen, die in dieser Unit erstellt werden durfen, fest. Dies stellt sicher, dass die Anzahl der Prozesse, fur die die Unit buchfuhrt (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<<. Fur Details uber dieses Control-Gruppen-Attribut siehe PIDs-Controller[7]. Die Systemvorgabe fur diese Einstellung kann mit DefaultTasksMax= in systemd-system.conf(5) gesteuert werden. Hinzugefugt in Version 227. E/A-Buchfuhrung und -Steuerung IOAccounting= Diese Einstellung steuert den Controller io in der vereinigten Hierarchie. Schaltet Block-E/A-Buchfuhrung fur 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-Buchfuhrung fur eine Unit dies implizit auch fur alle Units, die in der gleichen Scheibe enthalten sind und fur alle Elternscheiben und die darin befindlichen Units einschaltet. Die Systemvorgabe fur diese Einstellung kann durch DefaultIOAccounting= in systemd-system.conf(5) gesteuert werden. Hinzugefugt in Version 230. IOWeight=Gewicht, StartupIOWeight=Gewicht Diese Einstellungen steueren den Controller io in der vereinigten Hierarchie. Setzt die vorgegebene Gesamt-Block-E/A-Gewichtung fur die ausgefuhrten 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 standardmassig 100 betragt. Fur Details uber dieses Control-Gruppen-Attribut, siehe E/A-Schnittstellen-Dateien[8]. Die verfugbare E/A-Bandbreite wird zwischen allen Units innerhalb einer Scheibe relativ zu ihrer Block-E/A-Gewichtung aufgeteilt. Ein hoherer Wert bedeutet mehr E/A-Bandbreite, ein geringerer Wert weniger. Wahrend StartupIOWeight= in der Hoch- und Runterfahrphase des Systems angewandt wird, wird IOWeight= spater zur Laufzeit des Systems angewandt und falls erstere nicht gesetzt ist, auch wahrend der Hoch- und Runterfahrphasen. Dies erlaubt es, bestimmte Dienste beim Hoch- und Runterfahren anders als zur Laufzeit zu priorisieren. Hinzugefugt in Version 230. IODeviceWeight=Gerat Gewicht Diese Einstellung steuert den Controller io in der vereinigten Hierarchie. Setzt die geratebezogene Gesamt-Block-E/A-Gewichtung fur den ausgefuhrten Prozess, falls die vereinigte Control-Gruppenhierarchie auf dem System verwandt wird. Akzeptiert ein Leerzeichen-getrenntes Paar eines Dateipfades und eines Gewichtungswertes, um den geratespezifischen Gewichtungswert zwischen 1 und 10000 festzulegen. (Beispiel: "/dev/sda 1000"). Der Dateipfad kann als Pfad zu einem Blockgerateknoten oder zu einer anderen Datei angegeben werden. In letzterem Fall wird das zugrundeliegende Blockgerat des Dateisystems der Datei bestimmt. Dies steuert das Control-Gruppen-Attribut >>io.weight<<, das standardmassig 100 ist. Verwenden Sie diese Option mehrfach, um Gewichtungen fur mehrere Gerate zu setzen. Fur Details uber dieses Control-Gruppen-Attribut siehe E/A-Schnittstellen-Dateien[8]. Der festgelegte Gerateknoten sollte ein Blockgerat referenzieren, der einen E/A-Scheduler zugeordnet hat, d.h. er sollte sich nicht auf eine Partition oder Loopback-Blockgerate beziehen, sondern auf das ursprungliche, physische Gerat. Wenn ein Pfad zu einer regularen Datei oder einem regularen Verzeichnis angegeben wird, wird versucht, das korrekte ursprungliche, zugrundeliegende Gerate fur den festgelegten Pfad zu entdecken. Dies funktioniert nur fur die einfacheren Falle korrekt, bei denen das Dateisystem direkt auf einer Partition oder einem physischen Blockgerat angelegt ist, oder bei denen einfache 1:1-Verschlusselung mittels dm-crypt/LUKS verwandt wird. Diese Erkennung deckt komplexe Speicher und insbesondere RAID und Datentrager-Verwaltungs-Speichergerate nicht ab. Hinzugefugt in Version 230. IOReadBandwidthMax=Gerat Byte, IOWriteBandwidthMax=Gerat Byte Diese Einstellungen steueren den Controller io in der vereinigten Hierarchie. Setzt die geratebezogene maximale Gesamt-Block-E/A-Bandbreitenbegrenzung fur den ausgefuhrten Prozess, falls die vereinigte Control-Gruppenhierarchie auf dem System verwandt wird. Diese Begrenzung ist nicht arbeitserhaltend und den ausgefuhrten Prozessen wird nicht mehr erlaubt, selbst falls das Gerat Leerlaufkapazitat hat. Akzeptiert ein Leerzeichen-getrenntes Paar eines Dateipfades und eines Bandbreitenwertes (in Byte pro Sekunde), um die geratespezifische Bandbreite festzulegen. Der Dateipfad kann als Pfad zu einem Blockgerateknoten oder zu einer anderen Datei angegeben werden. In letzterem Fall wird das zugrundeliegende Blockgerat des Dateisystems der Datei bestimmt. Falls der Bandbreite K, M, G oder T angehangt 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 fur mehrere Gerate zu setzen. Fur Details uber dieses Control-Gruppen-Attribut siehe E/A-Schnittstellen-Dateien[8]. Ahnliche Beschrankungen fur die Blockgerate-Erkennung gelten wie bei IODeviceWeight=, siehe oben. Hinzugefugt in Version 230. IOReadIOPSMax=Gerat EAPS, IOWriteIOPSMax=Gerat EAPS Diese Einstellungen steueren den Controller io in der vereinigten Hierarchie. Setzt die geratebezogene maximale Gesamt-Block-E/A-EA-Pro-Sekunden-Begrenzung fur den ausgefuhrten Prozess, falls die vereinigte Control-Gruppenhierarchie auf dem System verwandt wird. Diese Begrenzung ist nicht arbeitserhaltend und den ausgefuhrten Prozessen wird nicht mehr als dieser Wert erlaubt, selbst falls das Gerat Leerlaufkapazitat hat. Akzeptiert ein Leerzeichen-getrenntes Paar eines Dateipfades und eines EAPS-Wertes, um den geratespezifischen EAPS festzulegen. Der Dateipfad kann als Pfad zu einem Blockgerateknoten oder zu einer anderen Datei angegeben werden. In letzterem Fall wird das zugrundeliegende Blockgerat des Dateisystems der Datei bestimmt. Falls dem EAPS K, M, G oder T angehangt 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 fur mehrere Gerate zu setzen. Fur Details uber dieses Control-Gruppen-Attribut siehe E/A-Schnittstellen-Dateien[8]. Ahnliche Beschrankungen fur die Blockgerate-Erkennung gelten wie bei IODeviceWeight=, siehe oben. Hinzugefugt in Version 230. IODeviceLatencyTargetSec=Gerat Ziel Diese Einstellung steuert den Controller io in der vereinigten Hierarchie. Setzt die geratebezogene durchschnittliche Ziel-E/A-Latenz fur den ausgefuhrten Prozess, falls die vereinigte Control-Gruppenhierarchie auf dem System verwandt wird. Akzeptiert einen Dateipfad und eine Zeitspanne, getrennt durch ein Leerzeichen, um das geratespezifische Latenzziel festzulegen. (Beispiel: "/dev/sda 25ms"). Der Dateipfad kann als Pfad zu einem Blockgerateknoten oder zu einer anderen Datei angegeben werden. In letzterem Fall wird das zugrundeliegende Blockgerat des Dateisystems der Datei bestimmt. Dies steuert das Control-Gruppen-Attribut >>io.latency<<. Verwenden Sie diese Option mehrfach, um Latenzziele fur mehrere Gerate zu setzen. Fur Details uber dieses Control-Gruppen-Attribut siehe E/A-Schnittstellen-Dateien[8]. Impliziert >>IOAccounting=yes<<. Diese Einstellungen werden nur unterstutzt, falls die vereinigte Control-Gruppenhierarchie verwandt wird. Ahnliche Beschrankungen fur die Blockgerate-Erkennung gelten wie bei IODeviceWeight=, siehe oben. Hinzugefugt in Version 240. Netzwerk-Buchfuhrung und -Steuerung IPAccounting= Akzeptiert ein logisches Argument. Falls wahr, wird die IPv4- und IPv6-Netzwerkverkehrsbuchfuhrung fur Pakete, die von dieser Unit gesandt oder empfangen werden, eingeschaltet. Wenn diese Option eingeschaltet wird, erfolgt fur alle von einem der Prozesse der Unit erstellten IPv4- und IPv6-Sockets die Buchfuhrung. Wenn diese Option in Socket-Units verwandt wird, wird sie auf alle hierzu zugeordneten IPv4- und IPv6-Socket (einschliesslich der auf Anfragen wartenden und der Verbindugssockets, wo dies zutrifft) angewandt. Beachten Sie, dass fur Socket-aktivierte Dienste diese Konfigurationseinstellung und die Buchufuhrungsdaten 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 samtlicher Verkehr, der auf einem der Sockets der Socket-Unit empfangen oder gesandt wird fur die Socket-Unit buchgefuhrt -- und niemals fur die Dienste-Unit, die sie aktiviert haben konnte, selbst falls der Socket von dieser verwandt wird. Die Systemvorgabe fur diese Einstellung kann mit DefaultIPAccounting= in systemd-system.conf(5) gesteuert werden. Hinzugefugt in Version 235. IPAddressAllow=ADRESSE[/PRAFIXLANGE], IPAddressDeny=ADRESSE[/PRAFIXLANGE] Schaltet Netzwerkverkehrsfilterung fur IP-Pakete, die uber 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 Adressprafixlange in Bits nach einem Zeichen >>/<< angehangt werden. Falls die Endung entfallt, wird die Adresse als Rechneradresse betrachtet, d.h. der Filter deckt die gesamte Adresse ab (32 Bit fur IPv4, 128 Bit fur 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 fur irgendeine Elternscheibe, bei der diese Unit Mitglied sein konnte, kombiniert. Standardmassig 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 gepruft, im Falle des ausgehenden Verkehrs wird die Ziel-IP-Adresse gepruft. Die folgenden Regeln werden nacheinander angewandt: o Falls die uberpufte IP-Adresse auf einen Eintrag in der Einstellung IPAddressAllow= passt, wird der Zugriff erlaubt. o Falls die uberprufte IP-Adresse auf einen Eintrag in der Liste IPAddressDeny= passt, wird andernfalls der Zugriff verweigert. o Andernfalls wird der Zugriff gewahrt. Um eine IP-Firewall mit Positivliste zu implementieren, wird empfohlen, eine Einstellung IPAddressDeny=any in einer hoherstufigen Scheiben-Unit (wie der Wurzel-Scheibe -.slice oder der Scheibe, die alle Systemdienste enthalt, system.slice - siehe systemd.special(7) fur Details uber diese Scheiben-Units) zu verwenden, erganzt um individuelle, dienstebezogene IPAddressAllow=-Zeilen, die Netzwerkzugriff auf relevante Dienste, und nur diese, erlauben. Beachten Sie, dass fur 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 dafur schliesslich aktivierten Diensten erstellt wurde. Umgekehrt werden die fur die Dienste konfigurierten IP-Zugriffslisten nicht auf irgendein Socket angewandt, das dem Dienst uber 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 beschrankter zu verwalten, abhangig 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 zuruckgesetzt und alle vorherigen Einstellungen aufgehoben. Anstelle expliziter IPv4- oder IPv6-Adressen und Prafixlangenfestlegungen kann auch eine kleine Gruppe von symbolischen Namen verwandt werden. Die folgenden Namen sind definiert: Tabelle 1. Besondere Adress-/Netzwerknamen +------------------+---------------------+--------------------------+ |Symbolischer Name | Definition | Bedeutung | +------------------+---------------------+--------------------------+ |any | 0.0.0.0/0 ::/0 | jeder Rechner | +------------------+---------------------+--------------------------+ |localhost | 127.0.0.0/8 ::1/128 | alle Adressen auf dem | | | | lokalen Loopback | +------------------+---------------------+--------------------------+ |link-local | 169.254.0.0/16 | alle linklokalen | | | fe80::/64 | IP-Adressen | +------------------+---------------------+--------------------------+ |multicast | 224.0.0.0/4 | alle | | | ff00::/8 | IP-multicasting-Adressen | +------------------+---------------------+--------------------------+ Beachten Sie, dass diese Einstellungen auf einigen Systemen nicht unterstutzt werden konnten (beispielsweise falls eBPF-Control-Gruppen-Unterstutzung nicht im unterliegenden Kernel oder Container-Verwalter aktiviert ist). Diese Einstellungen haben in diesem Fall keine Auswirkung. Falls Kompatibilitat mit solchen Systemen gewunscht ist, wird daher empfohlen, sich nicht exklusiv auf sie fur IP-Sicherheit zu verlassen. Diese Option kann nicht durch Voranstellen von >>+<< vor den Ausfuhrungspfad in der Dienste-Unit umgangen werden, da sie fur die gesamte Control-Gruppe gilt. Hinzugefugt in Version 235. SocketBindAllow=Binderegel, SocketBindDeny=Binderegel Erlaubt oder verweigert das Anbinden einer Socket-Adresse an ein Socket durch Vergleich mit der Binderegel und Anwendung der entsprechenden Aktion, falls ein Treffer vorliegt Binderegel beschreibt Socket-Eigenschaften wie Adressfamilie, Transportprotokoll und IP-Ports. Binderegel := { [Adressfamilie:][Transportprotokoll:][IP-Ports] | any } Adressfamilie := { ipv4 | ipv6 } Transportprotokoll := { tcp | udp } IP-Ports:= { IP-Port | IP-Port-Bereich } Eine optionale Adressfamilie erwartet die Werte ipv4 oder ipv6. Falls nicht angegeben, passt eine Regel auf sowohl IPv4- als auch IPv6-Adressen und wird abhangig von anderen Socket-Felder angewendet, z.B. Transportprotokoll, IP-Port. Ein optionales Transportprotokoll erwartet den Transportprotokollnamen tcp oder udp. Falls nicht festgelegt, passt eine Regel auf jedes Transportprotokoll. Ein optionaler Wert IP-Port muss innerhalb des Intervalls 165535 (einschliesslich) liegen, d.h. der dynamische Port 0 ist nicht erlaubt. Ein Bereich von fortlaufenden Ports wird durch IP-Port-Bereich IP-Port-niedrig-IP-Port-hoch beschrieben, wobei IP-Port-niedrig kleiner oder gleich IP-Port-hoch ist und beide innerhalb von 165535 (einschliesslich) liegen. Ein besonderer Wert any kann zum Anwenden einer Regel fur jede Adressfamilie, jedes Transportprotokoll und jeden Port mit einem positiven Wert verwandt werden. Um mehrere Regeln zu erlauben, weisen Sie SocketBindAllow= oder SocketBindDeny= mehrfach zu. Um eine Zuweisung zuruckzusetzen, ubergeben Sie eine leere Zuweisung SocketBindAllow= oder SocketBindDeny=. Fur sowohl SocketBindAllow= als auch SocketBindDeny= ist die maximale Anzahl an Zuweisungen 128. o Anbinden an ein Socket wird erlaubt, wenn die Socket-Adresse auf einen Eintrag in der Liste SocketBindAllow= passt. o Andernfalls wir das Anbinden verweigert, falls die Socket-Adresse auf einen Eintrag in der Liste SocketBindDeny= passt. o Andernfalls wird das Anbinden erlaubt. Die Funktionalitat ist mit Cgroup-BPF-Hooks cgroup/bind4 und cgroup/bind6 implementiert. Beispiele: ... # Erlaubt das Anbinden von IPv6-Socket-Adressen mit Ports grosser oder gleich 10000. [Service] SocketBindAllow=ipv6:10000-65535 SocketBindDeny=any # Erlaubt das Anbinden von IPv4- und IPv6-Socket-Adressen mit 1234 und 4321 Ports. [Service] SocketBindAllow=1234 SocketBindAllow=4321 SocketBindDeny=any # Verweigert das Anbinden von IPv6-Socket-Adressen. [Service] SocketBindDeny=ipv6 # Verweigert das Anbinden von IPv4- und IPv6-Socket-Adressen. [Service] SocketBindDeny=any # Erlaubt das Anbinden nur uber TCP [Service] SocketBindAllow=tcp SocketBindDeny=any # Erlaubt das Anbinden nur uber IPv6/TCP [Service] SocketBindAllow=ipv6:tcp SocketBindDeny=any # Erlaubt das Anbinden von Ports innerhalb des Bereichs 10000-65535 uber IPv4/UDP. [Service] SocketBindAllow=ipv4:udp:10000-65535 SocketBindDeny=any Diese Option kann nicht durch Voranstellen von >>+<< vor den Ausfuhrungspfad in der Dienste-Unit umgangen werden, da sie fur die gesamte Control-Gruppe gilt. Hinzugefugt in Version 249. RestrictNetworkInterfaces= Akzeptiert eine Leerzeichen-getrennte Liste von Netzwerkschnittstellennamen. Diese Option beschrankt die Netzwerkschnittstellen, die Prozesse dieser Unit verwenden konnen. Standardmassig konnen Prozesse nur die aufgefuhrten Netzwerknamen verwenden (Erlaubnisliste). Falls das erste Zeichen der Regel eine >>~<< ist, dann wird die Auswirkung invertiert: die Prozesse konnen nur Netzwerkschnittstellen verwenden, die nicht aufgefuhrt sind (Verbotsliste). Diese Option kann mehrfach aufauchen, dann werden die Netzwerkschnittstellennamen vereinigt. Falls die leere Zeichenkette zugewiesen wird, wird die Gruppe zuruckgesetzt, alle vorherigen Zuweisungen haben keine Wirkung. Falls Sie beide Typen dieser Option festlegen (d.h. Erlaubnisliste und Verbotsliste), wird die zuerst vorkommende Vorrang haben und die Standardaktion vorgeben (erlauben oder verbieten). Dann wird das nachste Vorkommen dieser Option die aufgefuhrten Netzwerkschnittstellennamen zu der Menge hinzufugen oder sie daraus entfernen, abhangig von seinem Typ und der Vorgabeaktion. Die Loopback-Schnittstelle (>>lo<<) wird auf keine Weise besonders behandelt, Sie mussen sie explizit in der Unit-Datei konfigurieren. Beispiel 1: Erlaubnisliste RestrictNetworkInterfaces=eth1 RestrictNetworkInterfaces=eth2 Programme in dieser Unit-Datei werden nur in der Lage sein, die Netzwerkschnittstellen eth1 und eth2 zu verwenden. Beispiel 2: Verbotsliste RestrictNetworkInterfaces=~eth1 eth2 Programme in dieser Unit-Datei werden in der Lage sein, alle Netzwerkschnittstellen ausser eth1 und eth2 zu verwenden. Beispiel 3: gemischt RestrictNetworkInterfaces=eth1 eth2 RestrictNetworkInterfaces=~eth1 Programme in der Unit-Datei werden nur in der Lage sein, die Netzwerkschnittstelle eth2 zu verwenden. Diese Option kann nicht durch Voranstellen von >>+<< vor den Ausfuhrungspfad in der Dienste-Unit umgangen werden, da sie fur die gesamte Control-Gruppe gilt. Hinzugefugt in Version 250. NFTSet=Familie:Tabelle:Gruppe Diese Einstellung stellt eine Methode zur Integration dynamischer Cgroup-, Benutzer- und Gruppenkennungen in Firewallregeln mittels NFT[9]-Gruppen bereit. Der Vorteil der Verwendung dieser Einstellung liegt darin, dass die Kennungen leicht als Auswahlmerkmal in Firewallregeln verwandt werden kann, wodurch in Folge feiner granulares Filtern ermoglicht wird. NFT-Regeln fur Cgroup-Vergleiche verwenden nummerische Cgroup-Kennungen, die sich bei jedem Neustart eines Dienstes andern, wodurch sie in Systemdumgebungen andernfalls schwer zu verwenden sind. Von DynamicUser= verwandte dynamische und zufallige Kennungen konnen ebenfalls mit dieser Einstellung integriert werden. Diese Option erwartet eine durch Leerraum getrennte Liste von NFT-Gruppendefinitionen. Jede Definition besteht aus einem Doppelpunkt-getrennten Tupel von Quelltyp (einer aus >>cgroup<<, >>user<<, >>group<<), NFT-Adressfamilie (einer aus >>arp<<, >>bridge<<, >>inet<<, >>ip<<, >>ip6<<, >>netdev<<), Tabellenname und Gruppenname. Die Namen der Tabellen und Gruppen mussen den lexikalischen Beschrankungen von NFT-Tabellennamen folgen. Der Typ des in NFT-Filtern verwandten Elements muss auf den durch die Direktive (>>cgroup<<, >>user<< oder >>group<<) implizierten Typ passen, wie in der nachfolgenden Tabelle gezeigt. Wenn eine Control-Gruppe oder eine Unit realisiert wird, wird die entsprechende Kennung an die NFT-Gruppen angehangt und sie wird entfernt, wenn die Control-Gruppe oder Unit entfernt wird. systemd fugt nur Elemente in die Gruppen ein (entfernt sie daraus), daher mussen die NFT-Regeln, -Tabllen und -Gruppen vorher woanders erstellt werden. Fehler beim Verwalten der Gruppen werden ignoriert. Tabelle 2. Definierte Quelltyp-Werte +---------+-------------------------+----------------+ |Quelltyp | Beschreibung | Entsprechender | | | | NFT-Typname | +---------+-------------------------+----------------+ |"cgroup" | Control-Gruppen-Kennung | "cgroupsv2" | +---------+-------------------------+----------------+ |"user" | Benutzerkennung | "meta skuid" | +---------+-------------------------+----------------+ |"group" | Gruppenkennung | "meta skgid" | +---------+-------------------------+----------------+ Falls die Firewallregeln neu installiert werden, so dass die NFT-Gruppen zerstort werden, kann der Befehl systemctl daemon-reload zur Wiederbefullung der Gruppen verwandt werden. Beispiel: [Unit] NFTSet=cgroup:inet:filter:my_service user:inet:filter:serviceuser Entsprechende NFT-Regeln: table inet filter { set my_service { type cgroupsv2 } set serviceuser { typeof meta skuid } chain x { socket cgroupv2 level 2 @my_service accept drop } chain y { meta skuid @serviceuser accept drop } } Hinzugefugt in Version 255. BPF-Programme IPIngressFilterPath=BPF_FS_PROGRAM_PATH, IPEgressFilterPath=BPF_FS_PROGRAM_PATH Fugt angepasste Netzwerkverkehrsfilter hinzu, die als BPF-Programme implementiert und auf alle uber 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 zusatzlich zu den Filter aller Eltern-Scheiben-Units, bei denen diese Unit ein Mitglied sein konnte, sowie samtlichen IPAddressAllow=- und IPAddressDeny=-Filtern in jeden dieser Units geladen. Standardmassig sind keine Filter festgelegt. Falls diese Einstellungen mehrfach in der gleichen Unit verwandt werden, werden alle angegebenen Programme angehangt. Falls diesen Einstellungen eine leere Zeichenkette zugewiesen wird, wird die Programmliste zuruckgesetzt und alle vorher angegebenen Programme ignoriert. Falls der Pfad BPF_FS_PROGRAM_PATH in der Zuweisung IPIngressFilterPath= bereits durch einen Eingangs-Hook BPFProgram= gehandhabt wird, z.B. BPFProgram=ingress:BPF_FS_PROGRAM_PATH, dann wird die Zuweisung immer noch als gultig betrachtet und das Programm an eine Cgroup angehangt. Genauso fur den Pfad IPEgressFilterPath= und den Hook egress. Beachten Sie, dass fur 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 dafur schliesslich aktivierten Diensten erstellt wurde. Umgekehrt werden die fur die Dienste konfigurierten IP-Filterprogramme nicht auf irgendein Socket angewandt, das dem Dienst uber 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 beschrankter zu verwalten, abhangig vom Einsatzfall. Beachten Sie, dass diese Einstellungen auf einigen Systemen nicht unterstutzt werden konnten (beispielsweise falls eBPF-Control-Gruppen-Unterstutzung nicht im unterliegenden Kernel oder Container-Verwalter aktiviert ist). Diese Einstellungen fuhren in diesem Fall zu einem Fehlschlag des Dienstes. Falls Kompatibilitat mit solchen Systemen gewunscht ist, wird daher empfohlen, ihre Filter manuell (benotigt Delegate=yes) anzuhangen, statt diese Einstellung zu verwenden. Hinzugefugt in Version 243. BPFProgram=Typ:Programmpfad BPFProgram= erlaubt das Anhangen von angepassten BPF-Programmen an die Cgroup einer Unit. (Dies verallgemeinert die mittels IPEgressFilterPath= und IPIngressFilterPath= fur andere Hooks offengelegte Funktionalitat.) Cgroup-bpf-Hooks in der Form von BPF-Programmen, die in das BPF-Dateisystem geladen werden, werden mit den durch die Unit ermittelten Cgroup-Bpf-Anhange-Schaltern angehangt. Fur Details uber Anhange-Typen und Schalter siehe bpf.h[10]. Schauen Sie auch in die allgemeine BPF-Dokumentation[11]. Die Spezifikation eines BPF-Programms besteht aus einem Paar aus BPF-Programmtyp und -Programmpfad im Dateisystem, wobei >>:<< der Trenner ist: Typ:Programmpfad. Der BPF-Programmtyp ist aquivalent zu dem in bpftool(8) verwandten BPF-Anhangetyp. Er kann sein: egress, ingress, sock_create, sock_ops, device, bind4, bind6, connect4, connect6, post_bind4, post_bind6, sendmsg4, sendmsg6, sysctl, recvmsg4, recvmsg6, getsockopt oder setsockopt. Der festgelegte Programmpfad muss ein absoluter Pfad sein, der eine BPF-Programm-Inode in dem bpffs-Dateisystem referenziert (dies bedeutet im Allgemeinen, dass er mit >>/sys/fs/bpf/<< beginnt). Falls ein festgelegtes Programm nicht existiert (d.h. es noch nicht in das BPF-Subsystem des Kernels hochgeladen wurde), wird es nicht installiert, aber mit der Unit-Aktivierung wird fortgefahren (in die Protokolle wird eine Warnung ausgegeben). Durch Setzen von BPFProgram= auf einen leeren Wert werden vorherige Zuweisungen unwirksam. Mehrfache Zuweisungen des gleichen Werts Programmtyp/Pfad-Paar haben die gleiche Auswirkung wie eine einzelne Zuweisung: Das Programm wird nur einmal angehangt. Falls das auf Programmpfad befestigte BPF-egress bereits durch IPEgressFilterPath= behandelt wird, wird die Zuweisung BPFProgram= als gultig betrachtet und BPFProgram= an eine Cgroup angehangt. Ahnlich fur den Hook ingress die Zuweisung IPIngressFilterPath=. Mit BPFProgram= ubergebene BPF-Programme werden an die Cgroup einer Unit mit dem BFP-Anhangeschalter multi angehangt, der weitere Anhangungen des gleichen Typs innerhalb der Cgroup-Hierarchie mit der Unit-Cgroup an der Spitze erlaubt. Beispiele: BPFProgram=egress:/sys/fs/bpf/egress-hook BPFProgram=bind6:/sys/fs/bpf/sock-addr-hook Hinzugefugt in Version 249. Geratezugriff DeviceAllow= Steuert Zugriff auf bestimmte Gerateknoten durch ausgefuhrte Prozesse. Akzeptiert zwei Leerzeichen-getrennte Zeichenketten: einen Gerateknotenkennzeichner, gefolgt von einer Kombination aus r, w, m, um das Lesen, Schreiben bzw. Erstellen von bestimmten Gerateknoten der Unit (mit mknod) zu steuern. Diese Funktionalitat ist mittels eBPF-Filterung implementiert. Wenn der Zugriff auf alle physischen Gerate verboten werden soll, kann stattdessen PrivateDevices= verwandt werden. Siehe systemd.exec(5). Der Gerateknotenkennzeichner ist entweder ein Pfad zu einem Gerateknoten in dem Dateisystem, beginnend mit /dev/, oder eine Zeichenkette, die entweder mit >>char-<< oder >>block-<< beginnt und von einem Gerategruppennamen, wie in /proc/devices aufgefuhrt, gefolgt wird. Letzteres ist nutzlich, um eine Positivliste aller aktuellen und zukunftigen Gerate, die zu einer bestimmten Gerategruppe gehoren, auf einmal anzulegen. Die Gerategruppe wird entsprechend der Dateinamen-Glob-Muster-Regeln abgeglichen, Sie konnen daher die Metazeichen >>*<< und >>?<< verwenden. (Beachten Sie, dass solche Glob-Metazeichen nicht fur Gerateknotenpfadspezifikationen verfugbar sind) Um Gerateknoten gemass Major-/Minor-Nummern abzugleichen, verwenden Sie Gerateknotenpfade in den Verzeichnissen /dev/char/ und /dev/block/. Allerdings wird das Abgleichen von Geraten 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 Gerateknoten, der sich auf ein ATA- oder SCSI-Blockgerat bezieht. >>char-pts<< und >>char-alsa<< sind Kennzeichner fur alle Pseudo-TTY- bzw. alle ALSA-Sound-Gerate. >>char-cpu/*<< ist ein Kennzeichner, der auf alle Gerategruppen mit CPU-Bezug passt. Beachten Sie, dass auf diese Weise definierte Positivlisten nur Gerategruppen referenzieren sollten, die zum Startzeitpunkt der Unit auflosbar sind. Samtliche Gerate, die zu diesem Zeitpunkt nicht auflosbar sind, werden nicht zur Positivliste hinzugefugt. Um diese Einschrankung zu umgehen, konnen Sie Dienste-Units um eine Paar von After=modprobe@xyz.service- und Wants=modprobe@xyz.service-Zeilen erganzen, die die notwendigen Kernelmodule laden, die die Gerategruppe implementieren, falls sie fehlen. Beispiel: ... [Unit] Wants=modprobe@loop.service After=modprobe@loop.service [Service] DeviceAllow=block-loop DeviceAllow=/dev/loop-control Diese Option kann nicht durch Voranstellen von >>+<< vor den Ausfuhrungspfad in der Dienste-Unit umgangen werden, da sie fur die gesamte Control-Gruppe gilt. Hinzugefugt in Version 208. DevicePolicy=auto|closed|strict Steuert die Richtlinien zum Erlauben des Geratezugriffs: strict bedeutet, nur Zugriffstypen zu erlauben, die explizit festgelegt wurden. Hinzugefugt in Version 208. closed erlaubt zusatzlich Zugriff auf die Standard-Pseudo-Gerate einschliesslich /dev/null, /dev/zero, /dev/full, /dev/random und /dev/urandom. Hinzugefugt in Version 208. auto erlaubt zusatzlich Zugriff auf alle Gerate, falls kein explizites DeviceAllow= vorhanden ist. Dies ist die Vorgabe. Hinzugefugt in Version 208. Diese Option kann nicht durch Voranstellen von >>+<< vor den Ausfuhrungspfad in der Dienste-Unit umgangen werden, da sie fur die gesamte Control-Gruppe gilt. Hinzugefugt in Version 208. Control-Gruppen-Verwaltung Slice= Der Name der Scheiben-Unit, in die die Unit hineingelegt werden soll. Standardmassig system.slice fur alle noch nicht instanziierten Units aller Unit-Typen (ausser fur Scheiben-Units selbst, siehe unten). Instanzen-Units werden standardmassig 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 konnen. Fur Units vom Typ >>Scheibe<< ist der einzige fur diese Einstellung akzeptierte Wert die Elternscheibe. Da der Name einer Scheiben-Unit die Elternscheibe impliziert, ist es daher immer redundant, diesen Parameter direkt fur 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 >>Standardabhangigkeiten<< fur Details. Hinzugefugt in Version 208. Delegate= Schaltet die Delegierung weiterer Ressourcensteuereinteilung auf die Prozesse der Unit ein. Units, bei denen dieses aktiviert ist, konnen ihre eigene private Unterhierarchie von Control-Gruppen unterhalb der Control-Gruppe der Unit selbst einrichten und verwalten. Fur nicht privilegierte Dienste (d.h. solchen, die die Einstellung User= verwenden), erhalt der relevante Benutzer Zugriff auf die Control-Gruppe der Unit. Wenn dies aktiviert ist, wird der Diensteverwalter es unterlassen, die Control-Gruppen zu verandern oder Prozesse unterhalb der Control-Gruppe der Unit zu verschieben, so dass ein klares Konzept der Eigentumerschaft etabliert wird: der Control-Gruppenbaum auf der Ebene der Control-Gruppe der Unit ond oberhalb (d.h. in Richtung der Wurzel-Control-Gruppe) gehort dem Diensteverwalter des Rechners und wird von ihm verwaltet, wahrend der Control-Gruppenbaum unterhalb der Control-Gruppe der Unit der Unit selbst gehort und von dieser verwaltet wird. Akzeptiert entweder ein logisches Argument oder eine (moglicherweise leere) Liste von Namen von Control-Gruppen-Controllern. Falls wahr, wird die Delegierung eingeschaltet und alle fur die Unit unterstutzten Controller werden aktiviert, wodurch sie fur die Verwaltung der Prozesse der Unit verfugbar werden. Falls falsch, wird die Delegierung komplett ausgeschaltet (und keine zusatzlichen Controller werden aktiviert). Falls auf eine Liste von Controllern gesetzt, wird die Delegierung eingeschaltet und die festgelegten Controller werden fur die Unit aktiviert. Zuweisung der leeren Liste wird Delegierung aktivieren, aber die Liste der Controller zurucksetzen, und alle vorherigen Zuweisungen haben keine Auswirkung. Beachten Sie, dass andere als die festgelegten Controller auch verfugbar gemacht werden konnen, abhangig von der Konfiguration der enthaltenen Scheibe oder anderer, darin enthaltener Units. Standardmassig falsch. Beachten Sie, dass Controller-Delegation an weniger privilegierten Code nur auf der vereinigten Control-Gruppenhierarchie sicher ist. Entsprechend wird der Zugriff auf die angegebenen Controller nicht an unprivilegierte Dienste auf der veralteten Hierarchie gewahrt, selbst falls dies angefragt wurde. Die folgenden Controller-Namen konnen festgelegt werden: cpu, cpuacct, cpuset, io, blkio, memory, devices, pids, bpf-firewall, und bpf-devices. Nicht alle dieser Controller sind allerdings auf allen Kerneln verfugbar und einige sind spezifisch fur die vereinigte Hierarchie, wahrend andere fur die veraltete Hierarchie spezifisch sind. Beachten Sie auch, dass der Kernel weitere Controller unterstutzen konnte, die hier noch nicht berucksichtigt sind, da Delegation hierfur uberhaupt noch nicht unterstutzt wird oder noch nicht sauber definiert ist. Beachten Sie, dass aufgrund der hierarchischen Natur der Cgroup-Hierarchie alle delegierten Controller fur die Eltern- und Geschwister-Units der Units der Delegierung aktiviert werden. Fur weitere Details uber das Delegationsmodell ziehen Sie bitte Control-Gruppen-APIs und Delegierung[12] heran. Hinzugefugt in Version 218. DelegateSubgroup= Legt Unit-Prozesse in die festgelegte Untergruppe der Control-Gruppe der Unit ab. Akzeptiert den Namen einer gultigen Control-Gruppe (nicht den Pfad!) als Parameter oder eine leere Zeichenkette, um diese Funktionalitat abzuschalten. Standardmassig abgeschaltet. Der Name der Control-Gruppe muss als Dateiname benutzbar sein und Konflikte mit den Control-Gruppen-Attributdateien des Kernels vermeiden (d.h. cgroup.procs kann nicht als Name akzeptiert werden, da der kernel eine native Control-Gruppen-Attributdatei mit dem Namen offenlegt). Diese Option hat nur Auswirkungen, wenn die Control-Gruppendelegation mittels Delegate= eingeschaltet ist, siehe oben. Beachten Sie, dass diese Einstellung nur fur den >>Haupt<<-Prozess einer Unit gilt, d.h. fur Dienste auf ExecStart=, aber nicht fur ExecReload= und ahnliche. Falls Delegierung aktiviert ist, wird letztere immer innerhalb einer Untergruppe namens >>.control<< abgelegt. Die festgelegte Untergruppe wird automatisch erstellt (und moglicherweise die Eigentumerschaft an die fur die Unit konfigurierten Benutzer/Gruppen abgegeben), wenn darin ein Prozess gestartet wird. Diese Option ist nutzlich, um das manuelle Verschieben des aufgerufenen Prozesses in eine Untergruppe zu vermeiden, nachdem dieser gestartet wurde. Da kein Prozess in den inneren Inodes der Control-Gruppenbaumes leben sollte, ist es fast immer notwendig, den Hauptprozess (>>Uberwacher<<) einer Unit, bei der Delegierung eingeschaltet ist, in einer Untergruppe auszufuhren. Hinzugefugt in Version 254. DisableControllers= Deaktiviert Controller, so dass sie fur die Kinder einer Unit nicht eingeschaltet werden konnen. Falls ein aufgefuhrter Controller bereits in seinem Unterbaum in Verwendung ist, wird der Controller aus dem Unterbaum entfernt. Damit konnen Sie vermeiden, dass Konfiguration in Kind-Units in die Lage versetzt wird, implizit oder explizit einen Controller einzuschalten. Standardmassig leer. Es konnen mehrere Controller durch Leerzeichen getrennt angegeben werden. Sie konnen auch DisableControllers= mehrfach angeben, dann wird jede neue Instanz einen anderen Controller zum Deaktivieren hinzufugen. Wird DisableControllers= selbst ohne vorhandenen Controller-Namen ubergeben, dann wird die Liste der deaktivierten Controller zuruckgesetzt. Es mag nicht moglich sein, einen Controller zu deaktivieren, nachdem die Units gestartet wurden, 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. Die folgenden Controller-Namen konnen festgelegt werden: cpu, cpuacct, cpuset, io, blkio, memory, devices, pids, bpf-firewall, und bpf-devices. Hinzugefugt in Version 240. Speicherdruck-Steuerung ManagedOOMSwap=auto|kill, ManagedOOMMemoryPressure=auto|kill Gibt an, wie systemd-oomd.service(8) mit den Cgroups dieser Unit umgeht. Standardmassig auto. Wird dies auf kill gesetzt, dann wird die Unit ein Kandidat fur die Uberwachung durch systemd-oomd. Falls die Cgroup die durch oomd.conf(5) oder die Unit-Konfiguration gesetzten Beschrankungen uberschreitet, dann wird systemd-oomd eine Nachkommens-Cgroup auswahlen und SIGKILL an alle darunter befindlichen Prozesse senden. Sie erhalten weitere Details uber Kandidaten und das Totenverhalten unter systemd-oomd.service(8) und oomd.conf(5). Wird eine dieser Eigenschaften auf kill gesetzt, fuhrt dies zu Abhangigkeiten After= und Wants= auf systemd-oomd.service ausser DefaultDependencies=no. Wird dies auf auto gesetzt, dann wird systemd-oomd nicht aktiv diese Cgroup-Daten zur Uberwachung und Erkennung verwenden. Falls allerdings eine Vorfahr-Cgroup eine dieser Eigenschaften auf kill gesetzt hat, dann kann eine Unit mit auto weiterhin ein Kandidat fur systemd-oomd zum Beenden sein. Hinzugefugt in Version 247. ManagedOOMMemoryPressureLimit= Setzt die durch oomd.conf(5) fur diese Unit (Cgroup) gesetzte Standard-Speicher-Belastungsgrenze ausser Kraft. Akzeptiert einen Prozentwert zwischen (einschliesslich) 0% und 100%. Diese Eigenschaft wird ignoriert, ausser ManagedOOMMemoryPressure=kill. Standardmassig 0%, was bedeutet, dass die in oomd.conf(5) gesetzte Vorgabe verwandt wird. Hinzugefugt in Version 247. ManagedOOMPreference=none|avoid|omit Erlaubt das Herunterpriorisieren oder Uberspringen der Cgroup dieser Unit als Kandidat, wenn systemd-oomd agieren muss. Benotigt Unterstutzung fur erweiterte Attribute (siehe xattr(7)), um avoid oder omit zu verwenden. Bei der Berechnung von Kandidaten, um die Verwendung des Auslagerungsspeichers zu reduzieren, wird systemd-oomd diese erweiterten Attribute nur respektieren, falls die Cgroup der Unit root gehort. Bei der Berechnung von Kandidaten, um Speicherdruck zu reduzieren, wird systemd-oomd diese erweiterten Attribute nur respektieren, falls der Eigentumer der Cgroup root ist oder falls der Eigentumber der Cgrop und der des Vorgangers identisch sind. Falls beispielsweise systemd-oomd Kandiaten fur -.slice berechnet, werden die auf die Nachfahren von /user.slice/user-1000.slice/user@1000.service/ gesetzten erweiterten Attribute ignoriert, da die Nachfahren UID 1000 gehoren und -.slice UID 0 gehort. Falls aber Kandidaten fur /user.slice/user-1000.slice/user@1000.service/ berechnet werden, dann werden auf die Nachfahren gesetzte erweiterte Attribute respektiert. Falls diese Eigenschaft auf avoid gesetzt ist, wird der Diensteverwalter dies systemd-oomd mitteilen, der diese Cgroup nur auswahlen wird, wenn es keinen anderen brauchbaren Kandidaten gibt. Falls diese Eigenschaft auf omit gesetzt ist, wird der Diensteverwalter dies systemd-oomd mitteilen, der diese Cgroup als Kandidat ignorieren und keinerlei Aktion auf ihr ausfuhren wird. Es wird empfohlen, avoid und omit nur vereinzelt zu verwenden, da es das Kill-Verhalten von systemd-oomd negativ beeinflussen kann. Beachten Sie auch, dass diese erweiterten Attribute nicht rekursiv auf Cgroups unterhalb der Cgroup dieser Unit angewandt werden. Standardmassig none, was bedeutet, dass systemd-oomd die Cgroup dieser Unit wie in systemd-oomd.service(8) und oomd.conf(5) definiert einordnen wird. Hinzugefugt in Version 248. MemoryPressureWatch= Steuert die Uberwachung von Speicherdruck fur aufgerufene Prozesse. Akzeptiert entweder >>off<<, >>on<<, >>auto<< oder >>skip<<. Falls >>off<<, wird dem Dienst mitgeteilt, nicht auf Speicherdruckereignisse zu beobachten, indem die Umgebungsvariable $MEMORY_PRESSURE_WATCH auf die wortliche Zeichenkette >>/dev/null<< gesetzt wird. Falls >>on<<, wird dem Dienst mitgeteilt, auf Speicherdruckereignisse zu beobachten. Dies aktiviert die Speicherbuchfuhrung fur den Dienst und stellt sicher, dass die Cgroup-Attributdatei memory.pressure fur den Benutzer des Dienstes zum Lesen und Schreiben verfugbar ist. Es setzt dann die Umgebungsvariable $MEMORY_PRESSURE_WATCH fur Prozesse, die von der Unit aufgerufen werden, auf den Dateisystempfad auf diese Datei. Die mittels MemoryPressureThresholdSec= konfigurierte Schwellwertinformation wird in der Umgebungsvariable $MEMORY_PRESSURE_WRITE kodiert. Falls der Wert >>auto<< gesetzt ist, wird das Protokoll immer aktiviert, falls Speicherbuchfuhrung fur die Unit sowieso aktiviert ist und andernfalls deaktiviert. Falls auf >>skip<< gesetzt, wird die Logik weder aktiviert noch deaktiviert, und die zwei Umgebungsvariablen werden nicht gesetzt. Beachten Sie, dass Dienste die Freiheit haben, die zwei Umgebungsvariablen zu verwenden, aber es unproblematisch ist, wenn sie sie ignorieren. Der Umgang mit Speicherdruck muss in jedem Dienst individuell implementiert werden und bedeutet normalerweise verschiedene Dinge fur verschiedene Software. Weitere Details zum Umgang mit Speicherdruck finden Sie in Umgang mit Speicherdruck in Systemd[13]. Mittels sd-event(3) implementierte Dienste konnen sd_event_add_memory_pressure(3) verwenden, um auf Speicherdruckereignisse zu beobachten und damit umzugehen. Falls nicht explizit gesetzt ist die Vorgabe fur die Einstellung DefaultMemoryPressureWatch= in systemd-system.conf(5). Hinzugefugt in Version 254. MemoryPressureThresholdSec= Setzt die Speicherdruck-Schwellwertzeit fur den Speicherdruck-Uberwacher, wie mittels MemoryPressureWatch= konfiguriert. Legt die maximale Belegungsverzogerung fest, bevor ein Speicherdruckereignis an den Dienst signalisiert wird, pro 2s-Fenster. Falls nicht angegeben, ist die Vorgabe die Einstellung DefaultMemoryPressureThresholdSec= in systemd-system.conf(5) (die wiederum standardmassig 200ms ist). Der festgelegte Wert erwartet eine Zeiteinheit wie >>ms<< oder >>s<<, siehe systemd.time(7) zu Details fur die erlaubte Syntax. Hinzugefugt in Version 254. Speicherauszugs-Steuerung CoredumpReceive= Akzeptiert ein logisches Argument. Diese Einstellung wird zur Aktivierung der Weiterleitung von Speicherauszugen fur Container verwandt, die zu der Cgroup dieser Unit gehoren. Units mit CoredumpReceive=yes mussen auch mit Delegate=yes konfiguriert werden. Standardmassig falsch. Wenn systemd-coredump(8) einen Speicherauszug fur einen Prozess aus einem Container handhabt und falls der leitende Prozess des Containers ein Nachkommen der Group mit CoredumpReceive=yes und Delegate=yes ist, dann wird systemd-coredump(8) versuchen, den Speicherauszug an systemd-coredump(8) innerhalb des Containers weiterzuleiten. Hinzugefugt in Version 255. GESCHICHTE systemd 252 Optionen fur die Steuerung der veralteten Control-Group-Hierarchie (Control-Gruppen Version 1[14]) sind jetzt vollstandig veraltet: CPUShares=Gewicht, StartupCPUShares=Gewicht, MemoryLimit=Byte, BlockIOAccounting=, BlockIOWeight=Gewicht, StartupBlockIOWeight=Gewicht, BlockIODeviceWeight=Gerat Gewicht, BlockIOReadBandwidth=device Byte, BlockIOWriteBandwidth=Gerat Byte. Bitte stellen Sie auf die vereinigte Cgroup-Hierarchie um. Hinzugefugt in Version 252. SIEHE AUCH systemd(1), systemd-system.conf(5), systemd.unit(5), systemd.service(5), systemd.slice(5), systemd.scope(5), systemd.socket(5), systemd.mount(5), systemd.swap(5), systemd.exec(5), systemd.directives(7), systemd.special(7), systemd-oomd.service(8), Die Dokumentation fur Control-Gruppen und bestimmte Controller im Linux-Kernel: Control-Gruppen v2[2]. ANMERKUNGEN 1. Neue Control-Gruppen-Schnittstellen https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface 2. Control-Gruppen v2 https://docs.kernel.org/admin-guide/cgroup-v2.html 3. CFS-Scheduler https://docs.kernel.org/scheduler/sched-design-CFS.html 4. CFS-Bandbreitensteuerung https://docs.kernel.org/scheduler/sched-bwc.html 5. Speicherschnittstellen-Dateien https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files 6. Zswap https://www.kernel.org/doc/html/latest/admin-guide/mm/zswap.html 7. PIDS-Controller https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid 8. E/A-Schnittstellen-Dateien https://docs.kernel.org/admin-guide/cgroup-v2.html#io-interface-files 9. NFT https://netfilter.org/projects/nftables/index.html 10. bpf.h https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf.h 11. BPF-Dokumentation https://docs.kernel.org/bpf/ 12. Control-Gruppen-APIs und Delegierung https://systemd.io/CGROUP_DELEGATION 13. Umgang mit Speicherdruck in Systemd https://systemd.io/MEMORY_PRESSURE 14. Control-Gruppen Version 1 https://docs.kernel.org/admin-guide/cgroup-v1/index.html UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 SYSTEMD.RESOURCE-CONTROL(5)