diff --git a/man/systemd.resource-control.xml b/man/systemd.resource-control.xml index 7836834efe..1cd0beea04 100644 --- a/man/systemd.resource-control.xml +++ b/man/systemd.resource-control.xml @@ -174,8 +174,9 @@ CPUWeight=20 DisableControllers=cpu / \ Options - Units of the types listed above can have settings - for resource control configuration: + Units of the types listed above can have settings for resource control configuration: + + CPU Accounting and Control @@ -305,29 +306,11 @@ CPUWeight=20 DisableControllers=cpu / \ - - AllowedMemoryNodes= - StartupAllowedMemoryNodes= + - - These settings control the controller in the unified hierarchy. + Memory Accounting and Control - Restrict processes to be executed on specific memory NUMA nodes. Takes a list of memory NUMA nodes indices - or ranges separated by either whitespace or commas. Memory NUMA nodes ranges are specified by the lower and upper - NUMA nodes indices separated by a dash. - - Setting AllowedMemoryNodes= or StartupAllowedMemoryNodes= doesn't - guarantee that all of the memory NUMA nodes will be used by the processes as it may be limited by parent units. - The effective configuration is reported as EffectiveMemoryNodes=. - - While StartupAllowedMemoryNodes= applies to the startup and shutdown phases of the system, - AllowedMemoryNodes= applies to normal runtime of the system, and if the former is not set also to - the startup and shutdown phases. Using StartupAllowedMemoryNodes= allows prioritizing specific services at - boot-up and shutdown differently than during normal runtime. - - This setting is supported only with the unified control group hierarchy. - - + MemoryAccounting= @@ -492,6 +475,36 @@ CPUWeight=20 DisableControllers=cpu / \ + + AllowedMemoryNodes= + StartupAllowedMemoryNodes= + + + These settings control the controller in the unified hierarchy. + + Restrict processes to be executed on specific memory NUMA nodes. Takes a list of memory NUMA nodes indices + or ranges separated by either whitespace or commas. Memory NUMA nodes ranges are specified by the lower and upper + NUMA nodes indices separated by a dash. + + Setting AllowedMemoryNodes= or StartupAllowedMemoryNodes= doesn't + guarantee that all of the memory NUMA nodes will be used by the processes as it may be limited by parent units. + The effective configuration is reported as EffectiveMemoryNodes=. + + While StartupAllowedMemoryNodes= applies to the startup and shutdown phases of the system, + AllowedMemoryNodes= applies to normal runtime of the system, and if the former is not set also to + the startup and shutdown phases. Using StartupAllowedMemoryNodes= allows prioritizing specific services at + boot-up and shutdown differently than during normal runtime. + + This setting is supported only with the unified control group hierarchy. + + + + + + Process Accounting and Control + + + TasksAccounting= @@ -529,6 +542,12 @@ CPUWeight=20 DisableControllers=cpu / \ + + + IO Accounting and Control + + + IOAccounting= @@ -665,6 +684,12 @@ CPUWeight=20 DisableControllers=cpu / \ + + + Network Accounting and Control + + + IPAccounting= @@ -791,91 +816,6 @@ CPUWeight=20 DisableControllers=cpu / \ - - IPIngressFilterPath=BPF_FS_PROGRAM_PATH - IPEgressFilterPath=BPF_FS_PROGRAM_PATH - - - Add custom network traffic filters implemented as BPF programs, applying to all IP packets - sent and received over AF_INET and AF_INET6 sockets. - Takes an absolute path to a pinned BPF program in the BPF virtual filesystem (/sys/fs/bpf/). - - - The filters configured with this option are applied to all sockets created by processes - of this unit (or in the case of socket units, associated with it). The filters are loaded in addition - to filters any of the parent slice units this unit might be a member of as well as any - IPAddressAllow= and IPAddressDeny= filters in any of these units. - By default there are no filters specified. - - If these settings are used multiple times in the same unit all the specified programs are attached. If an - empty string is assigned to these settings the program list is reset and all previous specified programs ignored. - - If the path BPF_FS_PROGRAM_PATH in IPIngressFilterPath= assignment - is already being handled by BPFProgram= ingress hook, e.g. - BPFProgram=ingress:BPF_FS_PROGRAM_PATH, - the assignment will be still considered valid and the program will be attached to a cgroup. Same for - IPEgressFilterPath= path and egress hook. - - Note that for socket-activated services, the IP filter programs configured on the socket unit apply to - all sockets associated with it directly, but not to any sockets created by the ultimately activated services - for it. Conversely, the IP filter programs configured for the service are not applied to any sockets passed into - the service via socket activation. Thus, it is usually a good idea, to replicate the IP filter programs on both - the socket and the service unit, however it often makes sense to maintain one configuration more open and the other - one more restricted, depending on the usecase. - - Note that these settings might not be supported on some systems (for example if eBPF control group - support is not enabled in the underlying kernel or container manager). These settings will fail the service in - that case. If compatibility with such systems is desired it is hence recommended to attach your filter manually - (requires Delegate=yes) instead of using this setting. - - - - - BPFProgram=type:program-path - - Add a custom cgroup BPF program. - - BPFProgram= allows attaching BPF hooks to the cgroup of a systemd unit. - (This generalizes the functionality exposed via IPEgressFilterPath= for egress and - IPIngressFilterPath= for ingress.) - Cgroup-bpf hooks in the form of BPF programs loaded to the BPF filesystem are attached with cgroup-bpf attach - flags determined by the unit. For details about attachment types and flags see . - For general BPF documentation please refer to . - - The specification of BPF program consists of a type followed by a - program-path with : as the separator: - type:program-path. - - type is the string name of BPF attach type also used in - bpftool. type can be one of egress, - ingress, sock_create, sock_ops, - device, bind4, bind6, - connect4, connect6, post_bind4, - post_bind6, sendmsg4, sendmsg6, - sysctl, recvmsg4, recvmsg6, - getsockopt, setsockopt. - - Setting BPFProgram= to an empty value makes previous assignments ineffective. - Multiple assignments of the same type:program-path - value have the same effect as a single assignment: the program with the path program-path - will be attached to cgroup hook type just once. - If BPF egress pinned to program-path path is already being - handled by IPEgressFilterPath=, BPFProgram= - assignment will be considered valid and BPFProgram= will be attached to a cgroup. - Similarly for ingress hook and IPIngressFilterPath= assignment. - - BPF programs passed with BPFProgram= are attached to the cgroup of a unit with BPF - attach flag multi, that allows further attachments of the same - type within cgroup hierarchy topped by the unit cgroup. - - Examples: -BPFProgram=egress:/sys/fs/bpf/egress-hook -BPFProgram=bind6:/sys/fs/bpf/sock-addr-hook - - - - SocketBindAllow=bind-rule SocketBindDeny=bind-rule @@ -1017,6 +957,103 @@ RestrictNetworkInterfaces=~eth1 + + + BPF Programs + + + + + IPIngressFilterPath=BPF_FS_PROGRAM_PATH + IPEgressFilterPath=BPF_FS_PROGRAM_PATH + + + Add custom network traffic filters implemented as BPF programs, applying to all IP packets + sent and received over AF_INET and AF_INET6 sockets. + Takes an absolute path to a pinned BPF program in the BPF virtual filesystem (/sys/fs/bpf/). + + + The filters configured with this option are applied to all sockets created by processes + of this unit (or in the case of socket units, associated with it). The filters are loaded in addition + to filters any of the parent slice units this unit might be a member of as well as any + IPAddressAllow= and IPAddressDeny= filters in any of these units. + By default there are no filters specified. + + If these settings are used multiple times in the same unit all the specified programs are attached. If an + empty string is assigned to these settings the program list is reset and all previous specified programs ignored. + + If the path BPF_FS_PROGRAM_PATH in IPIngressFilterPath= assignment + is already being handled by BPFProgram= ingress hook, e.g. + BPFProgram=ingress:BPF_FS_PROGRAM_PATH, + the assignment will be still considered valid and the program will be attached to a cgroup. Same for + IPEgressFilterPath= path and egress hook. + + Note that for socket-activated services, the IP filter programs configured on the socket unit apply to + all sockets associated with it directly, but not to any sockets created by the ultimately activated services + for it. Conversely, the IP filter programs configured for the service are not applied to any sockets passed into + the service via socket activation. Thus, it is usually a good idea, to replicate the IP filter programs on both + the socket and the service unit, however it often makes sense to maintain one configuration more open and the other + one more restricted, depending on the usecase. + + Note that these settings might not be supported on some systems (for example if eBPF control group + support is not enabled in the underlying kernel or container manager). These settings will fail the service in + that case. If compatibility with such systems is desired it is hence recommended to attach your filter manually + (requires Delegate=yes) instead of using this setting. + + + + + BPFProgram=type:program-path + + Add a custom cgroup BPF program. + + BPFProgram= allows attaching BPF hooks to the cgroup of a systemd unit. + (This generalizes the functionality exposed via IPEgressFilterPath= for egress and + IPIngressFilterPath= for ingress.) + Cgroup-bpf hooks in the form of BPF programs loaded to the BPF filesystem are attached with cgroup-bpf attach + flags determined by the unit. For details about attachment types and flags see . + For general BPF documentation please refer to . + + The specification of BPF program consists of a type followed by a + program-path with : as the separator: + type:program-path. + + type is the string name of BPF attach type also used in + bpftool. type can be one of egress, + ingress, sock_create, sock_ops, + device, bind4, bind6, + connect4, connect6, post_bind4, + post_bind6, sendmsg4, sendmsg6, + sysctl, recvmsg4, recvmsg6, + getsockopt, setsockopt. + + Setting BPFProgram= to an empty value makes previous assignments ineffective. + Multiple assignments of the same type:program-path + value have the same effect as a single assignment: the program with the path program-path + will be attached to cgroup hook type just once. + If BPF egress pinned to program-path path is already being + handled by IPEgressFilterPath=, BPFProgram= + assignment will be considered valid and BPFProgram= will be attached to a cgroup. + Similarly for ingress hook and IPIngressFilterPath= assignment. + + BPF programs passed with BPFProgram= are attached to the cgroup of a unit with BPF + attach flag multi, that allows further attachments of the same + type within cgroup hierarchy topped by the unit cgroup. + + Examples: +BPFProgram=egress:/sys/fs/bpf/egress-hook +BPFProgram=bind6:/sys/fs/bpf/sock-addr-hook + + + + + + + Device Access + + + DeviceAllow= @@ -1116,6 +1153,12 @@ DeviceAllow=/dev/loop-control + + + Control Group Management + + + Slice= @@ -1234,6 +1277,12 @@ DeviceAllow=/dev/loop-control + + + Memory Pressure Control + + + ManagedOOMSwap=auto|kill ManagedOOMMemoryPressure=auto|kill @@ -1367,6 +1416,7 @@ DeviceAllow=/dev/loop-control details on the permitted syntax. +