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 MemoryAccounting=
120 Turn on process and kernel memory accounting for this unit. Takes a
121 boolean argument. Note that turning on memory accounting for one
122 unit will also implicitly turn it on for all units contained in the
123 same slice and for all its parent slices and the units contained
124 therein. The system default for this setting may be controlled with
125 DefaultMemoryAccounting= in systemd-system.conf(5).
126 MemoryMin=bytes
128 Specify the memory usage protection of the executed processes in
129 this unit. If the memory usages of this unit and all its ancestors
130 are below their minimum boundaries, this unit's memory won't be
131 reclaimed.
132 Takes a memory size in bytes. If the value is suffixed with K, M, G
134 or T, the specified memory size is parsed as Kilobytes, Megabytes,
135 Gigabytes, or Terabytes (with the base 1024), respectively.
136 Alternatively, a percentage value may be specified, which is taken
137 relative to the installed physical memory on the system. This
138 controls the "memory.min" control group attribute. For details
139 about this control group attribute, see cgroup-v2.txt[2].
140 This setting is supported only if the unified control group
142 hierarchy is used and disables MemoryLimit=.
143 MemoryLow=bytes
145 Specify the best-effort memory usage protection of the executed
146 processes in this unit. If the memory usages of this unit and all
147 its ancestors are below their low boundaries, this unit's memory
148 won't be reclaimed as long as memory can be reclaimed from
149 unprotected units.
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. This
156 controls the "memory.low" control group attribute. For details
157 about this control group attribute, see cgroup-v2.txt[2].
158 This setting is supported only if the unified control group
160 hierarchy is used and disables MemoryLimit=.
161 MemoryHigh=bytes
163 Specify the high limit on memory usage of the executed processes in
164 this unit. Memory usage may go above the limit if unavoidable, but
165 the processes are heavily slowed down and memory is taken away
166 aggressively in such cases. This is the main mechanism to control
167 memory usage of a unit.
168 Takes a memory size in bytes. If the value is suffixed with K, M, G
170 or T, the specified memory size is parsed as Kilobytes, Megabytes,
171 Gigabytes, or Terabytes (with the base 1024), respectively.
172 Alternatively, a percentage value may be specified, which is taken
173 relative to the installed physical memory on the system. If
174 assigned the special value "infinity", no memory limit is applied.
175 This controls the "memory.high" control group attribute. For
176 details about this control group attribute, see cgroup-v2.txt[2].
177 This setting is supported only if the unified control group
179 hierarchy is used and disables MemoryLimit=.
180 MemoryMax=bytes
182 Specify the absolute limit on memory usage of the executed
183 processes in this unit. If memory usage cannot be contained under
184 the limit, out-of-memory killer is invoked inside the unit. It is
185 recommended to use MemoryHigh= as the main control mechanism and
186 use MemoryMax= as the last line of defense.
187 Takes a memory size in bytes. If the value is suffixed with K, M, G
189 or T, the specified memory size is parsed as Kilobytes, Megabytes,
190 Gigabytes, or Terabytes (with the base 1024), respectively.
191 Alternatively, a percentage value may be specified, which is taken
192 relative to the installed physical memory on the system. If
193 assigned the special value "infinity", no memory limit is applied.
194 This controls the "memory.max" control group attribute. For details
195 about this control group attribute, see cgroup-v2.txt[2].
196 This setting replaces MemoryLimit=.
198 MemorySwapMax=bytes
200 Specify the absolute limit on swap usage of the executed processes
201 in this unit.
202 Takes a swap size in bytes. If the value is suffixed with K, M, G
204 or T, the specified swap size is parsed as Kilobytes, Megabytes,
205 Gigabytes, or Terabytes (with the base 1024), respectively. If
206 assigned the special value "infinity", no swap limit is applied.
207 This controls the "memory.swap.max" control group attribute. For
208 details about this control group attribute, see cgroup-v2.txt[2].
209 This setting is supported only if the unified control group
211 hierarchy is used and disables MemoryLimit=.
212 TasksAccounting=
214 Turn on task accounting for this unit. Takes a boolean argument. If
215 enabled, the system manager will keep track of the number of tasks
216 in the unit. The number of tasks accounted this way includes both
217 kernel threads and userspace processes, with each thread counting
218 individually. Note that turning on tasks accounting for one unit
219 will also implicitly turn it on for all units contained in the same
220 slice and for all its parent slices and the units contained
221 therein. The system default for this setting may be controlled with
222 DefaultTasksAccounting= in systemd-system.conf(5).
223 TasksMax=N
225 Specify the maximum number of tasks that may be created in the
226 unit. This ensures that the number of tasks accounted for the unit
227 (see above) stays below a specific limit. This either takes an
228 absolute number of tasks or a percentage value that is taken
229 relative to the configured maximum number of tasks on the system.
230 If assigned the special value "infinity", no tasks limit is
231 applied. This controls the "pids.max" control group attribute. For
232 details about this control group attribute, see pids.txt[6].
233 The system default for this setting may be controlled with
235 DefaultTasksMax= in systemd-system.conf(5).
236 IOAccounting=
238 Turn on Block I/O accounting for this unit, if the unified control
239 group hierarchy is used on the system. Takes a boolean argument.
240 Note that turning on block I/O accounting for one unit will also
241 implicitly turn it on for all units contained in the same slice and
242 all for its parent slices and the units contained therein. The
243 system default for this setting may be controlled with
244 DefaultIOAccounting= in systemd-system.conf(5).
245 This setting replaces BlockIOAccounting= and disables settings
247 prefixed with BlockIO or StartupBlockIO.
248 IOWeight=weight, StartupIOWeight=weight
250 Set the default overall block I/O weight for the executed
251 processes, if the unified control group hierarchy is used on the
252 system. Takes a single weight value (between 1 and 10000) to set
253 the default block I/O weight. This controls the "io.weight" control
254 group attribute, which defaults to 100. For details about this
255 control group attribute, see cgroup-v2.txt[2]. The available I/O
256 bandwidth is split up among all units within one slice relative to
257 their block I/O weight.
258 While StartupIOWeight= only applies to the startup phase of the
260 system, IOWeight= applies to the later runtime of the system, and
261 if the former is not set also to the startup phase. This allows
262 prioritizing specific services at boot-up differently than during
263 runtime.
264 These settings replace BlockIOWeight= and StartupBlockIOWeight= and
266 disable settings prefixed with BlockIO or StartupBlockIO.
267 IODeviceWeight=device weight
269 Set the per-device overall block I/O weight for the executed
270 processes, if the unified control group hierarchy is used on the
271 system. Takes a space-separated pair of a file path and a weight
272 value to specify the device specific weight value, between 1 and
273 10000. (Example: "/dev/sda 1000"). The file path may be specified
274 as path to a block device node or as any other file, in which case
275 the backing block device of the file system of the file is
276 determined. This controls the "io.weight" control group attribute,
277 which defaults to 100. Use this option multiple times to set
278 weights for multiple devices. For details about this control group
279 attribute, see cgroup-v2.txt[2].
280 This setting replaces BlockIODeviceWeight= and disables settings
282 prefixed with BlockIO or StartupBlockIO.
283 IOReadBandwidthMax=device bytes, IOWriteBandwidthMax=device bytes
285 Set the per-device overall block I/O bandwidth maximum limit for
286 the executed processes, if the unified control group hierarchy is
287 used on the system. This limit is not work-conserving and the
288 executed processes are not allowed to use more even if the device
289 has idle capacity. Takes a space-separated pair of a file path and
290 a bandwidth value (in bytes per second) to specify the device
291 specific bandwidth. The file path may be a path to a block device
292 node, or as any other file in which case the backing block device
293 of the file system of the file is used. If the bandwidth is
294 suffixed with K, M, G, or T, the specified bandwidth is parsed as
295 Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the
296 base of 1000. (Example:
297 "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This
298 controls the "io.max" control group attributes. Use this option
299 multiple times to set bandwidth limits for multiple devices. For
300 details about this control group attribute, see cgroup-v2.txt[2].
301 These settings replace BlockIOReadBandwidth= and
303 BlockIOWriteBandwidth= and disable settings prefixed with BlockIO
304 or StartupBlockIO.
305 IOReadIOPSMax=device IOPS, IOWriteIOPSMax=device IOPS
307 Set the per-device overall block I/O IOs-Per-Second maximum limit
308 for the executed processes, if the unified control group hierarchy
309 is used on the system. This limit is not work-conserving and the
310 executed processes are not allowed to use more even if the device
311 has idle capacity. Takes a space-separated pair of a file path and
312 an IOPS value to specify the device specific IOPS. The file path
313 may be a path to a block device node, or as any other file in which
314 case the backing block device of the file system of the file is
315 used. If the IOPS is suffixed with K, M, G, or T, the specified
316 IOPS is parsed as KiloIOPS, MegaIOPS, GigaIOPS, or TeraIOPS,
317 respectively, to the base of 1000. (Example:
318 "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K"). This
319 controls the "io.max" control group attributes. Use this option
320 multiple times to set IOPS limits for multiple devices. For details
321 about this control group attribute, see cgroup-v2.txt[2].
322 These settings are supported only if the unified control group
324 hierarchy is used and disable settings prefixed with BlockIO or
325 StartupBlockIO.
326 IODeviceLatencyTargetSec=device target
328 Set the per-device average target I/O latency for the executed
329 processes, if the unified control group hierarchy is used on the
330 system. Takes a file path and a timespan separated by a space to
331 specify the device specific latency target. (Example: "/dev/sda
332 25ms"). The file path may be specified as path to a block device
333 node or as any other file, in which case the backing block device
334 of the file system of the file is determined. This controls the
335 "io.latency" control group attribute. Use this option multiple
336 times to set latency target for multiple devices. For details about
337 this control group attribute, see cgroup-v2.txt[2].
338 Implies "IOAccounting=yes".
340 These settings are supported only if the unified control group
342 hierarchy is used.
343 IPAccounting=
345 Takes a boolean argument. If true, turns on IPv4 and IPv6 network
346 traffic accounting for packets sent or received by the unit. When
347 this option is turned on, all IPv4 and IPv6 sockets created by any
348 process of the unit are accounted for.
349 When this option is used in socket units, it applies to all IPv4
351 and IPv6 sockets associated with it (including both listening and
352 connection sockets where this applies). Note that for
353 socket-activated services, this configuration setting and the
354 accounting data of the service unit and the socket unit are kept
355 separate, and displayed separately. No propagation of the setting
356 and the collected statistics is done, in either direction.
357 Moreover, any traffic sent or received on any of the socket unit's
358 sockets is accounted to the socket unit — and never to the service
359 unit it might have activated, even if the socket is used by it.
360 The system default for this setting may be controlled with
362 DefaultIPAccounting= in systemd-system.conf(5).
363 IPAddressAllow=ADDRESS[/PREFIXLENGTH]...,
365 IPAddressDeny=ADDRESS[/PREFIXLENGTH]...
366 Turn on address range network traffic filtering for packets sent
367 and received over AF_INET and AF_INET6 sockets. Both directives
368 take a space separated list of IPv4 or IPv6 addresses, each
369 optionally suffixed with an address prefix length (separated by a
370 "/" character). If the latter is omitted, the address is considered
371 a host address, i.e. the prefix covers the whole address (32 for
372 IPv4, 128 for IPv6).
373 The access lists configured with this option are applied to all
375 sockets created by processes of this unit (or in the case of socket
376 units, associated with it). The lists are implicitly combined with
377 any lists configured for any of the parent slice units this unit
378 might be a member of. By default all access lists are empty. When
379 configured the lists are enforced as follows:
380 · Access will be granted in case its destination/source address
382 matches any entry in the IPAddressAllow= setting.
383 · Otherwise, access will be denied in case its destination/source
385 address matches any entry in the IPAddressDeny= setting.
386 · Otherwise, access will be granted.
388 In order to implement a whitelisting IP firewall, it is recommended
390 to use a IPAddressDeny=any setting on an upper-level slice unit
391 (such as the root slice -.slice or the slice containing all system
392 services system.slice – see systemd.special(7) for details on these
393 slice units), plus individual per-service IPAddressAllow= lines
394 permitting network access to relevant services, and only them.
395 Note that for socket-activated services, the IP access list
397 configured on the socket unit applies to all sockets associated
398 with it directly, but not to any sockets created by the ultimately
399 activated services for it. Conversely, the IP access list
400 configured for the service is not applied to any sockets passed
401 into the service via socket activation. Thus, it is usually a good
402 idea, to replicate the IP access lists on both the socket and the
403 service unit, however it often makes sense to maintain one list
404 more open and the other one more restricted, depending on the
405 usecase.
406 If these settings are used multiple times in the same unit the
408 specified lists are combined. If an empty string is assigned to
409 these settings the specific access list is reset and all previous
410 settings undone.
411 In place of explicit IPv4 or IPv6 address and prefix length
413 specifications a small set of symbolic names may be used. The
414 following names are defined:
415 Table 1. Special address/network names
417 ┌──────────────┬─────────────────────┬─────────────────────┐
418 │Symbolic Name │ Definition │ Meaning │
419 ├──────────────┼─────────────────────┼─────────────────────┤
420 │any │ 0.0.0.0/0 ::/0 │ Any host │
421 ├──────────────┼─────────────────────┼─────────────────────┤
422 │localhost │ 127.0.0.0/8 ::1/128 │ All addresses on │
423 │ │ │ the local loopback │
424 ├──────────────┼─────────────────────┼─────────────────────┤
425 │link-local │ 169.254.0.0/16 │ All link-local IP │
426 │ │ fe80::/64 │ addresses │
427 ├──────────────┼─────────────────────┼─────────────────────┤
428 │multicast │ 224.0.0.0/4 │ All IP multicasting │
429 │ │ ff00::/8 │ addresses │
430 └──────────────┴─────────────────────┴─────────────────────┘
431 Note that these settings might not be supported on some systems
432 (for example if eBPF control group support is not enabled in the
433 underlying kernel or container manager). These settings will have
434 no effect in that case. If compatibility with such systems is
435 desired it is hence recommended to not exclusively rely on them for
436 IP security.
437 DeviceAllow=
439 Control access to specific device nodes by the executed processes.
440 Takes two space-separated strings: a device node specifier followed
441 by a combination of r, w, m to control reading, writing, or
442 creation of the specific device node(s) by the unit (mknod),
443 respectively. This controls the "devices.allow" and "devices.deny"
444 control group attributes. For details about these control group
445 attributes, see devices.txt[7].
446 The device node specifier is either a path to a device node in the
448 file system, starting with /dev/, or a string starting with either
449 "char-" or "block-" followed by a device group name, as listed in
450 /proc/devices. The latter is useful to whitelist all current and
451 future devices belonging to a specific device group at once. The
452 device group is matched according to filename globbing rules, you
453 may hence use the "*" and "?" wildcards. Examples: /dev/sda5 is a
454 path to a device node, referring to an ATA or SCSI block device.
455 "char-pts" and "char-alsa" are specifiers for all pseudo TTYs and
456 all ALSA sound devices, respectively. "char-cpu/*" is a specifier
457 matching all CPU related device groups.
458 DevicePolicy=auto|closed|strict
460 Control the policy for allowing device access:
461 strict
463 means to only allow types of access that are explicitly
464 specified.
465 closed
467 in addition, allows access to standard pseudo devices including
468 /dev/null, /dev/zero, /dev/full, /dev/random, and /dev/urandom.
469 auto
471 in addition, allows access to all devices if no explicit
472 DeviceAllow= is present. This is the default.
473 Slice=
475 The name of the slice unit to place the unit in. Defaults to
476 system.slice for all non-instantiated units of all unit types
477 (except for slice units themselves see below). Instance units are
478 by default placed in a subslice of system.slice that is named after
479 the template name.
480 This option may be used to arrange systemd units in a hierarchy of
482 slices each of which might have resource settings applied.
483 For units of type slice, the only accepted value for this setting
485 is the parent slice. Since the name of a slice unit implies the
486 parent slice, it is hence redundant to ever set this parameter
487 directly for slice units.
488 Special care should be taken when relying on the default slice
490 assignment in templated service units that have
491 DefaultDependencies=no set, see systemd.service(5), section
492 "Default Dependencies" for details.
493 Delegate=
495 Turns on delegation of further resource control partitioning to
496 processes of the unit. Units where this is enabled may create and
497 manage their own private subhierarchy of control groups below the
498 control group of the unit itself. For unprivileged services (i.e.
499 those using the User= setting) the unit's control group will be
500 made accessible to the relevant user. When enabled the service
501 manager will refrain from manipulating control groups or moving
502 processes below the unit's control group, so that a clear concept
503 of ownership is established: the control group tree above the
504 unit's control group (i.e. towards the root control group) is owned
505 and managed by the service manager of the host, while the control
506 group tree below the unit's control group is owned and managed by
507 the unit itself. Takes either a boolean argument or a list of
508 control group controller names. If true, delegation is turned on,
509 and all supported controllers are enabled for the unit, making them
510 available to the unit's processes for management. If false,
511 delegation is turned off entirely (and no additional controllers
512 are enabled). If set to a list of controllers, delegation is turned
513 on, and the specified controllers are enabled for the unit. Note
514 that additional controllers than the ones specified might be made
515 available as well, depending on configuration of the containing
516 slice unit or other units contained in it. Note that assigning the
517 empty string will enable delegation, but reset the list of
518 controllers, all assignments prior to this will have no effect.
519 Defaults to false.
520 Note that controller delegation to less privileged code is only
522 safe on the unified control group hierarchy. Accordingly, access to
523 the specified controllers will not be granted to unprivileged
524 services on the legacy hierarchy, even when requested.
525 The following controller names may be specified: cpu, cpuacct, io,
527 blkio, memory, devices, pids. Not all of these controllers are
528 available on all kernels however, and some are specific to the
529 unified hierarchy while others are specific to the legacy
530 hierarchy. Also note that the kernel might support further
531 controllers, which aren't covered here yet as delegation is either
532 not supported at all for them or not defined cleanly.
533 For further details on the delegation model consult Control Group
535 APIs and Delegation[8].
536 DisableControllers=
538 Disables controllers from being enabled for a unit's children. If a
539 controller listed is already in use in its subtree, the controller
540 will be removed from the subtree. This can be used to avoid child
541 units being able to implicitly or explicitly enable a controller.
542 Defaults to not disabling any controllers.
543 It may not be possible to successfully disable a controller if the
545 unit or any child of the unit in question delegates controllers to
546 its children, as any delegated subtree of the cgroup hierarchy is
547 unmanaged by systemd.
548 Multiple controllers may be specified, separated by spaces. You may
550 also pass DisableControllers= multiple times, in which case each
551 new instance adds another controller to disable. Passing
552 DisableControllers= by itself with no controller name present
553 resets the disabled controller list.
554 Valid controllers are cpu, cpuacct, io, blkio, memory, devices, and
556 pids.
557
559 The following options are deprecated. Use the indicated superseding
560 options instead:
561 CPUShares=weight, StartupCPUShares=weight
563 Assign the specified CPU time share weight to the processes
564 executed. These options take an integer value and control the
565 "cpu.shares" control group attribute. The allowed range is 2 to
566 262144. Defaults to 1024. For details about this control group
567 attribute, see sched-design-CFS.txt[4]. The available CPU time is
568 split up among all units within one slice relative to their CPU
569 time share weight.
570 While StartupCPUShares= only applies to the startup phase of the
572 system, CPUShares= applies to normal runtime of the system, and if
573 the former is not set also to the startup phase. Using
574 StartupCPUShares= allows prioritizing specific services at boot-up
575 differently than during normal runtime.
576 Implies "CPUAccounting=yes".
578 These settings are deprecated. Use CPUWeight= and StartupCPUWeight=
580 instead.
581 MemoryLimit=bytes
583 Specify the limit on maximum memory usage of the executed
584 processes. The limit specifies how much process and kernel memory
585 can be used by tasks in this unit. Takes a memory size in bytes. If
586 the value is suffixed with K, M, G or T, the specified memory size
587 is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with
588 the base 1024), respectively. Alternatively, a percentage value may
589 be specified, which is taken relative to the installed physical
590 memory on the system. If assigned the special value "infinity", no
591 memory limit is applied. This controls the "memory.limit_in_bytes"
592 control group attribute. For details about this control group
593 attribute, see memory.txt[9].
594 Implies "MemoryAccounting=yes".
596 This setting is deprecated. Use MemoryMax= instead.
598 BlockIOAccounting=
600 Turn on Block I/O accounting for this unit, if the legacy control
601 group hierarchy is used on the system. Takes a boolean argument.
602 Note that turning on block I/O accounting for one unit will also
603 implicitly turn it on for all units contained in the same slice and
604 all for its parent slices and the units contained therein. The
605 system default for this setting may be controlled with
606 DefaultBlockIOAccounting= in systemd-system.conf(5).
607 This setting is deprecated. Use IOAccounting= instead.
609 BlockIOWeight=weight, StartupBlockIOWeight=weight
611 Set the default overall block I/O weight for the executed
612 processes, if the legacy control group hierarchy is used on the
613 system. Takes a single weight value (between 10 and 1000) to set
614 the default block I/O weight. This controls the "blkio.weight"
615 control group attribute, which defaults to 500. For details about
616 this control group attribute, see blkio-controller.txt[10]. The
617 available I/O bandwidth is split up among all units within one
618 slice relative to their block I/O weight.
619 While StartupBlockIOWeight= only applies to the startup phase of
621 the system, BlockIOWeight= applies to the later runtime of the
622 system, and if the former is not set also to the startup phase.
623 This allows prioritizing specific services at boot-up differently
624 than during runtime.
625 Implies "BlockIOAccounting=yes".
627 These settings are deprecated. Use IOWeight= and StartupIOWeight=
629 instead.
630 BlockIODeviceWeight=device weight
632 Set the per-device overall block I/O weight for the executed
633 processes, if the legacy control group hierarchy is used on the
634 system. Takes a space-separated pair of a file path and a weight
635 value to specify the device specific weight value, between 10 and
636 1000. (Example: "/dev/sda 500"). The file path may be specified as
637 path to a block device node or as any other file, in which case the
638 backing block device of the file system of the file is determined.
639 This controls the "blkio.weight_device" control group attribute,
640 which defaults to 1000. Use this option multiple times to set
641 weights for multiple devices. For details about this control group
642 attribute, see blkio-controller.txt[10].
643 Implies "BlockIOAccounting=yes".
645 This setting is deprecated. Use IODeviceWeight= instead.
647 BlockIOReadBandwidth=device bytes, BlockIOWriteBandwidth=device bytes
649 Set the per-device overall block I/O bandwidth limit for the
650 executed processes, if the legacy control group hierarchy is used
651 on the system. Takes a space-separated pair of a file path and a
652 bandwidth value (in bytes per second) to specify the device
653 specific bandwidth. The file path may be a path to a block device
654 node, or as any other file in which case the backing block device
655 of the file system of the file is used. If the bandwidth is
656 suffixed with K, M, G, or T, the specified bandwidth is parsed as
657 Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the
658 base of 1000. (Example:
659 "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This
660 controls the "blkio.throttle.read_bps_device" and
661 "blkio.throttle.write_bps_device" control group attributes. Use
662 this option multiple times to set bandwidth limits for multiple
663 devices. For details about these control group attributes, see
664 blkio-controller.txt[10].
665 Implies "BlockIOAccounting=yes".
667 These settings are deprecated. Use IOReadBandwidthMax= and
669 IOWriteBandwidthMax= instead.
670
672 systemd(1), systemd-system.conf(5), systemd.unit(5),
673 systemd.service(5), systemd.slice(5), systemd.scope(5),
674 systemd.socket(5), systemd.mount(5), systemd.swap(5), systemd.exec(5),
675 systemd.directives(7), systemd.special(7), The documentation for
676 control groups and specific controllers in the Linux kernel:
677 cgroups.txt[3], cpuacct.txt[11], memory.txt[9],
678 blkio-controller.txt[10]. sched-bwc.txt[5].
679
681 1. New Control Group Interfaces
682 https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
683 2. cgroup-v2.txt
685 https://www.kernel.org/doc/Documentation/cgroup-v2.txt
686 3. cgroups.txt
688 https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
689 4. sched-design-CFS.txt
691 https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt
692 5. sched-bwc.txt
694 https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt
695 6. pids.txt
697 https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
698 7. devices.txt
700 https://www.kernel.org/doc/Documentation/cgroup-v1/devices.txt
701 8. Control Group APIs and Delegation
703 https://systemd.io/CGROUP_DELEGATION
704 9. memory.txt
706 https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
707 10. blkio-controller.txt
709 https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt
710 11. cpuacct.txt
712 https://www.kernel.org/doc/Documentation/cgroup-v1/cpuacct.txt
713systemd 241 SYSTEMD.RESOURCE-CONTROL(5)