{ "content": [ { "type": "text", "text": "# SYSTEMD.RESOURCE-CONTROL (man)\n\n## NAME\n\nsystemd.resource-control - Resource control unit settings\n\n## SYNOPSIS\n\nslice.slice, scope.scope, service.service, socket.socket, mount.mount, swap.swap\n\n## DESCRIPTION\n\nUnit configuration files for services, slices, scopes, sockets, mount points, and swap\ndevices share a subset of configuration options for resource control of spawned processes.\nInternally, this relies on the Linux Control Groups (cgroups) kernel concept for organizing\nprocesses in a hierarchical tree of named groups for the purpose of resource management.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION** (1 subsections)\n- **IMPLICIT DEPENDENCIES**\n- **UNIFIED AND LEGACY CONTROL GROUP HIERARCHIES**\n- **OPTIONS**\n- **DEPRECATED OPTIONS**\n- **SEE ALSO**\n- **NOTES**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "SYSTEMD.RESOURCE-CONTROL", "section": "", "mode": "man", "summary": "systemd.resource-control - Resource control unit settings", "synopsis": "slice.slice, scope.scope, service.service, socket.socket, mount.mount, swap.swap", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [ { "name": "systemd", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/systemd/1/json" }, { "name": "systemd-system.conf", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd-system.conf/5/json" }, { "name": "systemd.unit", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd.unit/5/json" }, { "name": "systemd.service", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd.service/5/json" }, { "name": "systemd.slice", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd.slice/5/json" }, { "name": "systemd.scope", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd.scope/5/json" }, { "name": "systemd.socket", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd.socket/5/json" }, { "name": "systemd.mount", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd.mount/5/json" }, { "name": "systemd.swap", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd.swap/5/json" }, { "name": "systemd.exec", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd.exec/5/json" }, { "name": "systemd.directives", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/systemd.directives/7/json" }, { "name": "systemd.special", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/systemd.special/7/json" }, { "name": "systemd-oomd.service", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/systemd-oomd.service/8/json" } ], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 2, "subsections": [] }, { "name": "DESCRIPTION", "lines": 18, "subsections": [ { "name": "Setting resource controls for a group of related units", "lines": 10 } ] }, { "name": "IMPLICIT DEPENDENCIES", "lines": 5, "subsections": [] }, { "name": "UNIFIED AND LEGACY CONTROL GROUP HIERARCHIES", "lines": 28, "subsections": [] }, { "name": "OPTIONS", "lines": 686, "subsections": [] }, { "name": "DEPRECATED OPTIONS", "lines": 90, "subsections": [] }, { "name": "SEE ALSO", "lines": 5, "subsections": [] }, { "name": "NOTES", "lines": 39, "subsections": [] } ], "sections": { "NAME": { "content": "systemd.resource-control - Resource control unit settings\n", "subsections": [] }, "SYNOPSIS": { "content": "slice.slice, scope.scope, service.service, socket.socket, mount.mount, swap.swap\n", "subsections": [] }, "DESCRIPTION": { "content": "Unit configuration files for services, slices, scopes, sockets, mount points, and swap\ndevices share a subset of configuration options for resource control of spawned processes.\nInternally, this relies on the Linux Control Groups (cgroups) kernel concept for organizing\nprocesses in a hierarchical tree of named groups for the purpose of resource management.\n\nThis man page lists the configuration options shared by those six unit types. See\nsystemd.unit(5) for the common options of all unit configuration files, and systemd.slice(5),\nsystemd.scope(5), systemd.service(5), systemd.socket(5), systemd.mount(5), and\nsystemd.swap(5) for more information on the specific unit configuration files. The resource\ncontrol configuration options are configured in the [Slice], [Scope], [Service], [Socket],\n[Mount], or [Swap] sections, depending on the unit type.\n\nIn addition, options which control resources available to programs executed by systemd are\nlisted in systemd.exec(5). Those options complement options listed here.\n\nSee the New Control Group Interfaces[1] for an introduction on how to make use of resource\ncontrol APIs from programs.\n", "subsections": [ { "name": "Setting resource controls for a group of related units", "content": "As described in systemd.unit(5), the settings listed here may be set through the main file of\na unit and drop-in snippets in *.d/ directories. The list of directories searched for\ndrop-ins includes names formed by repeatedly truncating the unit name after all dashes. This\nis particularly convenient to set resource limits for a group of units with similar names.\n\nFor example, every user gets their own slice user-nnn.slice. Drop-ins with local\nconfiguration that affect user 1000 may be placed in /etc/systemd/system/user-1000.slice,\n/etc/systemd/system/user-1000.slice.d/*.conf, but also\n/etc/systemd/system/user-.slice.d/*.conf. This last directory applies to all user slices.\n" } ] }, "IMPLICIT DEPENDENCIES": { "content": "The following dependencies are implicitly added:\n\n• Units with the Slice= setting set automatically acquire Requires= and After= dependencies\non the specified slice unit.\n", "subsections": [] }, "UNIFIED AND LEGACY CONTROL GROUP HIERARCHIES": { "content": "The unified control group hierarchy is the new version of kernel control group interface, see\nControl Groups v2[2]. Depending on the resource type, there are differences in resource\ncontrol capabilities. Also, because of interface changes, some resource types have separate\nset of options on the unified hierarchy.\n\nCPU\nCPUWeight= and StartupCPUWeight= replace CPUShares= and StartupCPUShares=, respectively.\n\nThe \"cpuacct\" controller does not exist separately on the unified hierarchy.\n\nMemory\nMemoryMax= replaces MemoryLimit=. MemoryLow= and MemoryHigh= are effective only on\nunified hierarchy.\n\nIO\n\"IO\"-prefixed settings are a superset of and replace \"BlockIO\"-prefixed ones. On unified\nhierarchy, IO resource control also applies to buffered writes.\n\nTo ease the transition, there is best-effort translation between the two versions of\nsettings. For each controller, if any of the settings for the unified hierarchy are present,\nall settings for the legacy hierarchy are ignored. If the resulting settings are for the\nother type of hierarchy, the configurations are translated before application.\n\nLegacy control group hierarchy (see Control Groups version 1[3]), also called cgroup-v1,\ndoesn't allow safe delegation of controllers to unprivileged processes. If the system uses\nthe legacy control group hierarchy, resource control is disabled for the systemd user\ninstance, see systemd(1).\n", "subsections": [] }, "OPTIONS": { "content": "Units of the types listed above can have settings for resource control configuration:\n\nCPUAccounting=\nTurn on CPU usage accounting for this unit. Takes a boolean argument. Note that turning\non CPU accounting for one unit will also implicitly turn it on for all units contained in\nthe same slice and for all its parent slices and the units contained therein. The system\ndefault for this setting may be controlled with DefaultCPUAccounting= in systemd-\nsystem.conf(5).\n\nCPUWeight=weight, StartupCPUWeight=weight\nAssign the specified CPU time weight to the processes executed, if the unified control\ngroup hierarchy is used on the system. These options take an integer value and control\nthe \"cpu.weight\" control group attribute. The allowed range is 1 to 10000. Defaults to\n100. For details about this control group attribute, see Control Groups v2[2] and CFS\nScheduler[4]. The available CPU time is split up among all units within one slice\nrelative to their CPU time weight. A higher weight means more CPU time, a lower weight\nmeans less.\n\nWhile StartupCPUWeight= only applies to the startup phase of the system, CPUWeight=\napplies to normal runtime of the system, and if the former is not set also to the startup\nphase. Using StartupCPUWeight= allows prioritizing specific services at boot-up\ndifferently than during normal runtime.\n\nThese settings replace CPUShares= and StartupCPUShares=.\n\nCPUQuota=\nAssign the specified CPU time quota to the processes executed. Takes a percentage value,\nsuffixed with \"%\". The percentage specifies how much CPU time the unit shall get at\nmaximum, relative to the total CPU time available on one CPU. Use values > 100% for\nallotting CPU time on more than one CPU. This controls the \"cpu.max\" attribute on the\nunified control group hierarchy and \"cpu.cfsquotaus\" on legacy. For details about these\ncontrol group attributes, see Control Groups v2[2] and sched-bwc.txt[5]. Setting\nCPUQuota= to an empty value unsets the quota.\n\nExample: CPUQuota=20% ensures that the executed processes will never get more than 20%\nCPU time on one CPU.\n\nCPUQuotaPeriodSec=\nAssign the duration over which the CPU time quota specified by CPUQuota= is measured.\nTakes a time duration value in seconds, with an optional suffix such as \"ms\" for\nmilliseconds (or \"s\" for seconds.) The default setting is 100ms. The period is clamped to\nthe range supported by the kernel, which is [1ms, 1000ms]. Additionally, the period is\nadjusted up so that the quota interval is also at least 1ms. Setting CPUQuotaPeriodSec=\nto an empty value resets it to the default.\n\nThis controls the second field of \"cpu.max\" attribute on the unified control group\nhierarchy and \"cpu.cfsperiodus\" on legacy. For details about these control group\nattributes, see Control Groups v2[2] and CFS Scheduler[4].\n\nExample: CPUQuotaPeriodSec=10ms to request that the CPU quota is measured in periods of\n10ms.\n\nAllowedCPUs=\nRestrict processes to be executed on specific CPUs. Takes a list of CPU indices or ranges\nseparated by either whitespace or commas. CPU ranges are specified by the lower and upper\nCPU indices separated by a dash.\n\nSetting AllowedCPUs= doesn't guarantee that all of the CPUs will be used by the processes\nas it may be limited by parent units. The effective configuration is reported as\nEffectiveCPUs=.\n\nThis setting is supported only with the unified control group hierarchy.\n\nAllowedMemoryNodes=\nRestrict processes to be executed on specific memory NUMA nodes. Takes a list of memory\nNUMA nodes indices or ranges separated by either whitespace or commas. Memory NUMA nodes\nranges are specified by the lower and upper NUMA nodes indices separated by a dash.\n\nSetting AllowedMemoryNodes= doesn't guarantee that all of the memory NUMA nodes will be\nused by the processes as it may be limited by parent units. The effective configuration\nis reported as EffectiveMemoryNodes=.\n\nThis setting is supported only with the unified control group hierarchy.\n\nMemoryAccounting=\nTurn on process and kernel memory accounting for this unit. Takes a boolean argument.\nNote that turning on memory accounting for one unit will also implicitly turn it on for\nall units contained in the same slice and for all its parent slices and the units\ncontained therein. The system default for this setting may be controlled with\nDefaultMemoryAccounting= in systemd-system.conf(5).\n\nMemoryMin=bytes, MemoryLow=bytes\nSpecify the memory usage protection of the executed processes in this unit. When\nreclaiming memory, the unit is treated as if it was using less memory resulting in memory\nto be preferentially reclaimed from unprotected units. Using MemoryLow= results in a\nweaker protection where memory may still be reclaimed to avoid invoking the OOM killer in\ncase there is no other reclaimable memory.\n\nFor a protection to be effective, it is generally required to set a corresponding\nallocation on all ancestors, which is then distributed between children (with the\nexception of the root slice). Any MemoryMin= or MemoryLow= allocation that is not\nexplicitly distributed to specific children is used to create a shared protection for all\nchildren. As this is a shared protection, the children will freely compete for the\nmemory.\n\nTakes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified\nmemory size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base\n1024), respectively. Alternatively, a percentage value may be specified, which is taken\nrelative to the installed physical memory on the system. If assigned the special value\n\"infinity\", all available memory is protected, which may be useful in order to always\ninherit all of the protection afforded by ancestors. This controls the \"memory.min\" or\n\"memory.low\" control group attribute. For details about this control group attribute, see\nMemory Interface Files[6].\n\nThis setting is supported only if the unified control group hierarchy is used and\ndisables MemoryLimit=.\n\nUnits may have their children use a default \"memory.min\" or \"memory.low\" value by\nspecifying DefaultMemoryMin= or DefaultMemoryLow=, which has the same semantics as\nMemoryMin= and MemoryLow=. This setting does not affect \"memory.min\" or \"memory.low\" in\nthe unit itself. Using it to set a default child allocation is only useful on kernels\nolder than 5.7, which do not support the \"memoryrecursiveprot\" cgroup2 mount option.\n\nMemoryHigh=bytes\nSpecify the throttling limit on memory usage of the executed processes in this unit.\nMemory usage may go above the limit if unavoidable, but the processes are heavily slowed\ndown and memory is taken away aggressively in such cases. This is the main mechanism to\ncontrol memory usage of a unit.\n\nTakes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified\nmemory size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base\n1024), respectively. Alternatively, a percentage value may be specified, which is taken\nrelative to the installed physical memory on the system. If assigned the special value\n\"infinity\", no memory throttling is applied. This controls the \"memory.high\" control\ngroup attribute. For details about this control group attribute, see Memory Interface\nFiles[6].\n\nThis setting is supported only if the unified control group hierarchy is used and\ndisables MemoryLimit=.\n\nMemoryMax=bytes\nSpecify the absolute limit on memory usage of the executed processes in this unit. If\nmemory usage cannot be contained under the limit, out-of-memory killer is invoked inside\nthe unit. It is recommended to use MemoryHigh= as the main control mechanism and use\nMemoryMax= as the last line of defense.\n\nTakes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified\nmemory size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base\n1024), respectively. Alternatively, a percentage value may be specified, which is taken\nrelative to the installed physical memory on the system. If assigned the special value\n\"infinity\", no memory limit is applied. This controls the \"memory.max\" control group\nattribute. For details about this control group attribute, see Memory Interface Files[6].\n\nThis setting replaces MemoryLimit=.\n\nMemorySwapMax=bytes\nSpecify the absolute limit on swap usage of the executed processes in this unit.\n\nTakes a swap size in bytes. If the value is suffixed with K, M, G or T, the specified\nswap size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base\n1024), respectively. If assigned the special value \"infinity\", no swap limit is applied.\nThis controls the \"memory.swap.max\" control group attribute. For details about this\ncontrol group attribute, see Memory Interface Files[6].\n\nThis setting is supported only if the unified control group hierarchy is used and\ndisables MemoryLimit=.\n\nTasksAccounting=\nTurn on task accounting for this unit. Takes a boolean argument. If enabled, the system\nmanager will keep track of the number of tasks in the unit. The number of tasks accounted\nthis way includes both kernel threads and userspace processes, with each thread counting\nindividually. Note that turning on tasks accounting for one unit will also implicitly\nturn it on for all units contained in the same slice and for all its parent slices and\nthe units contained therein. The system default for this setting may be controlled with\nDefaultTasksAccounting= in systemd-system.conf(5).\n\nTasksMax=N\nSpecify the maximum number of tasks that may be created in the unit. This ensures that\nthe number of tasks accounted for the unit (see above) stays below a specific limit. This\neither takes an absolute number of tasks or a percentage value that is taken relative to\nthe configured maximum number of tasks on the system. If assigned the special value\n\"infinity\", no tasks limit is applied. This controls the \"pids.max\" control group\nattribute. For details about this control group attribute, see Process Number\nController[7].\n\nThe system default for this setting may be controlled with DefaultTasksMax= in systemd-\nsystem.conf(5).\n\nIOAccounting=\nTurn on Block I/O accounting for this unit, if the unified control group hierarchy is\nused on the system. Takes a boolean argument. Note that turning on block I/O accounting\nfor one unit will also implicitly turn it on for all units contained in the same slice\nand all for its parent slices and the units contained therein. The system default for\nthis setting may be controlled with DefaultIOAccounting= in systemd-system.conf(5).\n\nThis setting replaces BlockIOAccounting= and disables settings prefixed with BlockIO or\nStartupBlockIO.\n\nIOWeight=weight, StartupIOWeight=weight\nSet the default overall block I/O weight for the executed processes, if the unified\ncontrol group hierarchy is used on the system. Takes a single weight value (between 1 and\n10000) to set the default block I/O weight. This controls the \"io.weight\" control group\nattribute, which defaults to 100. For details about this control group attribute, see IO\nInterface Files[8]. The available I/O bandwidth is split up among all units within one\nslice relative to their block I/O weight. A higher weight means more I/O bandwidth, a\nlower weight means less.\n\nWhile StartupIOWeight= only applies to the startup phase of the system, IOWeight= applies\nto the later runtime of the system, and if the former is not set also to the startup\nphase. This allows prioritizing specific services at boot-up differently than during\nruntime.\n\nThese settings replace BlockIOWeight= and StartupBlockIOWeight= and disable settings\nprefixed with BlockIO or StartupBlockIO.\n\nIODeviceWeight=device weight\nSet the per-device overall block I/O weight for the executed processes, if the unified\ncontrol group hierarchy is used on the system. Takes a space-separated pair of a file\npath and a weight value to specify the device specific weight value, between 1 and 10000.\n(Example: \"/dev/sda 1000\"). The file path may be specified as path to a block device node\nor as any other file, in which case the backing block device of the file system of the\nfile is determined. This controls the \"io.weight\" control group attribute, which defaults\nto 100. Use this option multiple times to set weights for multiple devices. For details\nabout this control group attribute, see IO Interface Files[8].\n\nThis setting replaces BlockIODeviceWeight= and disables settings prefixed with BlockIO or\nStartupBlockIO.\n\nThe specified device node should reference a block device that has an I/O scheduler\nassociated, i.e. should not refer to partition or loopback block devices, but to the\noriginating, physical device. When a path to a regular file or directory is specified it\nis attempted to discover the correct originating device backing the file system of the\nspecified path. This works correctly only for simpler cases, where the file system is\ndirectly placed on a partition or physical block device, or where simple 1:1 encryption\nusing dm-crypt/LUKS is used. This discovery does not cover complex storage and in\nparticular RAID and volume management storage devices.\n\nIOReadBandwidthMax=device bytes, IOWriteBandwidthMax=device bytes\nSet the per-device overall block I/O bandwidth maximum limit for the executed processes,\nif the unified control group hierarchy is used on the system. This limit is not\nwork-conserving and the executed processes are not allowed to use more even if the device\nhas idle capacity. Takes a space-separated pair of a file path and a bandwidth value (in\nbytes per second) to specify the device specific bandwidth. The file path may be a path\nto a block device node, or as any other file in which case the backing block device of\nthe file system of the file is used. If the bandwidth is suffixed with K, M, G, or T, the\nspecified bandwidth is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes,\nrespectively, to the base of 1000. (Example:\n\"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M\"). This controls the \"io.max\" control\ngroup attributes. Use this option multiple times to set bandwidth limits for multiple\ndevices. For details about this control group attribute, see IO Interface Files[8].\n\nThese settings replace BlockIOReadBandwidth= and BlockIOWriteBandwidth= and disable\nsettings prefixed with BlockIO or StartupBlockIO.\n\nSimilar restrictions on block device discovery as for IODeviceWeight= apply, see above.\n\nIOReadIOPSMax=device IOPS, IOWriteIOPSMax=device IOPS\nSet the per-device overall block I/O IOs-Per-Second maximum limit for the executed\nprocesses, if the unified control group hierarchy is used on the system. This limit is\nnot work-conserving and the executed processes are not allowed to use more even if the\ndevice has idle capacity. Takes a space-separated pair of a file path and an IOPS value\nto specify the device specific IOPS. The file path may be a path to a block device node,\nor as any other file in which case the backing block device of the file system of the\nfile is used. If the IOPS is suffixed with K, M, G, or T, the specified IOPS is parsed as\nKiloIOPS, MegaIOPS, GigaIOPS, or TeraIOPS, respectively, to the base of 1000. (Example:\n\"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K\"). This controls the \"io.max\" control\ngroup attributes. Use this option multiple times to set IOPS limits for multiple devices.\nFor details about this control group attribute, see IO Interface Files[8].\n\nThese settings are supported only if the unified control group hierarchy is used and\ndisable settings prefixed with BlockIO or StartupBlockIO.\n\nSimilar restrictions on block device discovery as for IODeviceWeight= apply, see above.\n\nIODeviceLatencyTargetSec=device target\nSet the per-device average target I/O latency for the executed processes, if the unified\ncontrol group hierarchy is used on the system. Takes a file path and a timespan separated\nby a space to specify the device specific latency target. (Example: \"/dev/sda 25ms\"). The\nfile path may be specified as path to a block device node or as any other file, in which\ncase the backing block device of the file system of the file is determined. This controls\nthe \"io.latency\" control group attribute. Use this option multiple times to set latency\ntarget for multiple devices. For details about this control group attribute, see IO\nInterface Files[8].\n\nImplies \"IOAccounting=yes\".\n\nThese settings are supported only if the unified control group hierarchy is used.\n\nSimilar restrictions on block device discovery as for IODeviceWeight= apply, see above.\n\nIPAccounting=\nTakes a boolean argument. If true, turns on IPv4 and IPv6 network traffic accounting for\npackets sent or received by the unit. When this option is turned on, all IPv4 and IPv6\nsockets created by any process of the unit are accounted for.\n\nWhen this option is used in socket units, it applies to all IPv4 and IPv6 sockets\nassociated with it (including both listening and connection sockets where this applies).\nNote that for socket-activated services, this configuration setting and the accounting\ndata of the service unit and the socket unit are kept separate, and displayed separately.\nNo propagation of the setting and the collected statistics is done, in either direction.\nMoreover, any traffic sent or received on any of the socket unit's sockets is accounted\nto the socket unit — and never to the service unit it might have activated, even if the\nsocket is used by it.\n\nThe system default for this setting may be controlled with DefaultIPAccounting= in\nsystemd-system.conf(5).\n\nIPAddressAllow=ADDRESS[/PREFIXLENGTH]..., IPAddressDeny=ADDRESS[/PREFIXLENGTH]...\nTurn on network traffic filtering for IP packets sent and received over AFINET and\nAFINET6 sockets. Both directives take a space separated list of IPv4 or IPv6 addresses,\neach optionally suffixed with an address prefix length in bits after a \"/\" character. If\nthe suffix is omitted, the address is considered a host address, i.e. the filter covers\nthe whole address (32 bits for IPv4, 128 bits for IPv6).\n\nThe access lists configured with this option are applied to all sockets created by\nprocesses of this unit (or in the case of socket units, associated with it). The lists\nare implicitly combined with any lists configured for any of the parent slice units this\nunit might be a member of. By default both access lists are empty. Both ingress and\negress traffic is filtered by these settings. In case of ingress traffic the source IP\naddress is checked against these access lists, in case of egress traffic the destination\nIP address is checked. The following rules are applied in turn:\n\n• Access is granted when the checked IP address matches an entry in the IPAddressAllow=\nlist.\n\n• Otherwise, access is denied when the checked IP address matches an entry in the\nIPAddressDeny= list.\n\n• Otherwise, access is granted.\n\nIn order to implement an allow-listing IP firewall, it is recommended to use a\nIPAddressDeny=any setting on an upper-level slice unit (such as the root slice -.slice or\nthe slice containing all system services system.slice – see systemd.special(7) for\ndetails on these slice units), plus individual per-service IPAddressAllow= lines\npermitting network access to relevant services, and only them.\n\nNote that for socket-activated services, the IP access list configured on the socket unit\napplies to all sockets associated with it directly, but not to any sockets created by the\nultimately activated services for it. Conversely, the IP access list configured for the\nservice is not applied to any sockets passed into the service via socket activation.\nThus, it is usually a good idea to replicate the IP access lists on both the socket and\nthe service unit. Nevertheless, it may make sense to maintain one list more open and the\nother one more restricted, depending on the usecase.\n\nIf these settings are used multiple times in the same unit the specified lists are\ncombined. If an empty string is assigned to these settings the specific access list is\nreset and all previous settings undone.\n\nIn place of explicit IPv4 or IPv6 address and prefix length specifications a small set of\nsymbolic names may be used. The following names are defined:\n\nTable 1. Special address/network names\n┌──────────────┬──────────────────────────┬──────────────────────┐\n│Symbolic Name │ Definition │ Meaning │\n├──────────────┼──────────────────────────┼──────────────────────┤\n│any │ 0.0.0.0/0 ::/0 │ Any host │\n├──────────────┼──────────────────────────┼──────────────────────┤\n│localhost │ 127.0.0.0/8 ::1/128 │ All addresses on the │\n│ │ │ local loopback │\n├──────────────┼──────────────────────────┼──────────────────────┤\n│link-local │ 169.254.0.0/16 fe80::/64 │ All link-local IP │\n│ │ │ addresses │\n├──────────────┼──────────────────────────┼──────────────────────┤\n│multicast │ 224.0.0.0/4 ff00::/8 │ All IP multicasting │\n│ │ │ addresses │\n└──────────────┴──────────────────────────┴──────────────────────┘\nNote that these settings might not be supported on some systems (for example if eBPF\ncontrol group support is not enabled in the underlying kernel or container manager).\nThese settings will have no effect in that case. If compatibility with such systems is\ndesired it is hence recommended to not exclusively rely on them for IP security.\n\nIPIngressFilterPath=BPFFSPROGRAMPATH, IPEgressFilterPath=BPFFSPROGRAMPATH\nAdd custom network traffic filters implemented as BPF programs, applying to all IP\npackets sent and received over AFINET and AFINET6 sockets. Takes an absolute path to a\npinned BPF program in the BPF virtual filesystem (/sys/fs/bpf/).\n\nThe filters configured with this option are applied to all sockets created by processes\nof this unit (or in the case of socket units, associated with it). The filters are loaded\nin addition to filters any of the parent slice units this unit might be a member of as\nwell as any IPAddressAllow= and IPAddressDeny= filters in any of these units. By default\nthere are no filters specified.\n\nIf these settings are used multiple times in the same unit all the specified programs are\nattached. If an empty string is assigned to these settings the program list is reset and\nall previous specified programs ignored.\n\nIf the path BPFFSPROGRAMPATH in IPIngressFilterPath= assignment is already being\nhandled by BPFProgram= ingress hook, e.g. BPFProgram=ingress:BPFFSPROGRAMPATH, the\nassignment will be still considered valid and the program will be attached to a cgroup.\nSame for IPEgressFilterPath= path and egress hook.\n\nNote that for socket-activated services, the IP filter programs configured on the socket\nunit apply to all sockets associated with it directly, but not to any sockets created by\nthe ultimately activated services for it. Conversely, the IP filter programs configured\nfor the service are not applied to any sockets passed into the service via socket\nactivation. Thus, it is usually a good idea, to replicate the IP filter programs on both\nthe socket and the service unit, however it often makes sense to maintain one\nconfiguration more open and the other one more restricted, depending on the usecase.\n\nNote that these settings might not be supported on some systems (for example if eBPF\ncontrol group support is not enabled in the underlying kernel or container manager).\nThese settings will fail the service in that case. If compatibility with such systems is\ndesired it is hence recommended to attach your filter manually (requires Delegate=yes)\ninstead of using this setting.\n\nBPFProgram=type:program-path\nAdd a custom cgroup BPF program.\n\nBPFProgram= allows attaching BPF hooks to the cgroup of a systemd unit. (This generalizes\nthe functionality exposed via IPEgressFilterPath= for egress and IPIngressFilterPath= for\ningress.) Cgroup-bpf hooks in the form of BPF programs loaded to the BPF filesystem are\nattached with cgroup-bpf attach flags determined by the unit. For details about\nattachment types and flags see\nhttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf.h.\nFor general BPF documentation please refer to\nhttps://www.kernel.org/doc/html/latest/bpf/index.html.\n\nThe specification of BPF program consists of a type followed by a program-path with \":\"\nas the separator: type:program-path.\n\ntype is the string name of BPF attach type also used in bpftool. type can be one of\negress, ingress, sockcreate, sockops, device, bind4, bind6, connect4, connect6,\npostbind4, postbind6, sendmsg4, sendmsg6, sysctl, recvmsg4, recvmsg6, getsockopt,\nsetsockopt.\n\nSetting BPFProgram= to an empty value makes previous assignments ineffective.\n\nMultiple assignments of the same type:program-path value have the same effect as a single\nassignment: the program with the path program-path will be attached to cgroup hook type\njust once.\n\nIf BPF egress pinned to program-path path is already being handled by\nIPEgressFilterPath=, BPFProgram= assignment will be considered valid and BPFProgram= will\nbe attached to a cgroup. Similarly for ingress hook and IPIngressFilterPath= assignment.\n\nBPF programs passed with BPFProgram= are attached to the cgroup of a unit with BPF attach\nflag multi, that allows further attachments of the same type within cgroup hierarchy\ntopped by the unit cgroup.\n\nExamples:\n\nBPFProgram=egress:/sys/fs/bpf/egress-hook\nBPFProgram=bind6:/sys/fs/bpf/sock-addr-hook\n\nSocketBindAllow=bind-rule, SocketBindDeny=bind-rule\nAllow or deny binding a socket address to a socket by matching it with the bind-rule and\napplying a corresponding action if there is a match.\n\nbind-rule describes socket properties such as address-family, transport-protocol and\nip-ports.\n\nbind-rule := { [address-family:][transport-protocol:][ip-ports] | any }\n\naddress-family := { ipv4 | ipv6 }\n\ntransport-protocol := { tcp | udp }\n\nip-ports := { ip-port | ip-port-range }\n\nAn optional address-family expects ipv4 or ipv6 values. If not specified, a rule will be\nmatched for both IPv4 and IPv6 addresses and applied depending on other socket fields,\ne.g. transport-protocol, ip-port.\n\nAn optional transport-protocol expects tcp or udp transport protocol names. If not\nspecified, a rule will be matched for any transport protocol.\n\nAn optional ip-port value must lie within 1...65535 interval inclusively, i.e. dynamic\nport 0 is not allowed. A range of sequential ports is described by ip-port-range :=\nip-port-low-ip-port-high, where ip-port-low is smaller than or equal to ip-port-high and\nboth are within 1...65535 inclusively.\n\nA special value any can be used to apply a rule to any address family, transport protocol\nand any port with a positive value.\n\nTo allow multiple rules assign SocketBindAllow= or SocketBindDeny= multiple times. To\nclear the existing assignments pass an empty SocketBindAllow= or SocketBindDeny=\nassignment.\n\nFor each of SocketBindAllow= and SocketBindDeny=, maximum allowed number of assignments\nis 128.\n\n• Binding to a socket is allowed when a socket address matches an entry in the\nSocketBindAllow= list.\n\n• Otherwise, binding is denied when the socket address matches an entry in the\nSocketBindDeny= list.\n\n• Otherwise, binding is allowed.\n\nThe feature is implemented with cgroup/bind4 and cgroup/bind6 cgroup-bpf hooks.\n\nExamples:\n\n...\n# Allow binding IPv6 socket addresses with a port greater than or equal to 10000.\n[Service]\nSocketBindAllow=ipv6:10000-65535\nSocketBindDeny=any\n...\n# Allow binding IPv4 and IPv6 socket addresses with 1234 and 4321 ports.\n[Service]\nSocketBindAllow=1234\nSocketBindAllow=4321\nSocketBindDeny=any\n...\n# Deny binding IPv6 socket addresses.\n[Service]\nSocketBindDeny=ipv6\n...\n# Deny binding IPv4 and IPv6 socket addresses.\n[Service]\nSocketBindDeny=any\n...\n# Allow binding only over TCP\n[Service]\nSocketBindAllow=tcp\nSocketBindDeny=any\n...\n# Allow binding only over IPv6/TCP\n[Service]\nSocketBindAllow=ipv6:tcp\nSocketBindDeny=any\n...\n# Allow binding ports within 10000-65535 range over IPv4/UDP.\n[Service]\nSocketBindAllow=ipv4:udp:10000-65535\nSocketBindDeny=any\n...\n\nDeviceAllow=\nControl access to specific device nodes by the executed processes. Takes two\nspace-separated strings: a device node specifier followed by a combination of r, w, m to\ncontrol reading, writing, or creation of the specific device node(s) by the unit (mknod),\nrespectively. On cgroup-v1 this controls the \"devices.allow\" control group attribute. For\ndetails about this control group attribute, see Device Whitelist Controller[9]. In the\nunified cgroup hierarchy this functionality is implemented using eBPF filtering.\n\nThe device node specifier is either a path to a device node in the file system, starting\nwith /dev/, or a string starting with either \"char-\" or \"block-\" followed by a device\ngroup name, as listed in /proc/devices. The latter is useful to allow-list all current\nand future devices belonging to a specific device group at once. The device group is\nmatched according to filename globbing rules, you may hence use the \"*\" and \"?\"\nwildcards. (Note that such globbing wildcards are not available for device node path\nspecifications!) In order to match device nodes by numeric major/minor, use device node\npaths in the /dev/char/ and /dev/block/ directories. However, matching devices by\nmajor/minor is generally not recommended as assignments are neither stable nor portable\nbetween systems or different kernel versions.\n\nExamples: /dev/sda5 is a path to a device node, referring to an ATA or SCSI block device.\n\"char-pts\" and \"char-alsa\" are specifiers for all pseudo TTYs and all ALSA sound devices,\nrespectively. \"char-cpu/*\" is a specifier matching all CPU related device groups.\n\nNote that allow lists defined this way should only reference device groups which are\nresolvable at the time the unit is started. Any device groups not resolvable then are not\nadded to the device allow list. In order to work around this limitation, consider\nextending service units with a pair of After=modprobe@xyz.service and\nWants=modprobe@xyz.service lines that load the necessary kernel module implementing the\ndevice group if missing. Example:\n\n...\n[Unit]\nWants=modprobe@loop.service\nAfter=modprobe@loop.service\n\n[Service]\nDeviceAllow=block-loop\nDeviceAllow=/dev/loop-control\n...\n\nDevicePolicy=auto|closed|strict\nControl the policy for allowing device access:\n\nstrict\nmeans to only allow types of access that are explicitly specified.\n\nclosed\nin addition, allows access to standard pseudo devices including /dev/null, /dev/zero,\n/dev/full, /dev/random, and /dev/urandom.\n\nauto\nin addition, allows access to all devices if no explicit DeviceAllow= is present.\nThis is the default.\n\nSlice=\nThe name of the slice unit to place the unit in. Defaults to system.slice for all\nnon-instantiated units of all unit types (except for slice units themselves see below).\nInstance units are by default placed in a subslice of system.slice that is named after\nthe template name.\n\nThis option may be used to arrange systemd units in a hierarchy of slices each of which\nmight have resource settings applied.\n\nFor units of type slice, the only accepted value for this setting is the parent slice.\nSince the name of a slice unit implies the parent slice, it is hence redundant to ever\nset this parameter directly for slice units.\n\nSpecial care should be taken when relying on the default slice assignment in templated\nservice units that have DefaultDependencies=no set, see systemd.service(5), section\n\"Default Dependencies\" for details.\n\nDelegate=\nTurns on delegation of further resource control partitioning to processes of the unit.\nUnits where this is enabled may create and manage their own private subhierarchy of\ncontrol groups below the control group of the unit itself. For unprivileged services\n(i.e. those using the User= setting) the unit's control group will be made accessible to\nthe relevant user. When enabled the service manager will refrain from manipulating\ncontrol groups or moving processes below the unit's control group, so that a clear\nconcept of ownership is established: the control group tree above the unit's control\ngroup (i.e. towards the root control group) is owned and managed by the service manager\nof the host, while the control group tree below the unit's control group is owned and\nmanaged by the unit itself. Takes either a boolean argument or a list of control group\ncontroller names. If true, delegation is turned on, and all supported controllers are\nenabled for the unit, making them available to the unit's processes for management. If\nfalse, delegation is turned off entirely (and no additional controllers are enabled). If\nset to a list of controllers, delegation is turned on, and the specified controllers are\nenabled for the unit. Note that additional controllers than the ones specified might be\nmade available as well, depending on configuration of the containing slice unit or other\nunits contained in it. Note that assigning the empty string will enable delegation, but\nreset the list of controllers, all assignments prior to this will have no effect.\nDefaults to false.\n\nNote that controller delegation to less privileged code is only safe on the unified\ncontrol group hierarchy. Accordingly, access to the specified controllers will not be\ngranted to unprivileged services on the legacy hierarchy, even when requested.\n\nThe following controller names may be specified: cpu, cpuacct, cpuset, io, blkio, memory,\ndevices, pids, bpf-firewall, and bpf-devices.\n\nNot all of these controllers are available on all kernels however, and some are specific\nto the unified hierarchy while others are specific to the legacy hierarchy. Also note\nthat the kernel might support further controllers, which aren't covered here yet as\ndelegation is either not supported at all for them or not defined cleanly.\n\nFor further details on the delegation model consult Control Group APIs and\nDelegation[10].\n\nDisableControllers=\nDisables controllers from being enabled for a unit's children. If a controller listed is\nalready in use in its subtree, the controller will be removed from the subtree. This can\nbe used to avoid child units being able to implicitly or explicitly enable a controller.\nDefaults to not disabling any controllers.\n\nIt may not be possible to successfully disable a controller if the unit or any child of\nthe unit in question delegates controllers to its children, as any delegated subtree of\nthe cgroup hierarchy is unmanaged by systemd.\n\nMultiple controllers may be specified, separated by spaces. You may also pass\nDisableControllers= multiple times, in which case each new instance adds another\ncontroller to disable. Passing DisableControllers= by itself with no controller name\npresent resets the disabled controller list.\n\nThe following controller names may be specified: cpu, cpuacct, cpuset, io, blkio, memory,\ndevices, pids, bpf-firewall, and bpf-devices.\n\nManagedOOMSwap=auto|kill, ManagedOOMMemoryPressure=auto|kill\nSpecifies how systemd-oomd.service(8) will act on this unit's cgroups. Defaults to auto.\n\nWhen set to kill, systemd-oomd will actively monitor this unit's cgroup metrics to decide\nwhether it needs to act. If the cgroup passes the limits set by oomd.conf(5) or its\noverrides, systemd-oomd will send a SIGKILL to all of the processes under the chosen\ncandidate cgroup. Note that only descendant cgroups can be eligible candidates for\nkilling; the unit that set its property to kill is not a candidate (unless one of its\nancestors set their property to kill). You can find more details on candidates and kill\nbehavior at systemd-oomd.service(8) and oomd.conf(5). Setting either of these properties\nto kill will also automatically acquire After= and Wants= dependencies on\nsystemd-oomd.service unless DefaultDependencies=no.\n\nWhen set to auto, systemd-oomd will not actively use this cgroup's data for monitoring\nand detection. However, if an ancestor cgroup has one of these properties set to kill, a\nunit with auto can still be an eligible candidate for systemd-oomd to act on.\n\nManagedOOMMemoryPressureLimit=\nOverrides the default memory pressure limit set by oomd.conf(5) for this unit (cgroup).\nTakes a percentage value between 0% and 100%, inclusive. This property is ignored unless\nManagedOOMMemoryPressure=kill. Defaults to 0%, which means to use the default set by\noomd.conf(5).\n\nManagedOOMPreference=none|avoid|omit\nAllows deprioritizing or omitting this unit's cgroup as a candidate when systemd-oomd\nneeds to act. Requires support for extended attributes (see xattr(7)) in order to use\navoid or omit. Additionally, systemd-oomd will ignore these extended attributes if the\nunit's cgroup is not owned by the root user.\n\nIf this property is set to avoid, the service manager will convey this to systemd-oomd,\nwhich will only select this cgroup if there are no other viable candidates.\n\nIf this property is set to omit, the service manager will convey this to systemd-oomd,\nwhich will ignore this cgroup as a candidate and will not perform any actions on it.\n\nIt is recommended to use avoid and omit sparingly, as it can adversely affect\nsystemd-oomd's kill behavior. Also note that these extended attributes are not applied\nrecursively to cgroups under this unit's cgroup.\n\nDefaults to none which means systemd-oomd will rank this unit's cgroup as defined in\nsystemd-oomd.service(8) and oomd.conf(5).\n", "subsections": [] }, "DEPRECATED OPTIONS": { "content": "The following options are deprecated. Use the indicated superseding options instead:\n\nCPUShares=weight, StartupCPUShares=weight\nAssign the specified CPU time share weight to the processes executed. These options take\nan integer value and control the \"cpu.shares\" control group attribute. The allowed range\nis 2 to 262144. Defaults to 1024. For details about this control group attribute, see CFS\nScheduler[4]. The available CPU time is split up among all units within one slice\nrelative to their CPU time share weight.\n\nWhile StartupCPUShares= only applies to the startup phase of the system, CPUShares=\napplies to normal runtime of the system, and if the former is not set also to the startup\nphase. Using StartupCPUShares= allows prioritizing specific services at boot-up\ndifferently than during normal runtime.\n\nImplies \"CPUAccounting=yes\".\n\nThese settings are deprecated. Use CPUWeight= and StartupCPUWeight= instead.\n\nMemoryLimit=bytes\nSpecify the limit on maximum memory usage of the executed processes. The limit specifies\nhow much process and kernel memory can be used by tasks in this unit. Takes a memory size\nin bytes. If the value is suffixed with K, M, G or T, the specified memory size is parsed\nas Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively.\nAlternatively, a percentage value may be specified, which is taken relative to the\ninstalled physical memory on the system. If assigned the special value \"infinity\", no\nmemory limit is applied. This controls the \"memory.limitinbytes\" control group\nattribute. For details about this control group attribute, see Memory Resource\nController[11].\n\nImplies \"MemoryAccounting=yes\".\n\nThis setting is deprecated. Use MemoryMax= instead.\n\nBlockIOAccounting=\nTurn on Block I/O accounting for this unit, if the legacy control group hierarchy is used\non the system. Takes a boolean argument. Note that turning on block I/O accounting for\none unit will also implicitly turn it on for all units contained in the same slice and\nall for its parent slices and the units contained therein. The system default for this\nsetting may be controlled with DefaultBlockIOAccounting= in systemd-system.conf(5).\n\nThis setting is deprecated. Use IOAccounting= instead.\n\nBlockIOWeight=weight, StartupBlockIOWeight=weight\nSet the default overall block I/O weight for the executed processes, if the legacy\ncontrol group hierarchy is used on the system. Takes a single weight value (between 10\nand 1000) to set the default block I/O weight. This controls the \"blkio.weight\" control\ngroup attribute, which defaults to 500. For details about this control group attribute,\nsee Block IO Controller[12]. The available I/O bandwidth is split up among all units\nwithin one slice relative to their block I/O weight.\n\nWhile StartupBlockIOWeight= only applies to the startup phase of the system,\nBlockIOWeight= applies to the later runtime of the system, and if the former is not set\nalso to the startup phase. This allows prioritizing specific services at boot-up\ndifferently than during runtime.\n\nImplies \"BlockIOAccounting=yes\".\n\nThese settings are deprecated. Use IOWeight= and StartupIOWeight= instead.\n\nBlockIODeviceWeight=device weight\nSet the per-device overall block I/O weight for the executed processes, if the legacy\ncontrol group hierarchy is used on the system. Takes a space-separated pair of a file\npath and a weight value to specify the device specific weight value, between 10 and 1000.\n(Example: \"/dev/sda 500\"). The file path may be specified as path to a block device node\nor as any other file, in which case the backing block device of the file system of the\nfile is determined. This controls the \"blkio.weightdevice\" control group attribute,\nwhich defaults to 1000. Use this option multiple times to set weights for multiple\ndevices. For details about this control group attribute, see Block IO Controller[12].\n\nImplies \"BlockIOAccounting=yes\".\n\nThis setting is deprecated. Use IODeviceWeight= instead.\n\nBlockIOReadBandwidth=device bytes, BlockIOWriteBandwidth=device bytes\nSet the per-device overall block I/O bandwidth limit for the executed processes, if the\nlegacy control group hierarchy is used on the system. Takes a space-separated pair of a\nfile path and a bandwidth value (in bytes per second) to specify the device specific\nbandwidth. The file path may be a path to a block device node, or as any other file in\nwhich case the backing block device of the file system of the file is used. If the\nbandwidth is suffixed with K, M, G, or T, the specified bandwidth is parsed as Kilobytes,\nMegabytes, Gigabytes, or Terabytes, respectively, to the base of 1000. (Example:\n\"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M\"). This controls the\n\"blkio.throttle.readbpsdevice\" and \"blkio.throttle.writebpsdevice\" control group\nattributes. Use this option multiple times to set bandwidth limits for multiple devices.\nFor details about these control group attributes, see Block IO Controller[12].\n\nImplies \"BlockIOAccounting=yes\".\n\nThese settings are deprecated. Use IOReadBandwidthMax= and IOWriteBandwidthMax= instead.\n", "subsections": [] }, "SEE ALSO": { "content": "systemd(1), systemd-system.conf(5), systemd.unit(5), systemd.service(5), systemd.slice(5),\nsystemd.scope(5), systemd.socket(5), systemd.mount(5), systemd.swap(5), systemd.exec(5),\nsystemd.directives(7), systemd.special(7), systemd-oomd.service(8), The documentation for\ncontrol groups and specific controllers in the Linux kernel: Control Groups v2[2].\n", "subsections": [] }, "NOTES": { "content": "1. New Control Group Interfaces\nhttps://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/\n\n2. Control Groups v2\nhttps://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html\n\n3. Control Groups version 1\nhttps://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/\n\n4. CFS Scheduler\nhttps://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html\n\n5. sched-bwc.txt\nhttps://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt\n\n6. Memory Interface Files\nhttps://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-files\n\n7. Process Number Controller\nhttps://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/pids.html\n\n8. IO Interface Files\nhttps://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#io-interface-files\n\n9. Device Whitelist Controller\nhttps://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/devices.html\n\n10. Control Group APIs and Delegation\nhttps://systemd.io/CGROUPDELEGATION\n\n11. Memory Resource Controller\nhttps://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/memory.html\n\n12. Block IO Controller\nhttps://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/blkio-controller.html\n\n\n\nsystemd 249 SYSTEMD.RESOURCE-CONTROL(5)", "subsections": [] } } } }