"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
+ SPDX-License-Identifier: LGPL-2.1+
+
This file is part of systemd.
Copyright 2013 Zbigniew Jędrzejewski-Szmek
<refsect1>
<title>Description</title>
- <para>Unit configuration files for services, slices, scopes,
- sockets, mount points, and swap devices share a subset of
- configuration options for resource control of spawned
- processes. Internally, this relies on the Control Groups
- kernel concept for organizing processes in a hierarchical tree of
- named groups for the purpose of resource management.</para>
+ <para>Unit configuration files for services, slices, scopes, sockets, mount points, and swap devices share a subset
+ of configuration options for resource control of spawned processes. Internally, this relies on the Linux Control
+ Groups (cgroups) kernel concept for organizing processes in a hierarchical tree of named groups for the purpose of
+ resource management.</para>
<para>This man page lists the configuration options shared by
those six unit types. See
[Slice], [Scope], [Service], [Socket], [Mount], or [Swap]
sections, depending on the unit type.</para>
+ <para>In addition, options which control resources available to programs
+ <emphasis>executed</emphasis> by systemd are listed in
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ Those options complement options listed here.</para>
+
<para>See the <ulink
- url="http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New
+ url="https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New
Control Group Interfaces</ulink> for an introduction on how to make
use of resource control APIs from programs.</para>
</refsect1>
<refsect1>
- <title>Automatic Dependencies</title>
+ <title>Implicit Dependencies</title>
- <para>Units with the <varname>Slice=</varname> setting set automatically acquire <varname>Requires=</varname> and
- <varname>After=</varname> dependencies on the specified slice unit.</para>
+ <para>The following dependencies are implicitly added:</para>
+
+ <itemizedlist>
+ <listitem><para>Units with the <varname>Slice=</varname> setting set automatically acquire
+ <varname>Requires=</varname> and <varname>After=</varname> dependencies on the specified
+ slice unit.</para></listitem>
+ </itemizedlist>
</refsect1>
+ <!-- We don't have any default dependency here. -->
+
<refsect1>
<title>Unified and Legacy Control Group Hierarchies</title>
<varlistentry>
<term><option>CPU</option></term>
<listitem>
- <para>Due to the lack of consensus in the kernel community, the CPU controller support on the unified
- cgroup hierarchy requires out-of-tree kernel patches. See <ulink
- url="https://git.kernel.org/cgit/linux/kernel/git/tj/cgroup.git/tree/Documentation/cgroup-v2-cpu.txt?h=cgroup-v2-cpu">cgroup-v2-cpu.txt</ulink>.</para>
-
<para><varname>CPUWeight=</varname> and <varname>StartupCPUWeight=</varname> replace
<varname>CPUShares=</varname> and <varname>StartupCPUShares=</varname>, respectively.</para>
<varlistentry>
<term><option>IO</option></term>
<listitem>
- <para><varname>IO</varname> prefixed settings are superset of and replace <varname>BlockIO</varname>
+ <para><varname>IO</varname> prefixed settings are a superset of and replace <varname>BlockIO</varname>
prefixed ones. On unified hierarchy, IO resource control also applies to buffered writes.</para>
</listitem>
</varlistentry>
</variablelist>
</para>
- <para>To ease the transition, there is best-effort translation between the two versions of settings. If all
- settings of a unit for a given resource type are for the other hierarchy type, the settings are translated and
- applied. If there are any valid settings for the hierarchy in use, all translations are disabled for the resource
- type. Mixing the two types of settings on a unit can lead to confusing results.</para>
+ <para>To ease the transition, there is best-effort translation between the two versions of settings. For each
+ controller, if any of the settings for the unified hierarchy are present, all settings for the legacy hierarchy are
+ ignored. If the resulting settings are for the other type of hierarchy, the configurations are translated before
+ application.</para>
<para>Legacy control group hierarchy (see <ulink
url="https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt">cgroups.txt</ulink>), also called cgroup-v1,
<para>Implies <literal>CPUAccounting=true</literal>.</para>
- <para>These settings are supported only if the unified control group hierarchy is used.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><varname>CPUShares=<replaceable>weight</replaceable></varname></term>
- <term><varname>StartupCPUShares=<replaceable>weight</replaceable></varname></term>
-
- <listitem>
- <para>Assign the specified CPU time share weight to the processes executed. These options take an integer
- value and control the <literal>cpu.shares</literal> control group attribute. The allowed range is 2 to
- 262144. Defaults to 1024. For details about this control group attribute, see <ulink
- url="https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt">sched-design-CFS.txt</ulink>.
- The available CPU time is split up among all units within one slice relative to their CPU time share
- weight.</para>
-
- <para>While <varname>StartupCPUShares=</varname> only applies to the startup phase of the system,
- <varname>CPUShares=</varname> applies to normal runtime of the system, and if the former is not set also to
- the startup phase. Using <varname>StartupCPUShares=</varname> allows prioritizing specific services at
- boot-up differently than during normal runtime.</para>
-
- <para>Implies <literal>CPUAccounting=true</literal>.</para>
-
- <para>These settings are supported only if the legacy control group hierarchy is used.</para>
+ <para>These settings replace <varname>CPUShares=</varname> and <varname>StartupCPUShares=</varname>.</para>
</listitem>
</varlistentry>
20% CPU time on one CPU.</para>
<para>Implies <literal>CPUAccounting=true</literal>.</para>
-
- <para>This setting is supported on both unified and legacy control group hierarchies.</para>
</listitem>
</varlistentry>
<para>Implies <literal>MemoryAccounting=true</literal>.</para>
- <para>This setting is supported only if the unified control group hierarchy is used.</para>
+ <para>This setting is supported only if the unified control group hierarchy is used and disables
+ <varname>MemoryLimit=</varname>.</para>
</listitem>
</varlistentry>
<para>Implies <literal>MemoryAccounting=true</literal>.</para>
- <para>This setting is supported only if the unified control group hierarchy is used.</para>
+ <para>This setting is supported only if the unified control group hierarchy is used and disables
+ <varname>MemoryLimit=</varname>.</para>
</listitem>
</varlistentry>
<para>Implies <literal>MemoryAccounting=true</literal>.</para>
- <para>This setting is supported only if the unified control group hierarchy is used. Use
- <varname>MemoryLimit=</varname> on systems using the legacy control group hierarchy.</para>
+ <para>This setting replaces <varname>MemoryLimit=</varname>.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><varname>MemoryLimit=<replaceable>bytes</replaceable></varname></term>
+ <term><varname>MemorySwapMax=<replaceable>bytes</replaceable></varname></term>
<listitem>
- <para>Specify the limit on maximum memory usage of the executed processes. The limit specifies how much
- process and kernel memory can be used by tasks in this unit. Takes a memory size in bytes. If the value is
- suffixed with K, M, G or T, the specified memory size is parsed as Kilobytes, Megabytes, Gigabytes, or
- Terabytes (with the base 1024), respectively. Alternatively, a percentage value may be specified, which is
- taken relative to the installed physical memory on the system. If assigned the special value
- <literal>infinity</literal>, no memory limit is applied. This controls the
- <literal>memory.limit_in_bytes</literal> control group attribute. For details about this control group
- attribute, see <ulink
- url="https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt">memory.txt</ulink>.</para>
+ <para>Specify the absolute limit on swap usage of the executed processes in this unit.</para>
+
+ <para>Takes a swap size in bytes. If the value is suffixed with K, M, G or T, the specified swap size is
+ parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. If assigned the
+ special value <literal>infinity</literal>, no swap limit is applied. This controls the
+ <literal>memory.swap.max</literal> control group attribute. For details about this control group attribute,
+ see <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>.</para>
<para>Implies <literal>MemoryAccounting=true</literal>.</para>
- <para>This setting is supported only if the legacy control group hierarchy is used. Use
- <varname>MemoryMax=</varname> on systems using the unified control group hierarchy.</para>
+ <para>This setting is supported only if the unified control group hierarchy is used and disables
+ <varname>MemoryLimit=</varname>.</para>
</listitem>
</varlistentry>
in
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
- <para>This setting is supported only if the unified control group hierarchy is used. Use
- <varname>BlockIOAccounting=</varname> on systems using the legacy control group hierarchy.</para>
+ <para>This setting replaces <varname>BlockIOAccounting=</varname> and disables settings prefixed with
+ <varname>BlockIO</varname> or <varname>StartupBlockIO</varname>.</para>
</listitem>
</varlistentry>
<para>Implies <literal>IOAccounting=true</literal>.</para>
- <para>This setting is supported only if the unified control group hierarchy is used. Use
- <varname>BlockIOWeight=</varname> and <varname>StartupBlockIOWeight=</varname> on systems using the legacy
- control group hierarchy.</para>
+ <para>These settings replace <varname>BlockIOWeight=</varname> and <varname>StartupBlockIOWeight=</varname>
+ and disable settings prefixed with <varname>BlockIO</varname> or <varname>StartupBlockIO</varname>.</para>
</listitem>
</varlistentry>
<para>Implies <literal>IOAccounting=true</literal>.</para>
- <para>This setting is supported only if the unified control group hierarchy is used. Use
- <varname>BlockIODeviceWeight=</varname> on systems using the legacy control group hierarchy.</para>
+ <para>This setting replaces <varname>BlockIODeviceWeight=</varname> and disables settings prefixed with
+ <varname>BlockIO</varname> or <varname>StartupBlockIO</varname>.</para>
</listitem>
</varlistentry>
<para>Implies <literal>IOAccounting=true</literal>.</para>
- <para>This setting is supported only if the unified control group hierarchy is used. Use
- <varname>BlockIOAccounting=</varname> on systems using the legacy control group hierarchy.</para>
+ <para>These settings replace <varname>BlockIOReadBandwidth=</varname> and
+ <varname>BlockIOWriteBandwidth=</varname> and disable settings prefixed with <varname>BlockIO</varname> or
+ <varname>StartupBlockIO</varname>.</para>
</listitem>
</varlistentry>
<para>Implies <literal>IOAccounting=true</literal>.</para>
- <para>This setting is supported only if the unified control group hierarchy is used.</para>
+ <para>These settings are supported only if the unified control group hierarchy is used and disable settings
+ prefixed with <varname>BlockIO</varname> or <varname>StartupBlockIO</varname>.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><varname>BlockIOAccounting=</varname></term>
+ <term><varname>IPAccounting=</varname></term>
<listitem>
- <para>Turn on Block I/O accounting for this unit, if the legacy control group hierarchy is used on the
- system. Takes a boolean argument. Note that turning on block I/O accounting for one unit will also implicitly
- turn it on for all units contained in the same slice and all for its parent slices and the units contained
- therein. The system default for this setting may be controlled with
- <varname>DefaultBlockIOAccounting=</varname> in
+ <para>Takes a boolean argument. If true, turns on IPv4 and IPv6 network traffic accounting for packets sent
+ or received by the unit. When this option is turned on, all IPv4 and IPv6 sockets created by any process of
+ the unit are accounted for. When this option is used in socket units, it applies to all IPv4 and IPv6 sockets
+ associated with it (including both listening and connection sockets where this applies). Note that for
+ socket-activated services, this configuration setting and the accounting data of the service unit and the
+ socket unit are kept separate, and displayed separately. No propagation of the setting and the collected
+ statistics is done, in either direction. Moreover, any traffic sent or received on any of the socket unit's
+ sockets is accounted to the socket unit — and never to the service unit it might have activated, even if the
+ socket is used by it. Note that IP accounting is currently not supported for slice units, and enabling this
+ option for them has no effect. The system default for this setting may be controlled with
+ <varname>DefaultIPAccounting=</varname> in
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
-
- <para>This setting is supported only if the legacy control group hierarchy is used. Use
- <varname>IOAccounting=</varname> on systems using the unified control group hierarchy.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><varname>BlockIOWeight=<replaceable>weight</replaceable></varname></term>
- <term><varname>StartupBlockIOWeight=<replaceable>weight</replaceable></varname></term>
-
- <listitem><para>Set the default overall block I/O weight for the executed processes, if the legacy control
- group hierarchy is used on the system. Takes a single weight value (between 10 and 1000) to set the default
- block I/O weight. This controls the <literal>blkio.weight</literal> control group attribute, which defaults to
- 500. For details about this control group attribute, see <ulink
- url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>.
- The available I/O bandwidth is split up among all units within one slice relative to their block I/O
- weight.</para>
-
- <para>While <varname>StartupBlockIOWeight=</varname> only
- applies to the startup phase of the system,
- <varname>BlockIOWeight=</varname> applies to the later runtime
- of the system, and if the former is not set also to the
- startup phase. This allows prioritizing specific services at
- boot-up differently than during runtime.</para>
-
- <para>Implies
- <literal>BlockIOAccounting=true</literal>.</para>
-
- <para>This setting is supported only if the legacy control group hierarchy is used. Use
- <varname>IOWeight=</varname> and <varname>StartupIOWeight=</varname> on systems using the unified control group
- hierarchy.</para>
-
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><varname>BlockIODeviceWeight=<replaceable>device</replaceable> <replaceable>weight</replaceable></varname></term>
-
- <listitem>
- <para>Set the per-device overall block I/O weight for the executed processes, if the legacy control group
- hierarchy is used on the system. Takes a space-separated pair of a file path and a weight value to specify
- the device specific weight value, between 10 and 1000. (Example: "/dev/sda 500"). The file path may be
- specified as path to a block device node or as any other file, in which case the backing block device of the
- file system of the file is determined. This controls the <literal>blkio.weight_device</literal> control group
- attribute, which defaults to 1000. Use this option multiple times to set weights for multiple devices. For
- details about this control group attribute, see <ulink
- url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>.</para>
-
- <para>Implies
- <literal>BlockIOAccounting=true</literal>.</para>
-
- <para>This setting is supported only if the legacy control group hierarchy is used. Use
- <varname>IODeviceWeight=</varname> on systems using the unified control group hierarchy.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><varname>BlockIOReadBandwidth=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term>
- <term><varname>BlockIOWriteBandwidth=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term>
+ <term><varname>IPAddressAllow=<replaceable>ADDRESS[/PREFIXLENGTH]…</replaceable></varname></term>
+ <term><varname>IPAddressDeny=<replaceable>ADDRESS[/PREFIXLENGTH]…</replaceable></varname></term>
<listitem>
- <para>Set the per-device overall block I/O bandwidth limit for the executed processes, if the legacy control
- group hierarchy is used on the system. Takes a space-separated pair of a file path and a bandwidth value (in
- bytes per second) to specify the device specific bandwidth. The file path may be a path to a block device
- node, or as any other file in which case the backing block device of the file system of the file is used. If
- the bandwidth is suffixed with K, M, G, or T, the specified bandwidth is parsed as Kilobytes, Megabytes,
- Gigabytes, or Terabytes, respectively, to the base of 1000. (Example:
- "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This controls the
- <literal>blkio.throttle.read_bps_device</literal> and <literal>blkio.throttle.write_bps_device</literal>
- control group attributes. Use this option multiple times to set bandwidth limits for multiple devices. For
- details about these control group attributes, see <ulink
- url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>.
+ <para>Turn on address range network traffic filtering for packets sent and received over AF_INET and AF_INET6
+ sockets. Both directives take a space separated list of IPv4 or IPv6 addresses, each optionally suffixed
+ with an address prefix length (separated by a <literal>/</literal> character). If the latter is omitted, the
+ address is considered a host address, i.e. the prefix covers the whole address (32 for IPv4, 128 for IPv6).
</para>
- <para>Implies
- <literal>BlockIOAccounting=true</literal>.</para>
-
- <para>This setting is supported only if the legacy control group hierarchy is used. Use
- <varname>IOReadBandwidthMax=</varname> and <varname>IOWriteBandwidthMax=</varname> on systems using the
- unified control group hierarchy.</para>
+ <para>The access lists configured with this option are applied to all sockets created by processes of this
+ unit (or in the case of socket units, associated with it). The lists are implicitly combined with any lists
+ configured for any of the parent slice units this unit might be a member of. By default all access lists are
+ empty. When configured the lists are enforced as follows:</para>
+
+ <itemizedlist>
+ <listitem><para>Access will be granted in case its destination/source address matches any entry in the
+ <varname>IPAddressAllow=</varname> setting.</para></listitem>
+
+ <listitem><para>Otherwise, access will be denied in case its destination/source address matches any entry
+ in the <varname>IPAddressDeny=</varname> setting.</para></listitem>
+
+ <listitem><para>Otherwise, access will be granted.</para></listitem>
+ </itemizedlist>
+
+ <para>In order to implement a whitelisting IP firewall, it is recommended to use a
+ <varname>IPAddressDeny=</varname><constant>any</constant> setting on an upper-level slice unit (such as the
+ root slice <filename>-.slice</filename> or the slice containing all system services
+ <filename>system.slice</filename> – see
+ <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+ details on these slice units), plus individual per-service <varname>IPAddressAllow=</varname> lines
+ permitting network access to relevant services, and only them.</para>
+
+ <para>Note that for socket-activated services, the IP access list configured on the socket unit applies to
+ all sockets associated with it directly, but not to any sockets created by the ultimately activated services
+ for it. Conversely, the IP access list configured for the service is not applied to any sockets passed into
+ the service via socket activation. Thus, it is usually a good idea, to replicate the IP access lists on both
+ the socket and the service unit, however it often makes sense to maintain one list more open and the other
+ one more restricted, depending on the usecase.</para>
+
+ <para>If these settings are used multiple times in the same unit the specified lists are combined. If an
+ empty string is assigned to these settings the specific access list is reset and all previous settings undone.</para>
+
+ <para>In place of explicit IPv4 or IPv6 address and prefix length specifications a small set of symbolic
+ names may be used. The following names are defined:</para>
+
+ <table>
+ <title>Special address/network names</title>
+
+ <tgroup cols='3'>
+ <colspec colname='name'/>
+ <colspec colname='definition'/>
+ <colspec colname='meaning'/>
+
+ <thead>
+ <row>
+ <entry>Symbolic Name</entry>
+ <entry>Definition</entry>
+ <entry>Meaning</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry><constant>any</constant></entry>
+ <entry>0.0.0.0/0 ::/0</entry>
+ <entry>Any host</entry>
+ </row>
+
+ <row>
+ <entry><constant>localhost</constant></entry>
+ <entry>127.0.0.0/8 ::1/128</entry>
+ <entry>All addresses on the local loopback</entry>
+ </row>
+
+ <row>
+ <entry><constant>link-local</constant></entry>
+ <entry>169.254.0.0/16 fe80::/64</entry>
+ <entry>All link-local IP addresses</entry>
+ </row>
+
+ <row>
+ <entry><constant>multicast</constant></entry>
+ <entry>224.0.0.0/4 ff00::/8</entry>
+ <entry>All IP multicasting addresses</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>Note that these settings might not be supported on some systems (for example if eBPF control group
+ support is not enabled in the underlying kernel or container manager). These settings will have no effect in
+ that case. If compatibility with such systems is desired it is hence recommended to not exclusively rely on
+ them for IP security.</para>
</listitem>
</varlistentry>
<filename>/proc/devices</filename>. The latter is useful to
whitelist all current and future devices belonging to a
specific device group at once. The device group is matched
- according to file name globbing rules, you may hence use the
+ according to filename globbing rules, you may hence use the
<literal>*</literal> and <literal>?</literal>
wildcards. Examples: <filename>/dev/sda5</filename> is a
path to a device node, referring to an ATA or SCSI block
<para>Special care should be taken when relying on the default slice assignment in templated service units
that have <varname>DefaultDependencies=no</varname> set, see
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, section
- "Automatic Dependencies" for details.</para>
+ "Default Dependencies" for details.</para>
</listitem>
</varlistentry>
<term><varname>Delegate=</varname></term>
<listitem>
- <para>Turns on delegation of further resource control
- partitioning to processes of the unit. For unprivileged
- services (i.e. those using the <varname>User=</varname>
- setting), this allows processes to create a subhierarchy
- beneath its control group path. For privileged services and
- scopes, this ensures the processes will have all control
- group controllers enabled.</para>
+ <para>Turns on delegation of further resource control partitioning to processes of the unit. Units where this
+ is enabled may create and manage their own private subhierarchy of control groups below the control group of
+ the unit itself. For unprivileged services (i.e. those using the <varname>User=</varname> setting) the unit's
+ control group will be made accessible to the relevant user. When enabled the service manager will refrain
+ from manipulating control groups or moving processes below the unit's control group, so that a clear concept
+ of ownership is established: the control group tree above the unit's control group (i.e. towards the root
+ control group) is owned and managed by the service manager of the host, while the control group tree below
+ the unit's control group is owned and managed by the unit itself. Takes either a boolean argument or a list
+ of control group controller names. If true, delegation is turned on, and all supported controllers are
+ enabled for the unit, making them available to the unit's processes for management. If false, delegation is
+ turned off entirely (and no additional controllers are enabled). If set to a list of controllers, delegation
+ is turned on, and the specified controllers are enabled for the unit. Note that additional controllers than
+ the ones specified might be made available as well, depending on configuration of the containing slice unit
+ or other units contained in it. Note that assigning the empty string will enable delegation, but reset the
+ list of controllers, all assignments prior to this will have no effect. Defaults to false.</para>
+
+ <para>Note that controller delegation to less privileged code is only safe on the unified control group
+ hierarchy. Accordingly, access to the specified controllers will not be granted to unprivileged services on
+ the legacy hierarchy, even when requested.</para>
+
+ <para>The following controller names may be specified: <option>cpu</option>, <option>cpuacct</option>,
+ <option>io</option>, <option>blkio</option>, <option>memory</option>, <option>devices</option>,
+ <option>pids</option>. Not all of these controllers are available on all kernels however, and some are
+ specific to the unified hierarchy while others are specific to the legacy hierarchy. Also note that the
+ kernel might support further controllers, which aren't covered here yet as delegation is either not supported
+ at all for them or not defined cleanly.</para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+ </refsect1>
+
+ <refsect1>
+ <title>Deprecated Options</title>
+
+ <para>The following options are deprecated. Use the indicated superseding options instead:</para>
+
+ <variablelist class='unit-directives'>
+
+ <varlistentry>
+ <term><varname>CPUShares=<replaceable>weight</replaceable></varname></term>
+ <term><varname>StartupCPUShares=<replaceable>weight</replaceable></varname></term>
+
+ <listitem>
+ <para>Assign the specified CPU time share weight to the processes executed. These options take an integer
+ value and control the <literal>cpu.shares</literal> control group attribute. The allowed range is 2 to
+ 262144. Defaults to 1024. For details about this control group attribute, see <ulink
+ url="https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt">sched-design-CFS.txt</ulink>.
+ The available CPU time is split up among all units within one slice relative to their CPU time share
+ weight.</para>
+
+ <para>While <varname>StartupCPUShares=</varname> only applies to the startup phase of the system,
+ <varname>CPUShares=</varname> applies to normal runtime of the system, and if the former is not set also to
+ the startup phase. Using <varname>StartupCPUShares=</varname> allows prioritizing specific services at
+ boot-up differently than during normal runtime.</para>
+
+ <para>Implies <literal>CPUAccounting=true</literal>.</para>
+
+ <para>These settings are deprecated. Use <varname>CPUWeight=</varname> and
+ <varname>StartupCPUWeight=</varname> instead.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>MemoryLimit=<replaceable>bytes</replaceable></varname></term>
+
+ <listitem>
+ <para>Specify the limit on maximum memory usage of the executed processes. The limit specifies how much
+ process and kernel memory can be used by tasks in this unit. Takes a memory size in bytes. If the value is
+ suffixed with K, M, G or T, the specified memory size is parsed as Kilobytes, Megabytes, Gigabytes, or
+ Terabytes (with the base 1024), respectively. Alternatively, a percentage value may be specified, which is
+ taken relative to the installed physical memory on the system. If assigned the special value
+ <literal>infinity</literal>, no memory limit is applied. This controls the
+ <literal>memory.limit_in_bytes</literal> control group attribute. For details about this control group
+ attribute, see <ulink
+ url="https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt">memory.txt</ulink>.</para>
+
+ <para>Implies <literal>MemoryAccounting=true</literal>.</para>
+
+ <para>This setting is deprecated. Use <varname>MemoryMax=</varname> instead.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>BlockIOAccounting=</varname></term>
+
+ <listitem>
+ <para>Turn on Block I/O accounting for this unit, if the legacy control group hierarchy is used on the
+ system. Takes a boolean argument. Note that turning on block I/O accounting for one unit will also implicitly
+ turn it on for all units contained in the same slice and all for its parent slices and the units contained
+ therein. The system default for this setting may be controlled with
+ <varname>DefaultBlockIOAccounting=</varname> in
+ <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+ <para>This setting is deprecated. Use <varname>IOAccounting=</varname> instead.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>BlockIOWeight=<replaceable>weight</replaceable></varname></term>
+ <term><varname>StartupBlockIOWeight=<replaceable>weight</replaceable></varname></term>
+
+ <listitem><para>Set the default overall block I/O weight for the executed processes, if the legacy control
+ group hierarchy is used on the system. Takes a single weight value (between 10 and 1000) to set the default
+ block I/O weight. This controls the <literal>blkio.weight</literal> control group attribute, which defaults to
+ 500. For details about this control group attribute, see <ulink
+ url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>.
+ The available I/O bandwidth is split up among all units within one slice relative to their block I/O
+ weight.</para>
+
+ <para>While <varname>StartupBlockIOWeight=</varname> only
+ applies to the startup phase of the system,
+ <varname>BlockIOWeight=</varname> applies to the later runtime
+ of the system, and if the former is not set also to the
+ startup phase. This allows prioritizing specific services at
+ boot-up differently than during runtime.</para>
+
+ <para>Implies
+ <literal>BlockIOAccounting=true</literal>.</para>
+
+ <para>These settings are deprecated. Use <varname>IOWeight=</varname> and <varname>StartupIOWeight=</varname>
+ instead.</para>
+
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>BlockIODeviceWeight=<replaceable>device</replaceable> <replaceable>weight</replaceable></varname></term>
+
+ <listitem>
+ <para>Set the per-device overall block I/O weight for the executed processes, if the legacy control group
+ hierarchy is used on the system. Takes a space-separated pair of a file path and a weight value to specify
+ the device specific weight value, between 10 and 1000. (Example: "/dev/sda 500"). The file path may be
+ specified as path to a block device node or as any other file, in which case the backing block device of the
+ file system of the file is determined. This controls the <literal>blkio.weight_device</literal> control group
+ attribute, which defaults to 1000. Use this option multiple times to set weights for multiple devices. For
+ details about this control group attribute, see <ulink
+ url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>.</para>
+
+ <para>Implies
+ <literal>BlockIOAccounting=true</literal>.</para>
+
+ <para>This setting is deprecated. Use <varname>IODeviceWeight=</varname> instead.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>BlockIOReadBandwidth=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term>
+ <term><varname>BlockIOWriteBandwidth=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term>
+
+ <listitem>
+ <para>Set the per-device overall block I/O bandwidth limit for the executed processes, if the legacy control
+ group hierarchy is used on the system. Takes a space-separated pair of a file path and a bandwidth value (in
+ bytes per second) to specify the device specific bandwidth. The file path may be a path to a block device
+ node, or as any other file in which case the backing block device of the file system of the file is used. If
+ the bandwidth is suffixed with K, M, G, or T, the specified bandwidth is parsed as Kilobytes, Megabytes,
+ Gigabytes, or Terabytes, respectively, to the base of 1000. (Example:
+ "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This controls the
+ <literal>blkio.throttle.read_bps_device</literal> and <literal>blkio.throttle.write_bps_device</literal>
+ control group attributes. Use this option multiple times to set bandwidth limits for multiple devices. For
+ details about these control group attributes, see <ulink
+ url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>.
+ </para>
+
+ <para>Implies
+ <literal>BlockIOAccounting=true</literal>.</para>
+
+ <para>These settings are deprecated. Use <varname>IOReadBandwidthMax=</varname> and
+ <varname>IOWriteBandwidthMax=</varname> instead.</para>
</listitem>
</varlistentry>
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
The documentation for control groups and specific controllers in the Linux kernel:
projects / thirdparty / systemd.git / blobdiff