{
    "mode": "info",
    "parameter": "SYSTEMD.RESOURCE-CONTROL",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/info/SYSTEMD.RESOURCE-CONTROL/json",
    "generated": "2026-07-05T11:49:00Z",
    "synopsis": "slice.slice, scope.scope, service.service, socket.socket, mount.mount,\nswap.swap",
    "sections": {
        "NAME": {
            "content": "systemd.resource-control - Resource control unit settings\n",
            "subsections": []
        },
        "SYNOPSIS": {
            "content": "slice.slice, scope.scope, service.service, socket.socket, mount.mount,\nswap.swap\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "Unit configuration files for services, slices, scopes, sockets, mount\npoints, and swap devices share a subset of configuration options for\nresource control of spawned processes. Internally, this relies on the\nLinux Control Groups (cgroups) kernel concept for organizing processes\nin a hierarchical tree of named groups for the purpose of resource\nmanagement.\n\nThis man page lists the configuration options shared by those six unit\ntypes. See systemd.unit(5) for the common options of all unit\nconfiguration files, and systemd.slice(5), systemd.scope(5),\nsystemd.service(5), systemd.socket(5), systemd.mount(5), and\nsystemd.swap(5) for more information on the specific unit configuration\nfiles. The resource control configuration options are configured in the\n[Slice], [Scope], [Service], [Socket], [Mount], or [Swap] sections,\ndepending on the unit type.\n\nIn addition, options which control resources available to programs\nexecuted by systemd are listed in systemd.exec(5). Those options\ncomplement options listed here.\n\nSee the New Control Group Interfaces[1] for an introduction on how to\nmake use of resource control APIs from programs.\n\nSetting resource controls for a group of related units\nAs described in systemd.unit(5), the settings listed here may be set\nthrough the main file of a unit and drop-in snippets in *.d/\ndirectories. The list of directories searched for drop-ins includes\nnames formed by repeatedly truncating the unit name after all dashes.\nThis is particularly convenient to set resource limits for a group of\nunits with similar names.\n\nFor example, every user gets their own slice user-nnn.slice. Drop-ins\nwith local configuration that affect user 1000 may be placed in\n/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\nto all user slices.\n",
            "subsections": []
        },
        "IMPLICIT DEPENDENCIES": {
            "content": "The following dependencies are implicitly added:\n\no   Units with the Slice= setting set automatically acquire Requires=\nand After= dependencies on the specified slice unit.\n",
            "subsections": []
        },
        "UNIFIED AND LEGACY CONTROL GROUP HIERARCHIES": {
            "content": "The unified control group hierarchy is the new version of kernel\ncontrol group interface, see Control Groups v2[2]. Depending on the\nresource type, there are differences in resource control capabilities.\nAlso, because of interface changes, some resource types have separate\nset of options on the unified hierarchy.\n\nCPU\nCPUWeight= and StartupCPUWeight= replace CPUShares= and\nStartupCPUShares=, respectively.\n\nThe \"cpuacct\" controller does not exist separately on the unified\nhierarchy.\n\nMemory\nMemoryMax= replaces MemoryLimit=.  MemoryLow= and MemoryHigh= are\neffective only on unified hierarchy.\n\nIO\n\"IO\"-prefixed settings are a superset of and replace\n\"BlockIO\"-prefixed ones. On unified hierarchy, IO resource control\nalso applies to buffered writes.\n\nTo ease the transition, there is best-effort translation between the\ntwo versions of settings. For each controller, if any of the settings\nfor the unified hierarchy are present, all settings for the legacy\nhierarchy are ignored. If the resulting settings are for the other type\nof hierarchy, the configurations are translated before application.\n\nLegacy control group hierarchy (see Control Groups version 1[3]), also\ncalled cgroup-v1, doesn't allow safe delegation of controllers to\nunprivileged processes. If the system uses the legacy control group\nhierarchy, resource control is disabled for the systemd user instance,\nsee systemd(1).\n",
            "subsections": []
        },
        "OPTIONS": {
            "content": "Units of the types listed above can have settings for resource control\nconfiguration:\n\nCPUAccounting=\nTurn on CPU usage accounting for this unit. Takes a boolean\nargument. Note that turning on CPU accounting for one unit will\nalso implicitly turn it on for all units contained in the same\nslice and for all its parent slices and the units contained\ntherein. The system default for this setting may be controlled with\nDefaultCPUAccounting= in systemd-system.conf(5).\n\nCPUWeight=weight, StartupCPUWeight=weight\nAssign the specified CPU time weight to the processes executed, if\nthe unified control group hierarchy is used on the system. These\noptions take an integer value and control the \"cpu.weight\" control\ngroup attribute. The allowed range is 1 to 10000. Defaults to 100.\nFor details about this control group attribute, see Control Groups\nv2[2] and CFS Scheduler[4]. The available CPU time is split up\namong all units within one slice relative to their CPU time weight.\nA higher weight means more CPU time, a lower weight means less.\n\nWhile StartupCPUWeight= only applies to the startup phase of the\nsystem, CPUWeight= applies to normal runtime of the system, and if\nthe former is not set also to the startup phase. Using\nStartupCPUWeight= 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.\nTakes a percentage value, suffixed with \"%\". The percentage\nspecifies how much CPU time the unit shall get at maximum, relative\nto the total CPU time available on one CPU. Use values > 100% for\nallotting CPU time on more than one CPU. This controls the\n\"cpu.max\" attribute on the unified control group hierarchy and\n\"cpu.cfsquotaus\" on legacy. For details about these control group\nattributes, 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\nnever get more than 20% CPU time on one CPU.\n\nCPUQuotaPeriodSec=\nAssign the duration over which the CPU time quota specified by\nCPUQuota= is measured. Takes a time duration value in seconds, with\nan optional suffix such as \"ms\" for milliseconds (or \"s\" for\nseconds.) The default setting is 100ms. The period is clamped to\nthe range supported by the kernel, which is [1ms, 1000ms].\nAdditionally, the period is adjusted up so that the quota interval\nis also at least 1ms. Setting CPUQuotaPeriodSec= to an empty value\nresets it to the default.\n\nThis controls the second field of \"cpu.max\" attribute on the\nunified control group hierarchy and \"cpu.cfsperiodus\" on legacy.\nFor details about these control group attributes, see Control\nGroups v2[2] and CFS Scheduler[4].\n\nExample: CPUQuotaPeriodSec=10ms to request that the CPU quota is\nmeasured in periods of 10ms.\n\nAllowedCPUs=\nRestrict processes to be executed on specific CPUs. Takes a list of\nCPU indices or ranges separated by either whitespace or commas. CPU\nranges are specified by the lower and upper CPU indices separated\nby a dash.\n\nSetting AllowedCPUs= doesn't guarantee that all of the CPUs will be\nused by the processes as it may be limited by parent units. The\neffective configuration is reported as EffectiveCPUs=.\n\nThis setting is supported only with the unified control group\nhierarchy.\n\nAllowedMemoryNodes=\nRestrict processes to be executed on specific memory NUMA nodes.\nTakes a list of memory NUMA nodes indices or ranges separated by\neither whitespace or commas. Memory NUMA nodes ranges are specified\nby the lower and upper NUMA nodes indices separated by a dash.\n\nSetting AllowedMemoryNodes= doesn't guarantee that all of the\nmemory NUMA nodes will be used by the processes as it may be\nlimited by parent units. The effective configuration is reported as\nEffectiveMemoryNodes=.\n\nThis setting is supported only with the unified control group\nhierarchy.\n\nMemoryAccounting=\nTurn on process and kernel memory accounting for this unit. Takes a\nboolean argument. Note that turning on memory accounting for one\nunit will also implicitly turn it on for all units contained in the\nsame slice and for all its parent slices and the units contained\ntherein. 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\nthis unit. When reclaiming memory, the unit is treated as if it was\nusing less memory resulting in memory to be preferentially\nreclaimed from unprotected units. Using MemoryLow= results in a\nweaker protection where memory may still be reclaimed to avoid\ninvoking the OOM killer in case there is no other reclaimable\nmemory.\n\nFor a protection to be effective, it is generally required to set a\ncorresponding allocation on all ancestors, which is then\ndistributed between children (with the exception of the root\nslice). Any MemoryMin= or MemoryLow= allocation that is not\nexplicitly distributed to specific children is used to create a\nshared protection for all children. As this is a shared protection,\nthe children will freely compete for the memory.\n\nTakes a memory size in bytes. If the value is suffixed with K, M, G\nor T, the specified memory size is parsed as Kilobytes, Megabytes,\nGigabytes, or Terabytes (with the base 1024), respectively.\nAlternatively, a percentage value may be specified, which is taken\nrelative to the installed physical memory on the system. If\nassigned the special value \"infinity\", all available memory is\nprotected, which may be useful in order to always inherit all of\nthe protection afforded by ancestors. This controls the\n\"memory.min\" or \"memory.low\" control group attribute. For details\nabout this control group attribute, see Memory Interface Files[6].\n\nThis setting is supported only if the unified control group\nhierarchy is used and disables MemoryLimit=.\n\nUnits may have their children use a default \"memory.min\" or\n\"memory.low\" value by specifying DefaultMemoryMin= or\nDefaultMemoryLow=, which has the same semantics as MemoryMin= and\nMemoryLow=. This setting does not affect \"memory.min\" or\n\"memory.low\" in the unit itself. Using it to set a default child\nallocation is only useful on kernels older than 5.7, which do not\nsupport the \"memoryrecursiveprot\" cgroup2 mount option.\n\nMemoryHigh=bytes\nSpecify the throttling limit on memory usage of the executed\nprocesses in this unit. Memory usage may go above the limit if\nunavoidable, but the processes are heavily slowed down and memory\nis taken away aggressively in such cases. This is the main\nmechanism to control memory usage of a unit.\n\nTakes a memory size in bytes. If the value is suffixed with K, M, G\nor T, the specified memory size is parsed as Kilobytes, Megabytes,\nGigabytes, or Terabytes (with the base 1024), respectively.\nAlternatively, a percentage value may be specified, which is taken\nrelative to the installed physical memory on the system. If\nassigned the special value \"infinity\", no memory throttling is\napplied. This controls the \"memory.high\" control group attribute.\nFor details about this control group attribute, see Memory\nInterface Files[6].\n\nThis setting is supported only if the unified control group\nhierarchy is used and disables MemoryLimit=.\n\nMemoryMax=bytes\nSpecify the absolute limit on memory usage of the executed\nprocesses in this unit. If memory usage cannot be contained under\nthe limit, out-of-memory killer is invoked inside the unit. It is\nrecommended to use MemoryHigh= as the main control mechanism and\nuse MemoryMax= as the last line of defense.\n\nTakes a memory size in bytes. If the value is suffixed with K, M, G\nor T, the specified memory size is parsed as Kilobytes, Megabytes,\nGigabytes, or Terabytes (with the base 1024), respectively.\nAlternatively, a percentage value may be specified, which is taken\nrelative to the installed physical memory on the system. If\nassigned the special value \"infinity\", no memory limit is applied.\nThis controls the \"memory.max\" control group attribute. For details\nabout 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\nin this unit.\n\nTakes a swap size in bytes. If the value is suffixed with K, M, G\nor T, the specified swap size is parsed as Kilobytes, Megabytes,\nGigabytes, or Terabytes (with the base 1024), respectively. If\nassigned the special value \"infinity\", no swap limit is applied.\nThis controls the \"memory.swap.max\" control group attribute. For\ndetails about this control group attribute, see Memory Interface\nFiles[6].\n\nThis setting is supported only if the unified control group\nhierarchy is used and disables MemoryLimit=.\n\nTasksAccounting=\nTurn on task accounting for this unit. Takes a boolean argument. If\nenabled, the system manager will keep track of the number of tasks\nin the unit. The number of tasks accounted this way includes both\nkernel threads and userspace processes, with each thread counting\nindividually. Note that turning on tasks accounting for one unit\nwill also implicitly turn it on for all units contained in the same\nslice and for all its parent slices and the units contained\ntherein. 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\nunit. This ensures that the number of tasks accounted for the unit\n(see above) stays below a specific limit. This either takes an\nabsolute number of tasks or a percentage value that is taken\nrelative to the configured maximum number of tasks on the system.\nIf assigned the special value \"infinity\", no tasks limit is\napplied. This controls the \"pids.max\" control group attribute. For\ndetails about this control group attribute, see Process Number\nController[7].\n\nThe system default for this setting may be controlled with\nDefaultTasksMax= in systemd-system.conf(5).\n\nIOAccounting=\nTurn on Block I/O accounting for this unit, if the unified control\ngroup hierarchy is used on the system. Takes a boolean argument.\nNote that turning on block I/O accounting for one unit will also\nimplicitly turn it on for all units contained in the same slice and\nall for its parent slices and the units contained therein. The\nsystem default for this setting may be controlled with\nDefaultIOAccounting= in systemd-system.conf(5).\n\nThis setting replaces BlockIOAccounting= and disables settings\nprefixed with BlockIO or StartupBlockIO.\n\nIOWeight=weight, StartupIOWeight=weight\nSet the default overall block I/O weight for the executed\nprocesses, if the unified control group hierarchy is used on the\nsystem. Takes a single weight value (between 1 and 10000) to set\nthe default block I/O weight. This controls the \"io.weight\" control\ngroup attribute, which defaults to 100. For details about this\ncontrol group attribute, see IO Interface Files[8]. The available\nI/O bandwidth is split up among all units within one slice relative\nto their block I/O weight. A higher weight means more I/O\nbandwidth, a lower weight means less.\n\nWhile StartupIOWeight= only applies to the startup phase of the\nsystem, IOWeight= applies to the later runtime of the system, and\nif the former is not set also to the startup phase. This allows\nprioritizing specific services at boot-up differently than during\nruntime.\n\nThese settings replace BlockIOWeight= and StartupBlockIOWeight= and\ndisable settings prefixed with BlockIO or StartupBlockIO.\n\nIODeviceWeight=device weight\nSet the per-device overall block I/O weight for the executed\nprocesses, if the unified control group hierarchy is used on the\nsystem. Takes a space-separated pair of a file path and a weight\nvalue to specify the device specific weight value, between 1 and\n10000. (Example: \"/dev/sda 1000\"). The file path may be specified\nas path to a block device node or as any other file, in which case\nthe backing block device of the file system of the file is\ndetermined. This controls the \"io.weight\" control group attribute,\nwhich defaults to 100. Use this option multiple times to set\nweights for multiple devices. For details about this control group\nattribute, see IO Interface Files[8].\n\nThis setting replaces BlockIODeviceWeight= and disables settings\nprefixed with BlockIO or StartupBlockIO.\n\nThe specified device node should reference a block device that has\nan I/O scheduler associated, i.e. should not refer to partition or\nloopback block devices, but to the originating, physical device.\nWhen a path to a regular file or directory is specified it is\nattempted to discover the correct originating device backing the\nfile system of the specified path. This works correctly only for\nsimpler cases, where the file system is directly placed on a\npartition or physical block device, or where simple 1:1 encryption\nusing dm-crypt/LUKS is used. This discovery does not cover complex\nstorage and in particular RAID and volume management storage\ndevices.\n\nIOReadBandwidthMax=device bytes, IOWriteBandwidthMax=device bytes\nSet the per-device overall block I/O bandwidth maximum limit for\nthe executed processes, if the unified control group hierarchy is\nused on the system. This limit is not work-conserving and the\nexecuted processes are not allowed to use more even if the device\nhas idle capacity. Takes a space-separated pair of a file path and\na bandwidth value (in bytes per second) to specify the device\nspecific bandwidth. The file path may be a path to a block device\nnode, or as any other file in which case the backing block device\nof the file system of the file is used. If the bandwidth is\nsuffixed with K, M, G, or T, the specified bandwidth is parsed as\nKilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the\nbase of 1000. (Example:\n\"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M\"). This\ncontrols the \"io.max\" control group attributes. Use this option\nmultiple times to set bandwidth limits for multiple devices. For\ndetails about this control group attribute, see IO Interface\nFiles[8].\n\nThese settings replace BlockIOReadBandwidth= and\nBlockIOWriteBandwidth= and disable settings prefixed with BlockIO\nor StartupBlockIO.\n\nSimilar restrictions on block device discovery as for\nIODeviceWeight= apply, see above.\n\nIOReadIOPSMax=device IOPS, IOWriteIOPSMax=device IOPS\nSet the per-device overall block I/O IOs-Per-Second maximum limit\nfor the executed processes, if the unified control group hierarchy\nis used on the system. This limit is not work-conserving and the\nexecuted processes are not allowed to use more even if the device\nhas idle capacity. Takes a space-separated pair of a file path and\nan IOPS value to specify the device specific IOPS. The file path\nmay be a 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\nused. If the IOPS is suffixed with K, M, G, or T, the specified\nIOPS is parsed as KiloIOPS, MegaIOPS, GigaIOPS, or TeraIOPS,\nrespectively, to the base of 1000. (Example:\n\"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K\"). This\ncontrols the \"io.max\" control group attributes. Use this option\nmultiple times to set IOPS limits for multiple devices. For details\nabout this control group attribute, see IO Interface Files[8].\n\nThese settings are supported only if the unified control group\nhierarchy is used and disable settings prefixed with BlockIO or\nStartupBlockIO.\n\nSimilar restrictions on block device discovery as for\nIODeviceWeight= apply, see above.\n\nIODeviceLatencyTargetSec=device target\nSet the per-device average target I/O latency for the executed\nprocesses, if the unified control group hierarchy is used on the\nsystem. Takes a file path and a timespan separated by a space to\nspecify the device specific latency target. (Example: \"/dev/sda\n25ms\"). The file path may be specified as path to a block device\nnode or as any other file, in which case the backing block device\nof the file system of the file is determined. This controls the\n\"io.latency\" control group attribute. Use this option multiple\ntimes to set latency target for multiple devices. For details about\nthis control group attribute, see IO Interface Files[8].\n\nImplies \"IOAccounting=yes\".\n\nThese settings are supported only if the unified control group\nhierarchy is used.\n\nSimilar restrictions on block device discovery as for\nIODeviceWeight= apply, see above.\n\nIPAccounting=\nTakes a boolean argument. If true, turns on IPv4 and IPv6 network\ntraffic accounting for packets sent or received by the unit. When\nthis option is turned on, all IPv4 and IPv6 sockets created by any\nprocess of the unit are accounted for.\n\nWhen this option is used in socket units, it applies to all IPv4\nand IPv6 sockets associated with it (including both listening and\nconnection sockets where this applies). Note that for\nsocket-activated services, this configuration setting and the\naccounting data of the service unit and the socket unit are kept\nseparate, and displayed separately. No propagation of the setting\nand the collected statistics is done, in either direction.\nMoreover, any traffic sent or received on any of the socket unit's\nsockets is accounted to the socket unit -- and never to the service\nunit it might have activated, even if the socket is used by it.\n\nThe system default for this setting may be controlled with\nDefaultIPAccounting= in systemd-system.conf(5).\n\nIPAddressAllow=ADDRESS[/PREFIXLENGTH]...,\nIPAddressDeny=ADDRESS[/PREFIXLENGTH]...\nTurn on network traffic filtering for IP packets sent and received\nover AFINET and AFINET6 sockets. Both directives take a space\nseparated list of IPv4 or IPv6 addresses, each optionally suffixed\nwith an address prefix length in bits after a \"/\" character. If the\nsuffix is omitted, the address is considered a host address, i.e.\nthe filter covers the whole address (32 bits for IPv4, 128 bits for\nIPv6).\n\nThe access lists configured with this option are applied to all\nsockets created by processes of this unit (or in the case of socket\nunits, associated with it). The lists are implicitly combined with\nany lists configured for any of the parent slice units this unit\nmight be a member of. By default both access lists are empty. Both\ningress and egress traffic is filtered by these settings. In case\nof ingress traffic the source IP address is checked against these\naccess lists, in case of egress traffic the destination IP address\nis checked. The following rules are applied in turn:\n\no   Access is granted when the checked IP address matches an entry\nin the IPAddressAllow= list.\n\no   Otherwise, access is denied when the checked IP address matches\nan entry in the IPAddressDeny= list.\n\no   Otherwise, access is granted.\n\nIn order to implement an allow-listing IP firewall, it is\nrecommended to use a IPAddressDeny=any setting on an upper-level\nslice unit (such as the root slice -.slice or the slice containing\nall system services system.slice - see systemd.special(7) for\ndetails on these slice units), plus individual per-service\nIPAddressAllow= lines permitting network access to relevant\nservices, and only them.\n\nNote that for socket-activated services, the IP access list\nconfigured on the socket unit applies to all sockets associated\nwith it directly, but not to any sockets created by the ultimately\nactivated services for it. Conversely, the IP access list\nconfigured for the service is not applied to any sockets passed\ninto the service via socket activation. Thus, it is usually a good\nidea to replicate the IP access lists on both the socket and the\nservice unit. Nevertheless, it may make sense to maintain one list\nmore open and the other one more restricted, depending on the\nusecase.\n\nIf these settings are used multiple times in the same unit the\nspecified lists are combined. If an empty string is assigned to\nthese settings the specific access list is reset and all previous\nsettings undone.\n\nIn place of explicit IPv4 or IPv6 address and prefix length\nspecifications a small set of symbolic names may be used. The\nfollowing 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    |\n|              |                     | the local loopback  |\n+--------------+---------------------+---------------------+\n|link-local    | 169.254.0.0/16      | All link-local IP   |\n|              | fe80::/64           | addresses           |\n+--------------+---------------------+---------------------+\n|multicast     | 224.0.0.0/4         | All IP multicasting |\n|              | ff00::/8            | addresses           |\n+--------------+---------------------+---------------------+\nNote that these settings might not be supported on some systems\n(for example if eBPF control group support is not enabled in the\nunderlying kernel or container manager). These settings will have\nno effect in that case. If compatibility with such systems is\ndesired it is hence recommended to not exclusively rely on them for\nIP security.\n\nIPIngressFilterPath=BPFFSPROGRAMPATH,\nIPEgressFilterPath=BPFFSPROGRAMPATH\nAdd custom network traffic filters implemented as BPF programs,\napplying to all IP packets sent and received over AFINET and\nAFINET6 sockets. Takes an absolute path to a pinned BPF program in\nthe BPF virtual filesystem (/sys/fs/bpf/).\n\nThe filters configured with this option are applied to all sockets\ncreated by processes of this unit (or in the case of socket units,\nassociated with it). The filters are loaded in addition to filters\nany of the parent slice units this unit might be a member of as\nwell as any IPAddressAllow= and IPAddressDeny= filters in any of\nthese units. By default there are no filters specified.\n\nIf these settings are used multiple times in the same unit all the\nspecified programs are attached. If an empty string is assigned to\nthese settings the program list is reset and all previous specified\nprograms ignored.\n\nIf the path BPFFSPROGRAMPATH in IPIngressFilterPath= assignment\nis already being handled by BPFProgram= ingress hook, e.g.\nBPFProgram=ingress:BPFFSPROGRAMPATH, the assignment will be\nstill considered valid and the program will be attached to a\ncgroup. Same for IPEgressFilterPath= path and egress hook.\n\nNote that for socket-activated services, the IP filter programs\nconfigured on the socket unit apply to all sockets associated with\nit directly, but not to any sockets created by the ultimately\nactivated services for it. Conversely, the IP filter programs\nconfigured for the service are not applied to any sockets passed\ninto the service via socket activation. Thus, it is usually a good\nidea, to replicate the IP filter programs on both the socket and\nthe service unit, however it often makes sense to maintain one\nconfiguration more open and the other one more restricted,\ndepending on the usecase.\n\nNote that these settings might not be supported on some systems\n(for example if eBPF control group support is not enabled in the\nunderlying kernel or container manager). These settings will fail\nthe service in that case. If compatibility with such systems is\ndesired it is hence recommended to attach your filter manually\n(requires Delegate=yes) instead 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\nunit. (This generalizes the functionality exposed via\nIPEgressFilterPath= for egress and IPIngressFilterPath= for\ningress.) Cgroup-bpf hooks in the form of BPF programs loaded to\nthe BPF filesystem are attached with cgroup-bpf attach flags\ndetermined by the unit. For details about attachment types and\nflags 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\nprogram-path with \":\" as the separator: type:program-path.\n\ntype is the string name of BPF attach type also used in bpftool.\ntype can be one of egress, ingress, sockcreate, sockops, device,\nbind4, bind6, connect4, connect6, postbind4, postbind6, sendmsg4,\nsendmsg6, sysctl, recvmsg4, recvmsg6, getsockopt, setsockopt.\n\nSetting BPFProgram= to an empty value makes previous assignments\nineffective.\n\nMultiple assignments of the same type:program-path value have the\nsame effect as a single assignment: the program with the path\nprogram-path will be attached to cgroup hook type just once.\n\nIf BPF egress pinned to program-path path is already being handled\nby IPEgressFilterPath=, BPFProgram= assignment will be considered\nvalid and BPFProgram= will be attached to a cgroup. Similarly for\ningress hook and IPIngressFilterPath= assignment.\n\nBPF programs passed with BPFProgram= are attached to the cgroup of\na unit with BPF attach flag multi, that allows further attachments\nof the same type within cgroup hierarchy topped 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\nwith the bind-rule and applying a corresponding action if there is\na match.\n\nbind-rule describes socket properties such as address-family,\ntransport-protocol and ip-ports.\n\nbind-rule := { [address-family:][transport-protocol:][ip-ports] |\nany }\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\nspecified, a rule will be matched for both IPv4 and IPv6 addresses\nand applied depending on other socket fields, e.g.\ntransport-protocol, ip-port.\n\nAn optional transport-protocol expects tcp or udp transport\nprotocol names. If not specified, a rule will be matched for any\ntransport protocol.\n\nAn optional ip-port value must lie within 1...65535 interval\ninclusively, i.e. dynamic port 0 is not allowed. A range of\nsequential ports is described by ip-port-range :=\nip-port-low-ip-port-high, where ip-port-low is smaller than or\nequal to ip-port-high and both are within 1...65535 inclusively.\n\nA special value any can be used to apply a rule to any address\nfamily, transport protocol and any port with a positive value.\n\nTo allow multiple rules assign SocketBindAllow= or SocketBindDeny=\nmultiple times. To clear the existing assignments pass an empty\nSocketBindAllow= or SocketBindDeny= assignment.\n\nFor each of SocketBindAllow= and SocketBindDeny=, maximum allowed\nnumber of assignments is 128.\n\no   Binding to a socket is allowed when a socket address matches an\nentry in the SocketBindAllow= list.\n\no   Otherwise, binding is denied when the socket address matches an\nentry in the SocketBindDeny= list.\n\no   Otherwise, binding is allowed.\n\nThe feature is implemented with cgroup/bind4 and cgroup/bind6\ncgroup-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.\nTakes two space-separated strings: a device node specifier followed\nby a combination of r, w, m to control reading, writing, or\ncreation of the specific device node(s) by the unit (mknod),\nrespectively. On cgroup-v1 this controls the \"devices.allow\"\ncontrol group attribute. For details about this control group\nattribute, see Device Whitelist Controller[9]. In the unified\ncgroup hierarchy this functionality is implemented using eBPF\nfiltering.\n\nThe device node specifier is either a path to a device node in the\nfile system, starting with /dev/, or a string starting with either\n\"char-\" or \"block-\" followed by a device group name, as listed in\n/proc/devices. The latter is useful to allow-list all current and\nfuture devices belonging to a specific device group at once. The\ndevice group is matched according to filename globbing rules, you\nmay hence use the \"*\" and \"?\"  wildcards. (Note that such globbing\nwildcards are not available for device node path specifications!)\nIn order to match device nodes by numeric major/minor, use device\nnode paths in the /dev/char/ and /dev/block/ directories. However,\nmatching devices by major/minor is generally not recommended as\nassignments are neither stable nor portable between systems or\ndifferent kernel versions.\n\nExamples: /dev/sda5 is a path to a device node, referring to an ATA\nor SCSI block device.  \"char-pts\" and \"char-alsa\" are specifiers\nfor all pseudo TTYs and all ALSA sound devices, respectively.\n\"char-cpu/*\" is a specifier matching all CPU related device groups.\n\nNote that allow lists defined this way should only reference device\ngroups which are resolvable at the time the unit is started. Any\ndevice groups not resolvable then are not added to the device allow\nlist. In order to work around this limitation, consider extending\nservice units with a pair of After=modprobe@xyz.service and\nWants=modprobe@xyz.service lines that load the necessary kernel\nmodule implementing the device 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\nspecified.\n\nclosed\nin addition, allows access to standard pseudo devices including\n/dev/null, /dev/zero, /dev/full, /dev/random, and /dev/urandom.\n\nauto\nin addition, allows access to all devices if no explicit\nDeviceAllow= is present. This is the default.\n\nSlice=\nThe name of the slice unit to place the unit in. Defaults to\nsystem.slice for all non-instantiated units of all unit types\n(except for slice units themselves see below). Instance units are\nby 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\nslices each of which might have resource settings applied.\n\nFor units of type slice, the only accepted value for this setting\nis the parent slice. Since the name of a slice unit implies the\nparent slice, it is hence redundant to ever set this parameter\ndirectly for slice units.\n\nSpecial care should be taken when relying on the default slice\nassignment in templated service units that have\nDefaultDependencies=no set, see systemd.service(5), section\n\"Default Dependencies\" for details.\n\nDelegate=\nTurns on delegation of further resource control partitioning to\nprocesses of the unit. Units where this is enabled may create and\nmanage their own private subhierarchy of control groups below the\ncontrol group of the unit itself. For unprivileged services (i.e.\nthose using the User= setting) the unit's control group will be\nmade accessible to the relevant user. When enabled the service\nmanager will refrain from manipulating control groups or moving\nprocesses below the unit's control group, so that a clear concept\nof ownership is established: the control group tree above the\nunit's control group (i.e. towards the root control group) is owned\nand managed by the service manager of the host, while the control\ngroup tree below the unit's control group is owned and managed by\nthe unit itself. Takes either a boolean argument or a list of\ncontrol group controller names. If true, delegation is turned on,\nand all supported controllers are enabled for the unit, making them\navailable to the unit's processes for management. If false,\ndelegation is turned off entirely (and no additional controllers\nare enabled). If set to a list of controllers, delegation is turned\non, and the specified controllers are enabled for the unit. Note\nthat additional controllers than the ones specified might be made\navailable as well, depending on configuration of the containing\nslice unit or other units contained in it. Note that assigning the\nempty string will enable delegation, but reset the list of\ncontrollers, all assignments prior to this will have no effect.\nDefaults to false.\n\nNote that controller delegation to less privileged code is only\nsafe on the unified control group hierarchy. Accordingly, access to\nthe specified controllers will not be granted to unprivileged\nservices on the legacy hierarchy, even when requested.\n\nThe following controller names may be specified: cpu, cpuacct,\ncpuset, io, blkio, memory, devices, pids, bpf-firewall, and\nbpf-devices.\n\nNot all of these controllers are available on all kernels however,\nand some are specific to the unified hierarchy while others are\nspecific to the legacy hierarchy. Also note that the kernel might\nsupport further controllers, which aren't covered here yet as\ndelegation is either not supported at all for them or not defined\ncleanly.\n\nFor further details on the delegation model consult Control Group\nAPIs and Delegation[10].\n\nDisableControllers=\nDisables controllers from being enabled for a unit's children. If a\ncontroller listed is already in use in its subtree, the controller\nwill be removed from the subtree. This can be used to avoid child\nunits 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\nunit or any child of the unit in question delegates controllers to\nits children, as any delegated subtree of the cgroup hierarchy is\nunmanaged by systemd.\n\nMultiple controllers may be specified, separated by spaces. You may\nalso pass DisableControllers= multiple times, in which case each\nnew instance adds another controller to disable. Passing\nDisableControllers= by itself with no controller name present\nresets the disabled controller list.\n\nThe following controller names may be specified: cpu, cpuacct,\ncpuset, io, blkio, memory, devices, pids, bpf-firewall, and\nbpf-devices.\n\nManagedOOMSwap=auto|kill, ManagedOOMMemoryPressure=auto|kill\nSpecifies how systemd-oomd.service(8) will act on this unit's\ncgroups. Defaults to auto.\n\nWhen set to kill, systemd-oomd will actively monitor this unit's\ncgroup metrics to decide whether it needs to act. If the cgroup\npasses the limits set by oomd.conf(5) or its overrides,\nsystemd-oomd will send a SIGKILL to all of the processes under the\nchosen candidate cgroup. Note that only descendant cgroups can be\neligible candidates for killing; the unit that set its property to\nkill is not a candidate (unless one of its ancestors set their\nproperty to kill). You can find more details on candidates and kill\nbehavior at systemd-oomd.service(8) and oomd.conf(5). Setting\neither of these properties to kill will also automatically acquire\nAfter= and Wants= dependencies on systemd-oomd.service unless\nDefaultDependencies=no.\n\nWhen set to auto, systemd-oomd will not actively use this cgroup's\ndata for monitoring and detection. However, if an ancestor cgroup\nhas one of these properties set to kill, a unit with auto can still\nbe an eligible candidate for systemd-oomd to act on.\n\nManagedOOMMemoryPressureLimit=\nOverrides the default memory pressure limit set by oomd.conf(5) for\nthis unit (cgroup). Takes a percentage value between 0% and 100%,\ninclusive. This property is ignored unless\nManagedOOMMemoryPressure=kill. Defaults to 0%, which means to use\nthe default set by oomd.conf(5).\n\nManagedOOMPreference=none|avoid|omit\nAllows deprioritizing or omitting this unit's cgroup as a candidate\nwhen systemd-oomd needs to act. Requires support for extended\nattributes (see xattr(7)) in order to use avoid or omit.\nAdditionally, systemd-oomd will ignore these extended attributes if\nthe unit's cgroup is not owned by the root user.\n\nIf this property is set to avoid, the service manager will convey\nthis to systemd-oomd, which will only select this cgroup if there\nare no other viable candidates.\n\nIf this property is set to omit, the service manager will convey\nthis to systemd-oomd, which will ignore this cgroup as a candidate\nand will not perform any actions on it.\n\nIt is recommended to use avoid and omit sparingly, as it can\nadversely affect systemd-oomd's kill behavior. Also note that these\nextended attributes are not applied recursively to cgroups under\nthis unit's cgroup.\n\nDefaults to none which means systemd-oomd will rank this unit's\ncgroup as defined in systemd-oomd.service(8) and oomd.conf(5).\n",
            "subsections": []
        },
        "DEPRECATED OPTIONS": {
            "content": "The following options are deprecated. Use the indicated superseding\noptions instead:\n\nCPUShares=weight, StartupCPUShares=weight\nAssign the specified CPU time share weight to the processes\nexecuted. These options take an integer value and control the\n\"cpu.shares\" control group attribute. The allowed range is 2 to\n262144. Defaults to 1024. For details about this control group\nattribute, see CFS Scheduler[4]. The available CPU time is split up\namong all units within one slice relative to their CPU time share\nweight.\n\nWhile StartupCPUShares= only applies to the startup phase of the\nsystem, CPUShares= applies to normal runtime of the system, and if\nthe former is not set also to the startup phase. Using\nStartupCPUShares= 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=\ninstead.\n\nMemoryLimit=bytes\nSpecify the limit on maximum memory usage of the executed\nprocesses. The limit specifies how much process and kernel memory\ncan be used by tasks in this unit. Takes a memory size in bytes. If\nthe value is suffixed with K, M, G or T, the specified memory size\nis parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with\nthe base 1024), respectively. Alternatively, a percentage value may\nbe specified, which is taken relative to the installed physical\nmemory on the system. If assigned the special value \"infinity\", no\nmemory limit is applied. This controls the \"memory.limitinbytes\"\ncontrol group attribute. For details about this control group\nattribute, see Memory Resource Controller[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\ngroup hierarchy is used on the system. Takes a boolean argument.\nNote that turning on block I/O accounting for one unit will also\nimplicitly turn it on for all units contained in the same slice and\nall for its parent slices and the units contained therein. The\nsystem default for this setting may be controlled with\nDefaultBlockIOAccounting= 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\nprocesses, if the legacy control group hierarchy is used on the\nsystem. Takes a single weight value (between 10 and 1000) to set\nthe default block I/O weight. This controls the \"blkio.weight\"\ncontrol group attribute, which defaults to 500. For details about\nthis control group attribute, see Block IO Controller[12]. The\navailable I/O bandwidth is split up among all units within one\nslice relative to their block I/O weight.\n\nWhile StartupBlockIOWeight= only applies to the startup phase of\nthe system, BlockIOWeight= applies to the later runtime of the\nsystem, and if the former is not set also to the startup phase.\nThis allows prioritizing specific services at boot-up differently\nthan during runtime.\n\nImplies \"BlockIOAccounting=yes\".\n\nThese settings are deprecated. Use IOWeight= and StartupIOWeight=\ninstead.\n\nBlockIODeviceWeight=device weight\nSet the per-device overall block I/O weight for the executed\nprocesses, if the legacy control group hierarchy is used on the\nsystem. Takes a space-separated pair of a file path and a weight\nvalue to specify the device specific weight value, between 10 and\n1000. (Example: \"/dev/sda 500\"). The file path may be specified as\npath to a block device node or as any other file, in which case the\nbacking block device of the file system of the file is determined.\nThis controls the \"blkio.weightdevice\" control group attribute,\nwhich defaults to 1000. Use this option multiple times to set\nweights for multiple devices. For details about this control group\nattribute, 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\nexecuted processes, if the legacy control group hierarchy is used\non the system. Takes a space-separated pair of a file path and a\nbandwidth value (in bytes per second) to specify the device\nspecific bandwidth. The file path may be a path to a block device\nnode, or as any other file in which case the backing block device\nof the file system of the file is used. If the bandwidth is\nsuffixed with K, M, G, or T, the specified bandwidth is parsed as\nKilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the\nbase of 1000. (Example:\n\"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M\"). This\ncontrols the \"blkio.throttle.readbpsdevice\" and\n\"blkio.throttle.writebpsdevice\" control group attributes. Use\nthis option multiple times to set bandwidth limits for multiple\ndevices. For details about these control group attributes, see\nBlock IO Controller[12].\n\nImplies \"BlockIOAccounting=yes\".\n\nThese settings are deprecated. Use IOReadBandwidthMax= and\nIOWriteBandwidthMax= instead.\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "systemd(1), systemd-system.conf(5), systemd.unit(5),\nsystemd.service(5), systemd.slice(5), systemd.scope(5),\nsystemd.socket(5), systemd.mount(5), systemd.swap(5), systemd.exec(5),\nsystemd.directives(7), systemd.special(7), systemd-oomd.service(8), The\ndocumentation for control groups and specific controllers in the Linux\nkernel: 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\nsystemd 249                                        SYSTEMD.RESOURCE-CONTROL(5)",
            "subsections": []
        }
    },
    "summary": "systemd.resource-control - Resource control unit settings",
    "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"
        }
    ]
}