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