1SYSTEMD.RESOURCE-CONTROL(5)systemd.resource-controlSYSTEMD.RESOURCE-CONTROL(5)
2
6 systemd.resource-control - Resource control unit settings
7
9 slice.slice, scope.scope, service.service, socket.socket, mount.mount,
10 swap.swap
11
13 Unit configuration files for services, slices, scopes, sockets, mount
14 points, and swap devices share a subset of configuration options for
15 resource control of spawned processes. Internally, this relies on the
16 Linux Control Groups (cgroups) kernel concept for organizing processes
17 in a hierarchical tree of named groups for the purpose of resource
18 management.
19 This man page lists the configuration options shared by those six unit
21 types. See systemd.unit(5) for the common options of all unit
22 configuration files, and systemd.slice(5), systemd.scope(5),
23 systemd.service(5), systemd.socket(5), systemd.mount(5), and
24 systemd.swap(5) for more information on the specific unit configuration
25 files. The resource control configuration options are configured in the
26 [Slice], [Scope], [Service], [Socket], [Mount], or [Swap] sections,
27 depending on the unit type.
28 In addition, options which control resources available to programs
30 executed by systemd are listed in systemd.exec(5). Those options
31 complement options listed here.
32 See the New Control Group Interfaces[1] for an introduction on how to
34 make use of resource control APIs from programs.
35
37 The following dependencies are implicitly added:
38 · Units with the Slice= setting set automatically acquire Requires=
40 and After= dependencies on the specified slice unit.
41
43 The unified control group hierarchy is the new version of kernel
44 control group interface, see cgroup-v2.txt[2]. Depending on the
45 resource type, there are differences in resource control capabilities.
46 Also, because of interface changes, some resource types have separate
47 set of options on the unified hierarchy.
48 CPU
50 CPUWeight= and StartupCPUWeight= replace CPUShares= and
51 StartupCPUShares=, respectively.
52 The "cpuacct" controller does not exist separately on the unified
54 hierarchy.
55 Memory
57 MemoryMax= replaces MemoryLimit=. MemoryLow= and MemoryHigh= are
58 effective only on unified hierarchy.
59 IO
61 IO prefixed settings are a superset of and replace BlockIO prefixed
62 ones. On unified hierarchy, IO resource control also applies to
63 buffered writes.
64 To ease the transition, there is best-effort translation between the
66 two versions of settings. For each controller, if any of the settings
67 for the unified hierarchy are present, all settings for the legacy
68 hierarchy are ignored. If the resulting settings are for the other type
69 of hierarchy, the configurations are translated before application.
70 Legacy control group hierarchy (see cgroups.txt[3]), also called
72 cgroup-v1, doesn't allow safe delegation of controllers to unprivileged
73 processes. If the system uses the legacy control group hierarchy,
74 resource control is disabled for systemd user instance, see systemd(1).
75
77 Units of the types listed above can have settings for resource control
78 configuration:
79 CPUAccounting=
81 Turn on CPU usage accounting for this unit. Takes a boolean
82 argument. Note that turning on CPU accounting for one unit will
83 also implicitly turn it on for all units contained in the same
84 slice and for all its parent slices and the units contained
85 therein. The system default for this setting may be controlled with
86 DefaultCPUAccounting= in systemd-system.conf(5).
87 CPUWeight=weight, StartupCPUWeight=weight
89 Assign the specified CPU time weight to the processes executed, if
90 the unified control group hierarchy is used on the system. These
91 options take an integer value and control the "cpu.weight" control
92 group attribute. The allowed range is 1 to 10000. Defaults to 100.
93 For details about this control group attribute, see
94 cgroup-v2.txt[2] and sched-design-CFS.txt[4]. The available CPU
95 time is split up among all units within one slice relative to their
96 CPU time weight.
97 While StartupCPUWeight= only applies to the startup phase of the
99 system, CPUWeight= applies to normal runtime of the system, and if
100 the former is not set also to the startup phase. Using
101 StartupCPUWeight= allows prioritizing specific services at boot-up
102 differently than during normal runtime.
103 These settings replace CPUShares= and StartupCPUShares=.
105 CPUQuota=
107 Assign the specified CPU time quota to the processes executed.
108 Takes a percentage value, suffixed with "%". The percentage
109 specifies how much CPU time the unit shall get at maximum, relative
110 to the total CPU time available on one CPU. Use values > 100% for
111 allotting CPU time on more than one CPU. This controls the
112 "cpu.max" attribute on the unified control group hierarchy and
113 "cpu.cfs_quota_us" on legacy. For details about these control group
114 attributes, see cgroup-v2.txt[2] and sched-bwc.txt[5].
115 Example: CPUQuota=20% ensures that the executed processes will
117 never get more than 20% CPU time on one CPU.
118 CPUQuotaPeriodSec=
120 Assign the duration over which the CPU time quota specified by
121 CPUQuota= is measured. Takes a time duration value in seconds, with
122 an optional suffix such as "ms" for milliseconds (or "s" for
123 seconds.) The default setting is 100ms. The period is clamped to
124 the range supported by the kernel, which is [1ms, 1000ms].
125 Additionally, the period is adjusted up so that the quota interval
126 is also at least 1ms. Setting CPUQuotaPeriodSec= to an empty value
127 resets it to the default.
128 This controls the second field of "cpu.max" attribute on the
130 unified control group hierarchy and "cpu.cfs_period_us" on legacy.
131 For details about these control group attributes, see
132 cgroup-v2.txt[2] and sched-design-CFS.txt[4].
133 Example: CPUQuotaPeriodSec=10ms to request that the CPU quota is
135 measured in periods of 10ms.
136 MemoryAccounting=
138 Turn on process and kernel memory accounting for this unit. Takes a
139 boolean argument. Note that turning on memory accounting for one
140 unit will also implicitly turn it on for all units contained in the
141 same slice and for all its parent slices and the units contained
142 therein. The system default for this setting may be controlled with
143 DefaultMemoryAccounting= in systemd-system.conf(5).
144 MemoryMin=bytes
146 Specify the memory usage protection of the executed processes in
147 this unit. If the memory usages of this unit and all its ancestors
148 are below their minimum boundaries, this unit's memory won't be
149 reclaimed.
150 Takes a memory size in bytes. If the value is suffixed with K, M, G
152 or T, the specified memory size is parsed as Kilobytes, Megabytes,
153 Gigabytes, or Terabytes (with the base 1024), respectively.
154 Alternatively, a percentage value may be specified, which is taken
155 relative to the installed physical memory on the system. If
156 assigned the special value "infinity", all available memory is
157 protected, which may be useful in order to always inherit all of
158 the protection afforded by ancestors. This controls the
159 "memory.min" control group attribute. For details about this
160 control group attribute, see cgroup-v2.txt[2].
161 This setting is supported only if the unified control group
163 hierarchy is used and disables MemoryLimit=.
164 Units may have their children use a default "memory.min" value by
166 specifying DefaultMemoryMin=, which has the same semantics as
167 MemoryMin=. This setting does not affect "memory.min" in the unit
168 itself.
169 MemoryLow=bytes
171 Specify the best-effort memory usage protection of the executed
172 processes in this unit. If the memory usages of this unit and all
173 its ancestors are below their low boundaries, this unit's memory
174 won't be reclaimed as long as memory can be reclaimed from
175 unprotected units.
176 Takes a memory size in bytes. If the value is suffixed with K, M, G
178 or T, the specified memory size is parsed as Kilobytes, Megabytes,
179 Gigabytes, or Terabytes (with the base 1024), respectively.
180 Alternatively, a percentage value may be specified, which is taken
181 relative to the installed physical memory on the system. If
182 assigned the special value "infinity", all available memory is
183 protected, which may be useful in order to always inherit all of
184 the protection afforded by ancestors. This controls the
185 "memory.low" control group attribute. For details about this
186 control group attribute, see cgroup-v2.txt[2].
187 This setting is supported only if the unified control group
189 hierarchy is used and disables MemoryLimit=.
190 Units may have their children use a default "memory.low" value by
192 specifying DefaultMemoryLow=, which has the same semantics as
193 MemoryLow=. This setting does not affect "memory.low" in the unit
194 itself.
195 MemoryHigh=bytes
197 Specify the throttling limit on memory usage of the executed
198 processes in this unit. Memory usage may go above the limit if
199 unavoidable, but the processes are heavily slowed down and memory
200 is taken away aggressively in such cases. This is the main
201 mechanism to control memory usage of a unit.
202 Takes a memory size in bytes. If the value is suffixed with K, M, G
204 or T, the specified memory size is parsed as Kilobytes, Megabytes,
205 Gigabytes, or Terabytes (with the base 1024), respectively.
206 Alternatively, a percentage value may be specified, which is taken
207 relative to the installed physical memory on the system. If
208 assigned the special value "infinity", no memory throttling is
209 applied. This controls the "memory.high" control group attribute.
210 For details about this control group attribute, see
211 cgroup-v2.txt[2].
212 This setting is supported only if the unified control group
214 hierarchy is used and disables MemoryLimit=.
215 MemoryMax=bytes
217 Specify the absolute limit on memory usage of the executed
218 processes in this unit. If memory usage cannot be contained under
219 the limit, out-of-memory killer is invoked inside the unit. It is
220 recommended to use MemoryHigh= as the main control mechanism and
221 use MemoryMax= as the last line of defense.
222 Takes a memory size in bytes. If the value is suffixed with K, M, G
224 or T, the specified memory size is parsed as Kilobytes, Megabytes,
225 Gigabytes, or Terabytes (with the base 1024), respectively.
226 Alternatively, a percentage value may be specified, which is taken
227 relative to the installed physical memory on the system. If
228 assigned the special value "infinity", no memory limit is applied.
229 This controls the "memory.max" control group attribute. For details
230 about this control group attribute, see cgroup-v2.txt[2].
231 This setting replaces MemoryLimit=.
233 MemorySwapMax=bytes
235 Specify the absolute limit on swap usage of the executed processes
236 in this unit.
237 Takes a swap size in bytes. If the value is suffixed with K, M, G
239 or T, the specified swap size is parsed as Kilobytes, Megabytes,
240 Gigabytes, or Terabytes (with the base 1024), respectively. If
241 assigned the special value "infinity", no swap limit is applied.
242 This controls the "memory.swap.max" control group attribute. For
243 details about this control group attribute, see cgroup-v2.txt[2].
244 This setting is supported only if the unified control group
246 hierarchy is used and disables MemoryLimit=.
247 TasksAccounting=
249 Turn on task accounting for this unit. Takes a boolean argument. If
250 enabled, the system manager will keep track of the number of tasks
251 in the unit. The number of tasks accounted this way includes both
252 kernel threads and userspace processes, with each thread counting
253 individually. Note that turning on tasks accounting for one unit
254 will also implicitly turn it on for all units contained in the same
255 slice and for all its parent slices and the units contained
256 therein. The system default for this setting may be controlled with
257 DefaultTasksAccounting= in systemd-system.conf(5).
258 TasksMax=N
260 Specify the maximum number of tasks that may be created in the
261 unit. This ensures that the number of tasks accounted for the unit
262 (see above) stays below a specific limit. This either takes an
263 absolute number of tasks or a percentage value that is taken
264 relative to the configured maximum number of tasks on the system.
265 If assigned the special value "infinity", no tasks limit is
266 applied. This controls the "pids.max" control group attribute. For
267 details about this control group attribute, see pids.txt[6].
268 The system default for this setting may be controlled with
270 DefaultTasksMax= in systemd-system.conf(5).
271 IOAccounting=
273 Turn on Block I/O accounting for this unit, if the unified control
274 group hierarchy is used on the system. Takes a boolean argument.
275 Note that turning on block I/O accounting for one unit will also
276 implicitly turn it on for all units contained in the same slice and
277 all for its parent slices and the units contained therein. The
278 system default for this setting may be controlled with
279 DefaultIOAccounting= in systemd-system.conf(5).
280 This setting replaces BlockIOAccounting= and disables settings
282 prefixed with BlockIO or StartupBlockIO.
283 IOWeight=weight, StartupIOWeight=weight
285 Set the default overall block I/O weight for the executed
286 processes, if the unified control group hierarchy is used on the
287 system. Takes a single weight value (between 1 and 10000) to set
288 the default block I/O weight. This controls the "io.weight" control
289 group attribute, which defaults to 100. For details about this
290 control group attribute, see cgroup-v2.txt[2]. The available I/O
291 bandwidth is split up among all units within one slice relative to
292 their block I/O weight.
293 While StartupIOWeight= only applies to the startup phase of the
295 system, IOWeight= applies to the later runtime of the system, and
296 if the former is not set also to the startup phase. This allows
297 prioritizing specific services at boot-up differently than during
298 runtime.
299 These settings replace BlockIOWeight= and StartupBlockIOWeight= and
301 disable settings prefixed with BlockIO or StartupBlockIO.
302 IODeviceWeight=device weight
304 Set the per-device overall block I/O weight for the executed
305 processes, if the unified control group hierarchy is used on the
306 system. Takes a space-separated pair of a file path and a weight
307 value to specify the device specific weight value, between 1 and
308 10000. (Example: "/dev/sda 1000"). The file path may be specified
309 as path to a block device node or as any other file, in which case
310 the backing block device of the file system of the file is
311 determined. This controls the "io.weight" control group attribute,
312 which defaults to 100. Use this option multiple times to set
313 weights for multiple devices. For details about this control group
314 attribute, see cgroup-v2.txt[2].
315 This setting replaces BlockIODeviceWeight= and disables settings
317 prefixed with BlockIO or StartupBlockIO.
318 IOReadBandwidthMax=device bytes, IOWriteBandwidthMax=device bytes
320 Set the per-device overall block I/O bandwidth maximum limit for
321 the executed processes, if the unified control group hierarchy is
322 used on the system. This limit is not work-conserving and the
323 executed processes are not allowed to use more even if the device
324 has idle capacity. Takes a space-separated pair of a file path and
325 a bandwidth value (in bytes per second) to specify the device
326 specific bandwidth. The file path may be a path to a block device
327 node, or as any other file in which case the backing block device
328 of the file system of the file is used. If the bandwidth is
329 suffixed with K, M, G, or T, the specified bandwidth is parsed as
330 Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the
331 base of 1000. (Example:
332 "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This
333 controls the "io.max" control group attributes. Use this option
334 multiple times to set bandwidth limits for multiple devices. For
335 details about this control group attribute, see cgroup-v2.txt[2].
336 These settings replace BlockIOReadBandwidth= and
338 BlockIOWriteBandwidth= and disable settings prefixed with BlockIO
339 or StartupBlockIO.
340 IOReadIOPSMax=device IOPS, IOWriteIOPSMax=device IOPS
342 Set the per-device overall block I/O IOs-Per-Second maximum limit
343 for the executed processes, if the unified control group hierarchy
344 is used on the system. This limit is not work-conserving and the
345 executed processes are not allowed to use more even if the device
346 has idle capacity. Takes a space-separated pair of a file path and
347 an IOPS value to specify the device specific IOPS. The file path
348 may be a path to a block device node, or as any other file in which
349 case the backing block device of the file system of the file is
350 used. If the IOPS is suffixed with K, M, G, or T, the specified
351 IOPS is parsed as KiloIOPS, MegaIOPS, GigaIOPS, or TeraIOPS,
352 respectively, to the base of 1000. (Example:
353 "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K"). This
354 controls the "io.max" control group attributes. Use this option
355 multiple times to set IOPS limits for multiple devices. For details
356 about this control group attribute, see cgroup-v2.txt[2].
357 These settings are supported only if the unified control group
359 hierarchy is used and disable settings prefixed with BlockIO or
360 StartupBlockIO.
361 IODeviceLatencyTargetSec=device target
363 Set the per-device average target I/O latency for the executed
364 processes, if the unified control group hierarchy is used on the
365 system. Takes a file path and a timespan separated by a space to
366 specify the device specific latency target. (Example: "/dev/sda
367 25ms"). The file path may be specified as path to a block device
368 node or as any other file, in which case the backing block device
369 of the file system of the file is determined. This controls the
370 "io.latency" control group attribute. Use this option multiple
371 times to set latency target for multiple devices. For details about
372 this control group attribute, see cgroup-v2.txt[2].
373 Implies "IOAccounting=yes".
375 These settings are supported only if the unified control group
377 hierarchy is used.
378 IPAccounting=
380 Takes a boolean argument. If true, turns on IPv4 and IPv6 network
381 traffic accounting for packets sent or received by the unit. When
382 this option is turned on, all IPv4 and IPv6 sockets created by any
383 process of the unit are accounted for.
384 When this option is used in socket units, it applies to all IPv4
386 and IPv6 sockets associated with it (including both listening and
387 connection sockets where this applies). Note that for
388 socket-activated services, this configuration setting and the
389 accounting data of the service unit and the socket unit are kept
390 separate, and displayed separately. No propagation of the setting
391 and the collected statistics is done, in either direction.
392 Moreover, any traffic sent or received on any of the socket unit's
393 sockets is accounted to the socket unit — and never to the service
394 unit it might have activated, even if the socket is used by it.
395 The system default for this setting may be controlled with
397 DefaultIPAccounting= in systemd-system.conf(5).
398 IPAddressAllow=ADDRESS[/PREFIXLENGTH]...,
400 IPAddressDeny=ADDRESS[/PREFIXLENGTH]...
401 Turn on address range network traffic filtering for IP packets sent
402 and received over AF_INET and AF_INET6 sockets. Both directives
403 take a space separated list of IPv4 or IPv6 addresses, each
404 optionally suffixed with an address prefix length in bits
405 (separated by a "/" character). If the latter is omitted, the
406 address is considered a host address, i.e. the prefix covers the
407 whole address (32 for IPv4, 128 for IPv6).
408 The access lists configured with this option are applied to all
410 sockets created by processes of this unit (or in the case of socket
411 units, associated with it). The lists are implicitly combined with
412 any lists configured for any of the parent slice units this unit
413 might be a member of. By default all access lists are empty. Both
414 ingress and egress traffic is filtered by these settings. In case
415 of ingress traffic the source IP address is checked against these
416 access lists, in case of egress traffic the destination IP address
417 is checked. When configured the lists are enforced as follows:
418 · Access will be granted in case an IP packet's
420 destination/source address matches any entry in the
421 IPAddressAllow= setting.
422 · Otherwise, access will be denied in case its destination/source
424 address matches any entry in the IPAddressDeny= setting.
425 · Otherwise, access will be granted.
427 In order to implement a whitelisting IP firewall, it is recommended
429 to use a IPAddressDeny=any setting on an upper-level slice unit
430 (such as the root slice -.slice or the slice containing all system
431 services system.slice – see systemd.special(7) for details on these
432 slice units), plus individual per-service IPAddressAllow= lines
433 permitting network access to relevant services, and only them.
434 Note that for socket-activated services, the IP access list
436 configured on the socket unit applies to all sockets associated
437 with it directly, but not to any sockets created by the ultimately
438 activated services for it. Conversely, the IP access list
439 configured for the service is not applied to any sockets passed
440 into the service via socket activation. Thus, it is usually a good
441 idea, to replicate the IP access lists on both the socket and the
442 service unit, however it often makes sense to maintain one list
443 more open and the other one more restricted, depending on the
444 usecase.
445 If these settings are used multiple times in the same unit the
447 specified lists are combined. If an empty string is assigned to
448 these settings the specific access list is reset and all previous
449 settings undone.
450 In place of explicit IPv4 or IPv6 address and prefix length
452 specifications a small set of symbolic names may be used. The
453 following names are defined:
454 Table 1. Special address/network names
456 ┌──────────────┬─────────────────────┬─────────────────────┐
457 │Symbolic Name │ Definition │ Meaning │
458 ├──────────────┼─────────────────────┼─────────────────────┤
459 │any │ 0.0.0.0/0 ::/0 │ Any host │
460 ├──────────────┼─────────────────────┼─────────────────────┤
461 │localhost │ 127.0.0.0/8 ::1/128 │ All addresses on │
462 │ │ │ the local loopback │
463 ├──────────────┼─────────────────────┼─────────────────────┤
464 │link-local │ 169.254.0.0/16 │ All link-local IP │
465 │ │ fe80::/64 │ addresses │
466 ├──────────────┼─────────────────────┼─────────────────────┤
467 │multicast │ 224.0.0.0/4 │ All IP multicasting │
468 │ │ ff00::/8 │ addresses │
469 └──────────────┴─────────────────────┴─────────────────────┘
470 Note that these settings might not be supported on some systems
471 (for example if eBPF control group support is not enabled in the
472 underlying kernel or container manager). These settings will have
473 no effect in that case. If compatibility with such systems is
474 desired it is hence recommended to not exclusively rely on them for
475 IP security.
476 IPIngressFilterPath=BPF_FS_PROGRAMM_PATH,
478 IPEgressFilterPath=BPF_FS_PROGRAMM_PATH
479 Add custom network traffic filters implemented as BPF programs,
480 applying to all IP packets sent and received over AF_INET and
481 AF_INET6 sockets. Takes an absolute path to a pinned BPF program in
482 the BPF virtual filesystem (/sys/fs/bpf/).
483 The filters configured with this option are applied to all sockets
485 created by processes of this unit (or in the case of socket units,
486 associated with it). The filters are loaded in addition to filters
487 any of the parent slice units this unit might be a member of as
488 well as any IPAddressAllow= and IPAddressDeny= filters in any of
489 these units. By default there are no filters specified.
490 If these settings are used multiple times in the same unit all the
492 specified programs are attached. If an empty string is assigned to
493 these settings the program list is reset and all previous specified
494 programs ignored.
495 Note that for socket-activated services, the IP filter programs
497 configured on the socket unit apply to all sockets associated with
498 it directly, but not to any sockets created by the ultimately
499 activated services for it. Conversely, the IP filter programs
500 configured for the service are not applied to any sockets passed
501 into the service via socket activation. Thus, it is usually a good
502 idea, to replicate the IP filter programs on both the socket and
503 the service unit, however it often makes sense to maintain one
504 configuration more open and the other one more restricted,
505 depending on the usecase.
506 Note that these settings might not be supported on some systems
508 (for example if eBPF control group support is not enabled in the
509 underlying kernel or container manager). These settings will fail
510 the service in that case. If compatibility with such systems is
511 desired it is hence recommended to attach your filter manually
512 (requires Delegate=yes) instead of using this setting.
513 DeviceAllow=
515 Control access to specific device nodes by the executed processes.
516 Takes two space-separated strings: a device node specifier followed
517 by a combination of r, w, m to control reading, writing, or
518 creation of the specific device node(s) by the unit (mknod),
519 respectively. On cgroup-v1 this controls the "devices.allow"
520 control group attribute. For details about this control group
521 attribute, see devices.txt[7]. On cgroup-v2 this functionality is
522 implemented using eBPF filtering.
523 The device node specifier is either a path to a device node in the
525 file system, starting with /dev/, or a string starting with either
526 "char-" or "block-" followed by a device group name, as listed in
527 /proc/devices. The latter is useful to whitelist all current and
528 future devices belonging to a specific device group at once. The
529 device group is matched according to filename globbing rules, you
530 may hence use the "*" and "?" wildcards. (Note that such globbing
531 wildcards are not available for device node path specifications!)
532 In order to match device nodes by numeric major/minor, use device
533 node paths in the /dev/char/ and /dev/block/ directories. However,
534 matching devices by major/minor is generally not recommended as
535 assignments are neither stable nor portable between systems or
536 different kernel versions.
537 Examples: /dev/sda5 is a path to a device node, referring to an ATA
539 or SCSI block device. "char-pts" and "char-alsa" are specifiers
540 for all pseudo TTYs and all ALSA sound devices, respectively.
541 "char-cpu/*" is a specifier matching all CPU related device groups.
542 Note that whitelists defined this way should only reference device
544 groups which are resolvable at the time the unit is started. Any
545 device groups not resolvable then are not added to the device
546 whitelist. In order to work around this limitation, consider
547 extending service units with an ExecStartPre=/sbin/modprobe...
548 line that loads the necessary kernel module implementing the device
549 group if missing. Example:
550 ...
552 [Service]
553 ExecStartPre=-/sbin/modprobe -abq loop
554 DeviceAllow=block-loop
555 DeviceAllow=/dev/loop-control
556 ...
557 DevicePolicy=auto|closed|strict
559 Control the policy for allowing device access:
560 strict
562 means to only allow types of access that are explicitly
563 specified.
564 closed
566 in addition, allows access to standard pseudo devices including
567 /dev/null, /dev/zero, /dev/full, /dev/random, and /dev/urandom.
568 auto
570 in addition, allows access to all devices if no explicit
571 DeviceAllow= is present. This is the default.
572 Slice=
574 The name of the slice unit to place the unit in. Defaults to
575 system.slice for all non-instantiated units of all unit types
576 (except for slice units themselves see below). Instance units are
577 by default placed in a subslice of system.slice that is named after
578 the template name.
579 This option may be used to arrange systemd units in a hierarchy of
581 slices each of which might have resource settings applied.
582 For units of type slice, the only accepted value for this setting
584 is the parent slice. Since the name of a slice unit implies the
585 parent slice, it is hence redundant to ever set this parameter
586 directly for slice units.
587 Special care should be taken when relying on the default slice
589 assignment in templated service units that have
590 DefaultDependencies=no set, see systemd.service(5), section
591 "Default Dependencies" for details.
592 Delegate=
594 Turns on delegation of further resource control partitioning to
595 processes of the unit. Units where this is enabled may create and
596 manage their own private subhierarchy of control groups below the
597 control group of the unit itself. For unprivileged services (i.e.
598 those using the User= setting) the unit's control group will be
599 made accessible to the relevant user. When enabled the service
600 manager will refrain from manipulating control groups or moving
601 processes below the unit's control group, so that a clear concept
602 of ownership is established: the control group tree above the
603 unit's control group (i.e. towards the root control group) is owned
604 and managed by the service manager of the host, while the control
605 group tree below the unit's control group is owned and managed by
606 the unit itself. Takes either a boolean argument or a list of
607 control group controller names. If true, delegation is turned on,
608 and all supported controllers are enabled for the unit, making them
609 available to the unit's processes for management. If false,
610 delegation is turned off entirely (and no additional controllers
611 are enabled). If set to a list of controllers, delegation is turned
612 on, and the specified controllers are enabled for the unit. Note
613 that additional controllers than the ones specified might be made
614 available as well, depending on configuration of the containing
615 slice unit or other units contained in it. Note that assigning the
616 empty string will enable delegation, but reset the list of
617 controllers, all assignments prior to this will have no effect.
618 Defaults to false.
619 Note that controller delegation to less privileged code is only
621 safe on the unified control group hierarchy. Accordingly, access to
622 the specified controllers will not be granted to unprivileged
623 services on the legacy hierarchy, even when requested.
624 The following controller names may be specified: cpu, cpuacct, io,
626 blkio, memory, devices, pids. Not all of these controllers are
627 available on all kernels however, and some are specific to the
628 unified hierarchy while others are specific to the legacy
629 hierarchy. Also note that the kernel might support further
630 controllers, which aren't covered here yet as delegation is either
631 not supported at all for them or not defined cleanly.
632 For further details on the delegation model consult Control Group
634 APIs and Delegation[8].
635 DisableControllers=
637 Disables controllers from being enabled for a unit's children. If a
638 controller listed is already in use in its subtree, the controller
639 will be removed from the subtree. This can be used to avoid child
640 units being able to implicitly or explicitly enable a controller.
641 Defaults to not disabling any controllers.
642 It may not be possible to successfully disable a controller if the
644 unit or any child of the unit in question delegates controllers to
645 its children, as any delegated subtree of the cgroup hierarchy is
646 unmanaged by systemd.
647 Multiple controllers may be specified, separated by spaces. You may
649 also pass DisableControllers= multiple times, in which case each
650 new instance adds another controller to disable. Passing
651 DisableControllers= by itself with no controller name present
652 resets the disabled controller list.
653 Valid controllers are cpu, cpuacct, io, blkio, memory, devices, and
655 pids.
656
658 The following options are deprecated. Use the indicated superseding
659 options instead:
660 CPUShares=weight, StartupCPUShares=weight
662 Assign the specified CPU time share weight to the processes
663 executed. These options take an integer value and control the
664 "cpu.shares" control group attribute. The allowed range is 2 to
665 262144. Defaults to 1024. For details about this control group
666 attribute, see sched-design-CFS.txt[4]. The available CPU time is
667 split up among all units within one slice relative to their CPU
668 time share weight.
669 While StartupCPUShares= only applies to the startup phase of the
671 system, CPUShares= applies to normal runtime of the system, and if
672 the former is not set also to the startup phase. Using
673 StartupCPUShares= allows prioritizing specific services at boot-up
674 differently than during normal runtime.
675 Implies "CPUAccounting=yes".
677 These settings are deprecated. Use CPUWeight= and StartupCPUWeight=
679 instead.
680 MemoryLimit=bytes
682 Specify the limit on maximum memory usage of the executed
683 processes. The limit specifies how much process and kernel memory
684 can be used by tasks in this unit. Takes a memory size in bytes. If
685 the value is suffixed with K, M, G or T, the specified memory size
686 is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with
687 the base 1024), respectively. Alternatively, a percentage value may
688 be specified, which is taken relative to the installed physical
689 memory on the system. If assigned the special value "infinity", no
690 memory limit is applied. This controls the "memory.limit_in_bytes"
691 control group attribute. For details about this control group
692 attribute, see memory.txt[9].
693 Implies "MemoryAccounting=yes".
695 This setting is deprecated. Use MemoryMax= instead.
697 BlockIOAccounting=
699 Turn on Block I/O accounting for this unit, if the legacy control
700 group hierarchy is used on the system. Takes a boolean argument.
701 Note that turning on block I/O accounting for one unit will also
702 implicitly turn it on for all units contained in the same slice and
703 all for its parent slices and the units contained therein. The
704 system default for this setting may be controlled with
705 DefaultBlockIOAccounting= in systemd-system.conf(5).
706 This setting is deprecated. Use IOAccounting= instead.
708 BlockIOWeight=weight, StartupBlockIOWeight=weight
710 Set the default overall block I/O weight for the executed
711 processes, if the legacy control group hierarchy is used on the
712 system. Takes a single weight value (between 10 and 1000) to set
713 the default block I/O weight. This controls the "blkio.weight"
714 control group attribute, which defaults to 500. For details about
715 this control group attribute, see blkio-controller.txt[10]. The
716 available I/O bandwidth is split up among all units within one
717 slice relative to their block I/O weight.
718 While StartupBlockIOWeight= only applies to the startup phase of
720 the system, BlockIOWeight= applies to the later runtime of the
721 system, and if the former is not set also to the startup phase.
722 This allows prioritizing specific services at boot-up differently
723 than during runtime.
724 Implies "BlockIOAccounting=yes".
726 These settings are deprecated. Use IOWeight= and StartupIOWeight=
728 instead.
729 BlockIODeviceWeight=device weight
731 Set the per-device overall block I/O weight for the executed
732 processes, if the legacy control group hierarchy is used on the
733 system. Takes a space-separated pair of a file path and a weight
734 value to specify the device specific weight value, between 10 and
735 1000. (Example: "/dev/sda 500"). The file path may be specified as
736 path to a block device node or as any other file, in which case the
737 backing block device of the file system of the file is determined.
738 This controls the "blkio.weight_device" control group attribute,
739 which defaults to 1000. Use this option multiple times to set
740 weights for multiple devices. For details about this control group
741 attribute, see blkio-controller.txt[10].
742 Implies "BlockIOAccounting=yes".
744 This setting is deprecated. Use IODeviceWeight= instead.
746 BlockIOReadBandwidth=device bytes, BlockIOWriteBandwidth=device bytes
748 Set the per-device overall block I/O bandwidth limit for the
749 executed processes, if the legacy control group hierarchy is used
750 on the system. Takes a space-separated pair of a file path and a
751 bandwidth value (in bytes per second) to specify the device
752 specific bandwidth. The file path may be a path to a block device
753 node, or as any other file in which case the backing block device
754 of the file system of the file is used. If the bandwidth is
755 suffixed with K, M, G, or T, the specified bandwidth is parsed as
756 Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the
757 base of 1000. (Example:
758 "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This
759 controls the "blkio.throttle.read_bps_device" and
760 "blkio.throttle.write_bps_device" control group attributes. Use
761 this option multiple times to set bandwidth limits for multiple
762 devices. For details about these control group attributes, see
763 blkio-controller.txt[10].
764 Implies "BlockIOAccounting=yes".
766 These settings are deprecated. Use IOReadBandwidthMax= and
768 IOWriteBandwidthMax= instead.
769
771 systemd(1), systemd-system.conf(5), systemd.unit(5),
772 systemd.service(5), systemd.slice(5), systemd.scope(5),
773 systemd.socket(5), systemd.mount(5), systemd.swap(5), systemd.exec(5),
774 systemd.directives(7), systemd.special(7), The documentation for
775 control groups and specific controllers in the Linux kernel:
776 cgroups.txt[3], cpuacct.txt[11], memory.txt[9],
777 blkio-controller.txt[10]. sched-bwc.txt[5].
778
780 1. New Control Group Interfaces
781 https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
782 2. cgroup-v2.txt
784 https://www.kernel.org/doc/Documentation/cgroup-v2.txt
785 3. cgroups.txt
787 https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
788 4. sched-design-CFS.txt
790 https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt
791 5. sched-bwc.txt
793 https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt
794 6. pids.txt
796 https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
797 7. devices.txt
799 https://www.kernel.org/doc/Documentation/cgroup-v1/devices.txt
800 8. Control Group APIs and Delegation
802 https://systemd.io/CGROUP_DELEGATION
803 9. memory.txt
805 https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
806 10. blkio-controller.txt
808 https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt
809 11. cpuacct.txt
811 https://www.kernel.org/doc/Documentation/cgroup-v1/cpuacct.txt
812systemd 243 SYSTEMD.RESOURCE-CONTROL(5)