Ubuntu Manpage: Config::Model::models::Systemd::Section::Service - Configuration class Systemd::Section::Service

Provided by: libconfig-model-systemd-perl_0.256.1-1_all

NAME

       Config::Model::models::Systemd::Section::Service - Configuration class Systemd::Section::Service

DESCRIPTION

       Configuration classes used by Config::Model

       A unit configuration file whose name ends in ".service" encodes information about a process controlled
       and supervised by systemd.

       This man page lists the configuration options specific to this unit type. See systemd.unit(5) for the
       common options of all unit configuration files. The common configuration items are configured in the
       generic [Unit] and [Install] sections. The service specific configuration options are configured in the
       [Service] section.

       Additional options are listed in systemd.exec(5), which define the execution environment the commands are
       executed in, and in systemd.kill(5), which define the way the processes of the service are terminated,
       and in systemd.resource-control(5), which configure resource control settings for the processes of the
       service.

       If SysV init compat is enabled, systemd automatically creates service units that wrap SysV init scripts
       (the service name is the same as the name of the script, with a ".service" suffix added); see
       systemd-sysv-generator(8).

       The systemd-run(1) command allows creating ".service" and ".scope" units dynamically and transiently from
       the command line.  This configuration class was generated from systemd documentation.  by parse-man.pl
       <https://github.com/dod38fr/config-model-systemd/contrib/parse-man.pl>

Elements

CPUAccounting
Turn on CPU usage accounting for this unit. Takes a boolean argument. Note that turning on CPU accounting
for one unit will also implicitly turn it on for all units contained in the same slice and for all its
parent slices and the units contained therein. The system default for this setting may be controlled with
"DefaultCPUAccounting" in systemd-system.conf(5).

Under the unified cgroup hierarchy, CPU accounting is available for all units and this setting has no
effect. Optional. Type boolean.

CPUWeight
These settings control the "cpu" controller in the unified hierarchy.

These options accept an integer value or a the special string "idle":

While "StartupCPUWeight" applies to the startup and shutdown phases of the system, "CPUWeight" applies to
normal runtime of the system, and if the former is not set also to the startup and shutdown phases. Using
"StartupCPUWeight" allows prioritizing specific services at boot-up and shutdown differently than during
normal runtime.

In addition to the resource allocation performed by the "cpu" controller, the kernel may automatically
divide resources based on session-id grouping, see "The autogroup feature" in sched(7). The effect of
this feature is similar to the "cpu" controller with no explicit configuration, so users should be
careful to not mistake one for the other. Optional. Type uniline.

StartupCPUWeight
These settings control the "cpu" controller in the unified hierarchy.

These options accept an integer value or a the special string "idle":

CPUQuota
This setting controls the "cpu" controller in the unified hierarchy.

Assign the specified CPU time quota to the processes executed. Takes a percentage value, suffixed with
"%". The percentage specifies how much CPU time the unit shall get at maximum, relative to the total CPU
time available on one CPU. Use values > 100% for allotting CPU time on more than one CPU. This controls
the "cpu.max" attribute on the unified control group hierarchy and "cpu.cfs_quota_us" on legacy. For
details about these control group attributes, see Control Groups v2 <https://docs.kernel.org/admin-
guide/cgroup-v2.html> and CFS Bandwidth Control <https://docs.kernel.org/scheduler/sched-bwc.html>.
Setting "CPUQuota" to an empty value unsets the quota.

Example: "CPUQuota=20%" ensures that the executed processes will never get more than 20% CPU time on one
CPU. Optional. Type uniline.

CPUQuotaPeriodSec
This setting controls the "cpu" controller in the unified hierarchy.

Assign the duration over which the CPU time quota specified by "CPUQuota" is measured. Takes a time
duration value in seconds, with an optional suffix such as "ms" for milliseconds (or "s" for seconds.)
The default setting is 100ms. The period is clamped to the range supported by the kernel, which is [1ms,
1000ms]. Additionally, the period is adjusted up so that the quota interval is also at least 1ms.
Setting "CPUQuotaPeriodSec" to an empty value resets it to the default.

This controls the second field of "cpu.max" attribute on the unified control group hierarchy and
"cpu.cfs_period_us" on legacy. For details about these control group attributes, see Control Groups v2
<https://docs.kernel.org/admin-guide/cgroup-v2.html> and CFS Scheduler
<https://docs.kernel.org/scheduler/sched-design-CFS.html>.

Example: "CPUQuotaPeriodSec=10ms" to request that the CPU quota is measured in periods of 10ms.
Optional. Type uniline.

AllowedCPUs
This setting controls the "cpuset" controller in the unified hierarchy.

Restrict processes to be executed on specific CPUs. Takes a list of CPU indices or ranges separated by
either whitespace or commas. CPU ranges are specified by the lower and upper CPU indices separated by a
dash.

Setting "AllowedCPUs" or "StartupAllowedCPUs" doesn't guarantee that all of the CPUs will be used by the
processes as it may be limited by parent units. The effective configuration is reported as
"EffectiveCPUs".

While "StartupAllowedCPUs" applies to the startup and shutdown phases of the system, "AllowedCPUs"
applies to normal runtime of the system, and if the former is not set also to the startup and shutdown
phases. Using "StartupAllowedCPUs" allows prioritizing specific services at boot-up and shutdown
differently than during normal runtime.

This setting is supported only with the unified control group hierarchy. Optional. Type uniline.

StartupAllowedCPUs
This setting controls the "cpuset" controller in the unified hierarchy.

This setting is supported only with the unified control group hierarchy. Optional. Type uniline.

MemoryAccounting
This setting controls the "memory" controller in the unified hierarchy.

Turn on process and kernel memory accounting for this unit. Takes a boolean argument. Note that turning
on memory accounting for one unit will also implicitly turn it on for all units contained in the same
slice and for all its parent slices and the units contained therein. The system default for this setting
may be controlled with "DefaultMemoryAccounting" in systemd-system.conf(5). Optional. Type boolean.

MemoryMin
These settings control the "memory" controller in the unified hierarchy.

Specify the memory usage protection of the executed processes in this unit. When reclaiming memory, the
unit is treated as if it was using less memory resulting in memory to be preferentially reclaimed from
unprotected units. Using "MemoryLow" results in a weaker protection where memory may still be reclaimed
to avoid invoking the OOM killer in case there is no other reclaimable memory.

For a protection to be effective, it is generally required to set a corresponding allocation on all
ancestors, which is then distributed between children (with the exception of the root slice). Any
"MemoryMin" or "MemoryLow" allocation that is not explicitly distributed to specific children is used to
create a shared protection for all children. As this is a shared protection, the children will freely
compete for the memory.

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 "infinity", all available memory is protected, which
may be useful in order to always inherit all of the protection afforded by ancestors. This controls the
"memory.min" or "memory.low" control group attribute. For details about this control group attribute,
see Memory Interface Files <https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files>.

Units may have their children use a default "memory.min" or "memory.low" value by specifying
"DefaultMemoryMin" or "DefaultMemoryLow", which has the same semantics as "MemoryMin" and "MemoryLow", or
"DefaultStartupMemoryLow" which has the same semantics as "StartupMemoryLow". This setting does not
affect "memory.min" or "memory.low" in the unit itself. Using it to set a default child allocation is
only useful on kernels older than 5.7, which do not support the "memory_recursiveprot" cgroup2 mount
option.

While "StartupMemoryLow" applies to the startup and shutdown phases of the system, "MemoryMin" applies to
normal runtime of the system, and if the former is not set also to the startup and shutdown phases. Using
"StartupMemoryLow" allows prioritizing specific services at boot-up and shutdown differently than during
normal runtime. Optional. Type uniline.

StartupMemoryLow
These settings control the "memory" controller in the unified hierarchy.

MemoryHigh
These settings control the "memory" controller in the unified hierarchy.

Specify the throttling limit on memory usage of the executed processes in this unit. Memory usage may go
above the limit if unavoidable, but the processes are heavily slowed down and memory is taken away
aggressively in such cases. This is the main mechanism to control memory usage of a 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 "infinity", no memory throttling is applied. This
controls the "memory.high" control group attribute. For details about this control group attribute, see
Memory Interface Files <https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files>. The
effective configuration is reported as "EffectiveMemoryHigh" (see also "EffectiveMemoryMax").

While "StartupMemoryHigh" applies to the startup and shutdown phases of the system, "MemoryHigh" applies
to normal runtime of the system, and if the former is not set also to the startup and shutdown phases.
Using "StartupMemoryHigh" allows prioritizing specific services at boot-up and shutdown differently than
during normal runtime. Optional. Type uniline.

StartupMemoryHigh
These settings control the "memory" controller in the unified hierarchy.

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 "infinity", no memory throttling is applied. This
controls the "memory.high" control group attribute. For details about this control group attribute, see
Memory Interface Files <https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files>. The
effective configuration is reported as "EffectiveMemoryHigh" (see also "EffectiveMemoryMax").

MemoryMax
These settings control the "memory" controller in the unified hierarchy.

Specify the absolute limit on memory usage of the executed processes in this unit. If memory usage cannot
be contained under the limit, out-of-memory killer is invoked inside the unit. It is recommended to use
"MemoryHigh" as the main control mechanism and use "MemoryMax" as the last line of defense.

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 "infinity", no memory limit is applied. This controls
the "memory.max" control group attribute. For details about this control group attribute, see Memory
Interface Files <https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files>. The
effective configuration is reported as "EffectiveMemoryMax" (the value is the most stringent limit of the
unit and parent slices and it is capped by physical memory).

While "StartupMemoryMax" applies to the startup and shutdown phases of the system, "MemoryMax" applies to
normal runtime of the system, and if the former is not set also to the startup and shutdown phases. Using
"StartupMemoryMax" allows prioritizing specific services at boot-up and shutdown differently than during
normal runtime. Optional. Type uniline.

StartupMemoryMax
These settings control the "memory" controller in the unified hierarchy.

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 "infinity", no memory limit is applied. This controls
the "memory.max" control group attribute. For details about this control group attribute, see Memory
Interface Files <https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files>. The
effective configuration is reported as "EffectiveMemoryMax" (the value is the most stringent limit of the
unit and parent slices and it is capped by physical memory).

MemorySwapMax
These settings control the "memory" controller in the unified hierarchy.

Specify the absolute limit on swap usage of the executed processes in this unit.

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. Alternatively, a
percentage value may be specified, which is taken relative to the specified swap size on the system. If
assigned the special value "infinity", no swap limit is applied. These settings control the
"memory.swap.max" control group attribute. For details about this control group attribute, see Memory
Interface Files <https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files>.

While "StartupMemorySwapMax" applies to the startup and shutdown phases of the system, "MemorySwapMax"
applies to normal runtime of the system, and if the former is not set also to the startup and shutdown
phases. Using "StartupMemorySwapMax" allows prioritizing specific services at boot-up and shutdown
differently than during normal runtime. Optional. Type uniline.

StartupMemorySwapMax
These settings control the "memory" controller in the unified hierarchy.

Specify the absolute limit on swap usage of the executed processes in this unit.

MemoryZSwapMax
These settings control the "memory" controller in the unified hierarchy.

Specify the absolute limit on zswap usage of the processes in this unit. Zswap is a lightweight
compressed cache for swap pages. It takes pages that are in the process of being swapped out and attempts
to compress them into a dynamically allocated RAM-based memory pool. If the limit specified is hit, no
entries from this unit will be stored in the pool until existing entries are faulted back or written out
to disk. See the kernel's Zswap <https://docs.kernel.org/admin-guide/mm/zswap.html> documentation for
more details.

Takes a size in bytes. If the value is suffixed with K, M, G or T, the specified size is parsed as
Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. If assigned the special
value "infinity", no limit is applied. These settings control the "memory.zswap.max" control group
attribute. For details about this control group attribute, see Memory Interface Files
<https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files>.

While "StartupMemoryZSwapMax" applies to the startup and shutdown phases of the system, "MemoryZSwapMax"
applies to normal runtime of the system, and if the former is not set also to the startup and shutdown
phases. Using "StartupMemoryZSwapMax" allows prioritizing specific services at boot-up and shutdown
differently than during normal runtime. Optional. Type uniline.

StartupMemoryZSwapMax
These settings control the "memory" controller in the unified hierarchy.

MemoryZSwapWriteback
This setting controls the "memory" controller in the unified hierarchy.

Takes a boolean argument. When true, pages stored in the Zswap cache are permitted to be written to the
backing storage, false otherwise. Defaults to true. This allows disabling writeback of swap pages for IO-
intensive applications, while retaining the ability to store compressed pages in Zswap. See the kernel's
Zswap <https://docs.kernel.org/admin-guide/mm/zswap.html> documentation for more details. Optional. Type
boolean.

AllowedMemoryNodes
These settings control the "cpuset" controller in the unified hierarchy.

Restrict processes to be executed on specific memory NUMA nodes. Takes a list of memory NUMA nodes
indices or ranges separated by either whitespace or commas. Memory NUMA nodes ranges are specified by the
lower and upper NUMA nodes indices separated by a dash.

Setting "AllowedMemoryNodes" or "StartupAllowedMemoryNodes" doesn't guarantee that all of the memory NUMA
nodes will be used by the processes as it may be limited by parent units. The effective configuration is
reported as "EffectiveMemoryNodes".

While "StartupAllowedMemoryNodes" applies to the startup and shutdown phases of the system,
"AllowedMemoryNodes" applies to normal runtime of the system, and if the former is not set also to the
startup and shutdown phases. Using "StartupAllowedMemoryNodes" allows prioritizing specific services at
boot-up and shutdown differently than during normal runtime.

This setting is supported only with the unified control group hierarchy. Optional. Type uniline.

StartupAllowedMemoryNodes
These settings control the "cpuset" controller in the unified hierarchy.

This setting is supported only with the unified control group hierarchy. Optional. Type uniline.

TasksAccounting
This setting controls the "pids" controller in the unified hierarchy.

Turn on task accounting for this unit. Takes a boolean argument. If enabled, the kernel will keep track
of the total number of tasks in the unit and its children. This number includes both kernel threads and
userspace processes, with each thread counted individually. Note that turning on tasks accounting for one
unit will also implicitly turn it on for all units contained in the same slice and for all its parent
slices and the units contained therein. The system default for this setting may be controlled with
"DefaultTasksAccounting" in systemd-system.conf(5). Optional. Type boolean.

TasksMax
This setting controls the "pids" controller in the unified hierarchy.

Specify the maximum number of tasks that may be created in the unit. This ensures that the number of
tasks accounted for the unit (see above) stays below a specific limit. This either takes an absolute
number of tasks or a percentage value that is taken relative to the configured maximum number of tasks on
the system. If assigned the special value "infinity", no tasks limit is applied. This controls the
"pids.max" control group attribute. For details about this control group attribute, the pids controller
<https://docs.kernel.org/admin-guide/cgroup-v2.html#pid>. The effective configuration is reported as
"EffectiveTasksMax".

The system default for this setting may be controlled with "DefaultTasksMax" in systemd-system.conf(5).
Optional. Type uniline.

IOAccounting
This setting controls the "io" controller in the unified hierarchy.

Turn on Block I/O accounting for this unit, if the unified 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 "DefaultIOAccounting" in
systemd-system.conf(5). Optional. Type boolean.

IOWeight
These settings control the "io" controller in the unified hierarchy.

Set the default overall block I/O weight for the executed processes, if the unified control group
hierarchy is used on the system. Takes a single weight value (between 1 and 10000) to set the default
block I/O weight. This controls the "io.weight" control group attribute, which defaults to 100. For
details about this control group attribute, see IO Interface Files <https://docs.kernel.org/admin-
guide/cgroup-v2.html#io-interface-files>. The available I/O bandwidth is split up among all units within
one slice relative to their block I/O weight. A higher weight means more I/O bandwidth, a lower weight
means less.

While "StartupIOWeight" applies to the startup and shutdown phases of the system, "IOWeight" applies to
the later runtime of the system, and if the former is not set also to the startup and shutdown phases.
This allows prioritizing specific services at boot-up and shutdown differently than during runtime.
Optional. Type uniline.

StartupIOWeight
These settings control the "io" controller in the unified hierarchy.

IODeviceWeight
This setting controls the "io" controller in the unified hierarchy.

Set the per-device overall block I/O weight for the executed processes, if the unified 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 1 and 10000. (Example: "/dev/sda 1000"). 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 "io.weight" control group
attribute, which defaults to 100. Use this option multiple times to set weights for multiple devices.
For details about this control group attribute, see IO Interface Files <https://docs.kernel.org/admin-
guide/cgroup-v2.html#io-interface-files>.

The specified device node should reference a block device that has an I/O scheduler associated, i.e.
should not refer to partition or loopback block devices, but to the originating, physical device. When a
path to a regular file or directory is specified it is attempted to discover the correct originating
device backing the file system of the specified path. This works correctly only for simpler cases, where
the file system is directly placed on a partition or physical block device, or where simple 1:1
encryption using dm-crypt/LUKS is used. This discovery does not cover complex storage and in particular
RAID and volume management storage devices. Optional. Type uniline.

IOReadBandwidthMax
These settings control the "io" controller in the unified hierarchy.

Set the per-device overall block I/O bandwidth maximum limit for the executed processes, if the unified
control group hierarchy is used on the system. This limit is not work-conserving and the executed
processes are not allowed to use more even if the device has idle capacity. 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 "io.max"
control group attributes. Use this option multiple times to set bandwidth limits for multiple devices.
For details about this control group attribute, see IO Interface Files <https://docs.kernel.org/admin-
guide/cgroup-v2.html#io-interface-files>.

Similar restrictions on block device discovery as for "IODeviceWeight" apply, see above. Optional. Type
uniline.

IOWriteBandwidthMax
These settings control the "io" controller in the unified hierarchy.

Similar restrictions on block device discovery as for "IODeviceWeight" apply, see above. Optional. Type
uniline.

IOReadIOPSMax
These settings control the "io" controller in the unified hierarchy.

Set the per-device overall block I/O IOs-Per-Second maximum limit for the executed processes, if the
unified control group hierarchy is used on the system. This limit is not work-conserving and the executed
processes are not allowed to use more even if the device has idle capacity. Takes a space-separated pair
of a file path and an IOPS value to specify the device specific IOPS. 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 IOPS is suffixed with K, M, G, or T, the specified IOPS is parsed as KiloIOPS,
MegaIOPS, GigaIOPS, or TeraIOPS, respectively, to the base of 1000. (Example:
"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K"). This controls the "io.max" control group
attributes. Use this option multiple times to set IOPS limits for multiple devices. For details about
this control group attribute, see IO Interface Files <https://docs.kernel.org/admin-guide/cgroup-
v2.html#io-interface-files>.

Similar restrictions on block device discovery as for "IODeviceWeight" apply, see above. Optional. Type
uniline.

IOWriteIOPSMax
These settings control the "io" controller in the unified hierarchy.

Similar restrictions on block device discovery as for "IODeviceWeight" apply, see above. Optional. Type
uniline.

IODeviceLatencyTargetSec
This setting controls the "io" controller in the unified hierarchy.

Set the per-device average target I/O latency for the executed processes, if the unified control group
hierarchy is used on the system. Takes a file path and a timespan separated by a space to specify the
device specific latency target. (Example: "/dev/sda 25ms"). 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 "io.latency" control group attribute. Use this option multiple
times to set latency target for multiple devices. For details about this control group attribute, see IO
Interface Files <https://docs.kernel.org/admin-guide/cgroup-v2.html#io-interface-files>.

Implies "IOAccounting=yes".

These settings are supported only if the unified control group hierarchy is used.

Similar restrictions on block device discovery as for "IODeviceWeight" apply, see above. Optional. Type
uniline.

IPAccounting
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.

The system default for this setting may be controlled with "DefaultIPAccounting" in
systemd-system.conf(5).

Note that this functionality is currently only available for system services, not for per-user services.
Optional. Type boolean.

IPAddressAllow
Turn on network traffic filtering for IP 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 in bits after a "/" character. If the suffix is omitted, the address is considered
a host address, i.e. the filter covers the whole address (32 bits for IPv4, 128 bits for IPv6).

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 both access lists
are empty. Both ingress and egress traffic is filtered by these settings. In case of ingress traffic the
source IP address is checked against these access lists, in case of egress traffic the destination IP
address is checked. The following rules are applied in turn:

In order to implement an allow-listing IP firewall, it is recommended to use a "IPAddressDeny""any"
setting on an upper-level slice unit (such as the root slice "-.slice" or the slice containing all system
services "system.slice" – see systemd.special(7) for details on these slice units), plus individual per-
service "IPAddressAllow" lines permitting network access to relevant services, and only them.

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. Nevertheless, it may make sense to maintain one list more open
and the other one more restricted, depending on the use case.

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.

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:

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. Optional. Type uniline.

IPAddressDeny
Turn on network traffic filtering for IP 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 in bits after a "/" character. If the suffix is omitted, the address is considered
a host address, i.e. the filter covers the whole address (32 bits for IPv4, 128 bits for IPv6).

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:

SocketBindAllow
Configures restrictions on the ability of unit processes to invoke bind(2) on a socket. Both allow and
deny rules may defined that restrict which addresses a socket may be bound to.

bind-rule describes socket properties such as address-family, transport-protocol and ip-ports.

bind-rule := { [address-family":"][transport-protocol":"][ip-ports] | "any" }

address-family := { "ipv4" | "ipv6" }

transport-protocol := { "tcp" | "udp" }

ip-ports := { ip-port | ip-port-range }

An optional address-family expects "ipv4" or "ipv6" values. If not specified, a rule will be matched for
both IPv4 and IPv6 addresses and applied depending on other socket fields, e.g. transport-protocol, ip-
port.

An optional transport-protocol expects "tcp" or "udp" transport protocol names. If not specified, a rule
will be matched for any transport protocol.

An optional ip-port value must lie within 1…65535 interval inclusively, i.e. dynamic port 0 is not
allowed. A range of sequential ports is described by ip-port-range := ip-port-low"-"ip-port-high, where
ip-port-low is smaller than or equal to ip-port-high and both are within 1…65535 inclusively.

A special value "any" can be used to apply a rule to any address family, transport protocol and any port
with a positive value.

To allow multiple rules assign "SocketBindAllow" or "SocketBindDeny" multiple times. To clear the
existing assignments pass an empty "SocketBindAllow" or "SocketBindDeny" assignment.

For each of "SocketBindAllow" and "SocketBindDeny", maximum allowed number of assignments is 128.

The feature is implemented with "cgroup/bind4" and "cgroup/bind6" cgroup-bpf hooks.

Note that these settings apply to any bind(2) system call invocation by the unit processes, regardless in
which network namespace they are placed. Or in other words: changing the network namespace is not a
suitable mechanism for escaping these restrictions on bind().

Examples:
…
# Allow binding IPv6 socket addresses with a port greater than or equal to 10000.
[Service]
SocketBindAllow=ipv6:10000-65535
SocketBindDeny=any
…
# Allow binding IPv4 and IPv6 socket addresses with 1234 and 4321 ports.
[Service]
SocketBindAllow=1234
SocketBindAllow=4321
SocketBindDeny=any
…
# Deny binding IPv6 socket addresses.
[Service]
SocketBindDeny=ipv6
…
# Deny binding IPv4 and IPv6 socket addresses.
[Service]
SocketBindDeny=any
…
# Allow binding only over TCP
[Service]
SocketBindAllow=tcp
SocketBindDeny=any
…
# Allow binding only over IPv6/TCP
[Service]
SocketBindAllow=ipv6:tcp
SocketBindDeny=any
…
# Allow binding ports within 10000-65535 range over IPv4/UDP.
[Service]
SocketBindAllow=ipv4:udp:10000-65535
SocketBindDeny=any
… Optional. Type uniline.

SocketBindDeny
Configures restrictions on the ability of unit processes to invoke bind(2) on a socket. Both allow and
deny rules may defined that restrict which addresses a socket may be bound to.

bind-rule describes socket properties such as address-family, transport-protocol and ip-ports.

bind-rule := { [address-family":"][transport-protocol":"][ip-ports] | "any" }

address-family := { "ipv4" | "ipv6" }

transport-protocol := { "tcp" | "udp" }

ip-ports := { ip-port | ip-port-range }

An optional transport-protocol expects "tcp" or "udp" transport protocol names. If not specified, a rule
will be matched for any transport protocol.

A special value "any" can be used to apply a rule to any address family, transport protocol and any port
with a positive value.

To allow multiple rules assign "SocketBindAllow" or "SocketBindDeny" multiple times. To clear the
existing assignments pass an empty "SocketBindAllow" or "SocketBindDeny" assignment.

For each of "SocketBindAllow" and "SocketBindDeny", maximum allowed number of assignments is 128.

The feature is implemented with "cgroup/bind4" and "cgroup/bind6" cgroup-bpf hooks.

RestrictNetworkInterfaces
Takes a list of space-separated network interface names. This option restricts the network interfaces
that processes of this unit can use. By default processes can only use the network interfaces listed
(allow-list). If the first character of the rule is "~", the effect is inverted: the processes can only
use network interfaces not listed (deny-list).

This option can appear multiple times, in which case the network interface names are merged. If the empty
string is assigned the set is reset, all prior assignments will have not effect.

If you specify both types of this option (i.e. allow-listing and deny-listing), the first encountered
will take precedence and will dictate the default action (allow vs deny). Then the next occurrences of
this option will add or delete the listed network interface names from the set, depending of its type and
the default action.

The loopback interface ("lo") is not treated in any special way, you have to configure it explicitly in
the unit file.

Example 1: allow-list

RestrictNetworkInterfaces=eth1
RestrictNetworkInterfaces=eth2

Programs in the unit will be only able to use the eth1 and eth2 network interfaces.

Example 2: deny-list

RestrictNetworkInterfaces=~eth1 eth2

Programs in the unit will be able to use any network interface but eth1 and eth2.

Example 3: mixed

RestrictNetworkInterfaces=eth1 eth2
RestrictNetworkInterfaces=~eth1

Programs in the unit will be only able to use the eth2 network interface. Optional. Type uniline.

NFTSet
This setting provides a method for integrating dynamic cgroup, user and group IDs into firewall rules
with NFT <https://netfilter.org/projects/nftables/index.html> sets. The benefit of using this setting is
to be able to use the IDs as selectors in firewall rules easily and this in turn allows more fine grained
filtering. NFT rules for cgroup matching use numeric cgroup IDs, which change every time a service is
restarted, making them hard to use in systemd environment otherwise. Dynamic and random IDs used by
"DynamicUser" can be also integrated with this setting.

This option expects a whitespace separated list of NFT set definitions. Each definition consists of a
colon-separated tuple of source type (one of "cgroup", "user" or "group"), NFT address family (one of
"arp", "bridge", "inet", "ip", "ip6", or "netdev"), table name and set name. The names of tables and sets
must conform to lexical restrictions of NFT table names. The type of the element used in the NFT filter
must match the type implied by the directive ("cgroup", "user" or "group") as shown in the table below.
When a control group or a unit is realized, the corresponding ID will be appended to the NFT sets and it
will be be removed when the control group or unit is removed. systemd only inserts elements to (or
removes from) the sets, so the related NFT rules, tables and sets must be prepared elsewhere in advance.
Failures to manage the sets will be ignored.

If the firewall rules are reinstalled so that the contents of NFT sets are destroyed, command systemctl
daemon-reload can be used to refill the sets.

Example:

[Unit]
NFTSet=cgroup:inet:filter:my_service user:inet:filter:serviceuser

Corresponding NFT rules:

table inet filter {
set my_service {
type cgroupsv2
}
set serviceuser {
typeof meta skuid
}
chain x {
socket cgroupv2 level 2 @my_service accept
drop
}
chain y {
meta skuid @serviceuser accept
drop
}
}
I< Optional. Type uniline. >

IPIngressFilterPath
Add custom network traffic filters implemented as BPF programs, applying to all IP packets sent and
received over "AF_INET" and "AF_INET6" sockets. Takes an absolute path to a pinned BPF program in the
BPF virtual filesystem ("/sys/fs/bpf/").

The filters configured with this option are applied to all sockets created by processes of this unit (or
in the case of socket units, associated with it). The filters are loaded in addition to filters any of
the parent slice units this unit might be a member of as well as any "IPAddressAllow" and "IPAddressDeny"
filters in any of these units. By default there are no filters specified.

If these settings are used multiple times in the same unit all the specified programs are attached. If an
empty string is assigned to these settings the program list is reset and all previous specified programs
ignored.

If the path BPF_FS_PROGRAM_PATH in "IPIngressFilterPath" assignment is already being handled by
"BPFProgram" ingress hook, e.g. "BPFProgram""ingress":BPF_FS_PROGRAM_PATH, the assignment will be still
considered valid and the program will be attached to a cgroup. Same for "IPEgressFilterPath" path and
"egress" hook.

Note that for socket-activated services, the IP filter programs configured on the socket unit apply to
all sockets associated with it directly, but not to any sockets created by the ultimately activated
services for it. Conversely, the IP filter programs configured for the service are not applied to any
sockets passed into the service via socket activation. Thus, it is usually a good idea, to replicate the
IP filter programs on both the socket and the service unit, however it often makes sense to maintain one
configuration more open and the other one more restricted, depending on the use case.

Note that these settings might not be supported on some systems (for example if eBPF control group
support is not enabled in the underlying kernel or container manager). These settings will fail the
service in that case. If compatibility with such systems is desired it is hence recommended to attach
your filter manually (requires "Delegate""yes") instead of using this setting. Optional. Type uniline.

IPEgressFilterPath
Add custom network traffic filters implemented as BPF programs, applying to all IP packets sent and
received over "AF_INET" and "AF_INET6" sockets. Takes an absolute path to a pinned BPF program in the
BPF virtual filesystem ("/sys/fs/bpf/").

Note that these settings might not be supported on some systems (for example if eBPF control group
support is not enabled in the underlying kernel or container manager). These settings will fail the
service in that case. If compatibility with such systems is desired it is hence recommended to attach
your filter manually (requires "Delegate""yes") instead of using this setting. Optional. Type uniline.

BPFProgram
"BPFProgram" allows attaching custom BPF programs to the cgroup of a unit. (This generalizes the
functionality exposed via "IPEgressFilterPath" and "IPIngressFilterPath" for other hooks.) Cgroup-bpf
hooks in the form of BPF programs loaded to the BPF filesystem are attached with cgroup-bpf attach flags
determined by the unit. For details about attachment types and flags see "bpf.h"
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf.h>. Also
refer to the general BPF documentation <https://docs.kernel.org/bpf/>.

The specification of BPF program consists of a pair of BPF program type and program path in the file
system, with ":" as the separator: type:program-path.

The BPF program type is equivalent to the BPF attach type used in bpftool(8) It may be one of "egress",
"ingress", "sock_create", "sock_ops", "device", "bind4", "bind6", "connect4", "connect6", "post_bind4",
"post_bind6", "sendmsg4", "sendmsg6", "sysctl", "recvmsg4", "recvmsg6", "getsockopt", or "setsockopt".

The specified program path must be an absolute path referencing a BPF program inode in the bpffs file
system (which generally means it must begin with "/sys/fs/bpf/"). If a specified program does not exist
(i.e. has not been uploaded to the BPF subsystem of the kernel yet), it will not be installed but unit
activation will continue (a warning will be printed to the logs).

Setting "BPFProgram" to an empty value makes previous assignments ineffective.

Multiple assignments of the same program type/path pair have the same effect as a single assignment: the
program will be attached just once.

If BPF "egress" pinned to program-path path is already being handled by "IPEgressFilterPath",
"BPFProgram" assignment will be considered valid and "BPFProgram" will be attached to a cgroup.
Similarly for "ingress" hook and "IPIngressFilterPath" assignment.

BPF programs passed with "BPFProgram" are attached to the cgroup of a unit with BPF attach flag "multi",
that allows further attachments of the same type within cgroup hierarchy topped by the unit cgroup.

Examples:
BPFProgram=egress:/sys/fs/bpf/egress-hook
BPFProgram=bind6:/sys/fs/bpf/sock-addr-hook . Optional. Type uniline.

DeviceAllow
Control access to specific device nodes by the executed processes. Takes two space-separated strings: a
device node specifier followed by a combination of "r", "w", "m" to control reading, writing, or creation
of the specific device nodes by the unit (mknod), respectively. This functionality is implemented using
eBPF filtering.

When access to all physical devices should be disallowed, "PrivateDevices" may be used instead. See
systemd.exec(5).

The device node specifier is either a path to a device node in the file system, starting with "/dev/", or
a string starting with either "char-" or "block-" followed by a device group name, as listed in
"/proc/devices". The latter is useful to allow-list all current and future devices belonging to a
specific device group at once. The device group is matched according to filename globbing rules, you may
hence use the "*" and "?" wildcards. (Note that such globbing wildcards are not available for device
node path specifications!) In order to match device nodes by numeric major/minor, use device node paths
in the "/dev/char/" and "/dev/block/" directories. However, matching devices by major/minor is generally
not recommended as assignments are neither stable nor portable between systems or different kernel
versions.

Examples: "/dev/sda5" is a path to a device node, referring to an ATA or SCSI block device. "char-pts"
and "char-alsa" are specifiers for all pseudo TTYs and all ALSA sound devices, respectively. "char-cpu/*"
is a specifier matching all CPU related device groups.

Note that allow lists defined this way should only reference device groups which are resolvable at the
time the unit is started. Any device groups not resolvable then are not added to the device allow list.
In order to work around this limitation, consider extending service units with a pair of
After=modprobe@xyz.service and Wants=modprobe@xyz.service lines that load the necessary kernel module
implementing the device group if missing. Example:
…
[Unit]
Wants=modprobe@loop.service
After=modprobe@loop.service
[Service]
DeviceAllow=block-loop
DeviceAllow=/dev/loop-control
… Optional. Type list of uniline.

DevicePolicy
Control the policy for allowing device access: Optional. Type enum. choice: 'auto', 'closed', 'strict'.

Slice
The name of the slice unit to place the unit in. Defaults to "system.slice" for all non-instantiated
units of all unit types (except for slice units themselves see below). Instance units are by default
placed in a subslice of "system.slice" that is named after the template name.

This option may be used to arrange systemd units in a hierarchy of slices each of which might have
resource settings applied.

For units of type slice, the only accepted value for this setting is the parent slice. Since the name of
a slice unit implies the parent slice, it is hence redundant to ever set this parameter directly for
slice units.

Special care should be taken when relying on the default slice assignment in templated service units that
have "DefaultDependencies=no" set, see systemd.service(5), section "Default Dependencies" for details.
Optional. Type uniline.

Delegate
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 "User" 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 at
the level of the unit's control group and above (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 (possibly empty) 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. Assigning the empty string will enable delegation, but reset the
list of controllers, and all assignments prior to this will have no effect. Note that additional
controllers other than the ones specified might be made available as well, depending on configuration of
the containing slice unit or other units contained in it. Defaults to false.

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.

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.

Note that because of the hierarchical nature of cgroup hierarchy, any controllers that are delegated will
be enabled for the parent and sibling units of the unit with delegation.

For further details on the delegation model consult Control Group APIs and Delegation
<https://systemd.io/CGROUP_DELEGATION>. Optional. Type uniline.

DelegateSubgroup
Place unit processes in the specified subgroup of the unit's control group. Takes a valid control group
name (not a path!) as parameter, or an empty string to turn this feature off. Defaults to off. The
control group name must be usable as filename and avoid conflicts with the kernel's control group
attribute files (i.e. "cgroup.procs" is not an acceptable name, since the kernel exposes a native control
group attribute file by that name). This option has no effect unless control group delegation is turned
on via "Delegate", see above. Note that this setting only applies to "main" processes of a unit, i.e. for
services to "ExecStart", but not for "ExecReload" and similar. If delegation is enabled, the latter are
always placed inside a subgroup named ".control". The specified subgroup is automatically created (and
potentially ownership is passed to the unit's configured user/group) when a process is started in it.

This option is useful to avoid manually moving the invoked process into a subgroup after it has been
started. Since no processes should live in inner nodes of the control group tree it's almost always
necessary to run the main ("supervising") process of a unit that has delegation turned on in a subgroup.
Optional. Type uniline.

DisableControllers
Disables controllers from being enabled for a unit's children. If a controller listed is already in use
in its subtree, the controller will be removed from the subtree. This can be used to avoid configuration
in child units from being able to implicitly or explicitly enable a controller. Defaults to empty.

Multiple controllers may be specified, separated by spaces. You may also pass "DisableControllers"
multiple times, in which case each new instance adds another controller to disable. Passing
"DisableControllers" by itself with no controller name present resets the disabled controller list.

It may not be possible to disable a controller after units have been started, if the unit or any child of
the unit in question delegates controllers to its children, as any delegated subtree of the cgroup
hierarchy is unmanaged by systemd. Optional. Type uniline.

ManagedOOMSwap
Specifies how systemd-oomd.service(8) will act on this unit's cgroups. Defaults to "auto".

When set to "kill", the unit becomes a candidate for monitoring by systemd-oomd. If the cgroup passes the
limits set by oomd.conf(5) or the unit configuration, systemd-oomd will select a descendant cgroup and
send "SIGKILL" to all of the processes under it. You can find more details on candidates and kill
behavior at systemd-oomd.service(8) and oomd.conf(5).

Setting either of these properties to "kill" will also result in "After" and "Wants" dependencies on
"systemd-oomd.service" unless "DefaultDependencies=no".

When set to "auto", systemd-oomd will not actively use this cgroup's data for monitoring and detection.
However, if an ancestor cgroup has one of these properties set to "kill", a unit with "auto" can still be
a candidate for systemd-oomd to terminate. Optional. Type enum. choice: 'auto', 'kill'.

ManagedOOMMemoryPressure
Specifies how systemd-oomd.service(8) will act on this unit's cgroups. Defaults to "auto".

Setting either of these properties to "kill" will also result in "After" and "Wants" dependencies on
"systemd-oomd.service" unless "DefaultDependencies=no".

ManagedOOMMemoryPressureLimit
Overrides the default memory pressure limit set by oomd.conf(5) for this unit (cgroup). Takes a
percentage value between 0% and 100%, inclusive. This property is ignored unless
"ManagedOOMMemoryPressure""kill". Defaults to 0%, which means to use the default set by oomd.conf(5).
Optional. Type uniline.

ManagedOOMPreference
Allows deprioritizing or omitting this unit's cgroup as a candidate when systemd-oomd needs to act.
Requires support for extended attributes (see xattr(7)) in order to use "avoid" or "omit".

When calculating candidates to relieve swap usage, systemd-oomd will only respect these extended
attributes if the unit's cgroup is owned by root.

When calculating candidates to relieve memory pressure, systemd-oomd will only respect these extended
attributes if the unit's cgroup is owned by root, or if the unit's cgroup owner, and the owner of the
monitored ancestor cgroup are the same. For example, if systemd-oomd is calculating candidates for
"-.slice", then extended attributes set on descendants of
"/user.slice/user-1000.slice/user@1000.service/" will be ignored because the descendants are owned by UID
1000, and "-.slice" is owned by UID 0. But, if calculating candidates for
"/user.slice/user-1000.slice/user@1000.service/", then extended attributes set on the descendants would
be respected.

If this property is set to "avoid", the service manager will convey this to systemd-oomd, which will only
select this cgroup if there are no other viable candidates.

If this property is set to "omit", the service manager will convey this to systemd-oomd, which will
ignore this cgroup as a candidate and will not perform any actions on it.

It is recommended to use "avoid" and "omit" sparingly, as it can adversely affect systemd-oomd's kill
behavior. Also note that these extended attributes are not applied recursively to cgroups under this
unit's cgroup.

Defaults to "none" which means systemd-oomd will rank this unit's cgroup as defined in
systemd-oomd.service(8) and oomd.conf(5). Optional. Type enum. choice: 'avoid', 'none', 'omit'.

MemoryPressureWatch
Controls memory pressure monitoring for invoked processes. Takes one of "off", "on", "auto" or "skip". If
"off" tells the service not to watch for memory pressure events, by setting the $MEMORY_PRESSURE_WATCH
environment variable to the literal string "/dev/null". If "on" tells the service to watch for memory
pressure events. This enables memory accounting for the service, and ensures the "memory.pressure" cgroup
attribute file is accessible for reading and writing by the service's user. It then sets the
$MEMORY_PRESSURE_WATCH environment variable for processes invoked by the unit to the file system path to
this file. The threshold information configured with "MemoryPressureThresholdSec" is encoded in the
$MEMORY_PRESSURE_WRITE environment variable. If the "auto" value is set the protocol is enabled if memory
accounting is anyway enabled for the unit, and disabled otherwise. If set to "skip" the logic is neither
enabled, nor disabled and the two environment variables are not set.

Note that services are free to use the two environment variables, but it's unproblematic if they ignore
them. Memory pressure handling must be implemented individually in each service, and usually means
different things for different software. For further details on memory pressure handling see Memory
Pressure Handling in systemd <https://systemd.io/MEMORY_PRESSURE>.

Services implemented using sd-event(3) may use sd_event_add_memory_pressure(3) to watch for and handle
memory pressure events.

If not explicit set, defaults to the "DefaultMemoryPressureWatch" setting in systemd-system.conf(5).
Optional. Type enum. choice: 'auto', 'off', 'on', 'skip'.

MemoryPressureThresholdSec
Sets the memory pressure threshold time for memory pressure monitor as configured via
"MemoryPressureWatch". Specifies the maximum allocation latency before a memory pressure event is
signalled to the service, per 2s window. If not specified defaults to the
"DefaultMemoryPressureThresholdSec" setting in systemd-system.conf(5) (which in turn defaults to 200ms).
The specified value expects a time unit such as "ms" or "μs", see systemd.time(7) for details on the
permitted syntax. Optional. Type uniline.

CoredumpReceive
Takes a boolean argument. This setting is used to enable coredump forwarding for containers that belong
to this unit's cgroup. Units with "CoredumpReceive=yes" must also be configured with "Delegate=yes".
Defaults to false.

When systemd-coredump is handling a coredump for a process from a container, if the container's leader
process is a descendant of a cgroup with "CoredumpReceive=yes" and "Delegate=yes", then systemd-coredump
will attempt to forward the coredump to systemd-coredump within the container. Optional. Type boolean.

ExecSearchPath
Takes a colon separated list of absolute paths relative to which the executable used by the "Exec*="
(e.g. "ExecStart", "ExecStop", etc.) properties can be found. "ExecSearchPath" overrides $PATH if $PATH
is not supplied by the user through "Environment", "EnvironmentFile" or "PassEnvironment". Assigning an
empty string removes previous assignments and setting "ExecSearchPath" to a value multiple times will
append to the previous setting. Optional. Type list of uniline.

WorkingDirectory
Takes a directory path relative to the service's root directory specified by "RootDirectory", or the
special value "~". Sets the working directory for executed processes. If set to "~", the home directory
of the user specified in "User" is used. If not set, defaults to the root directory when systemd is
running as a system instance and the respective user's home directory if run as user. If the setting is
prefixed with the "-" character, a missing working directory is not considered fatal. If
"RootDirectory"/"RootImage" is not set, then "WorkingDirectory" is relative to the root of the system
running the service manager. Note that setting this parameter might result in additional dependencies to
be added to the unit (see above). Optional. Type uniline.

RootDirectory
Takes a directory path relative to the host's root directory (i.e. the root of the system running the
service manager). Sets the root directory for executed processes, with the pivot_root(2) or chroot(2)
system call. If this is used, it must be ensured that the process binary and all its auxiliary files are
available in the new root. Note that setting this parameter might result in additional dependencies to be
added to the unit (see above).

The "MountAPIVFS" and "PrivateUsers" settings are particularly useful in conjunction with
"RootDirectory". For details, see below.

If "RootDirectory"/"RootImage" are used together with "NotifyAccess" the notification socket is
automatically mounted from the host into the root environment, to ensure the notification interface can
work correctly.

Note that services using "RootDirectory"/"RootImage" will not be able to log via the syslog or journal
protocols to the host logging infrastructure, unless the relevant sockets are mounted from the host,
specifically:

The host's os-release(5) file will be made available for the service (read-only) as
"/run/host/os-release". It will be updated automatically on soft reboot (see:
systemd-soft-reboot.service(8)), in case the service is configured to survive it. Optional. Type
uniline.

RootImage
Takes a path to a block device node or regular file as argument. This call is similar to "RootDirectory"
however mounts a file system hierarchy from a block device node or loopback file instead of a directory.
The device node or file system image file needs to contain a file system without a partition table, or a
file system within an MBR/MS-DOS or GPT partition table with only a single Linux-compatible partition, or
a set of file systems within a GPT partition table that follows the Discoverable Partitions Specification
<https://uapi-group.org/specifications/specs/discoverable_partitions_specification>.

When "DevicePolicy" is set to "closed" or "strict", or set to "auto" and "DeviceAllow" is set, then this
setting adds "/dev/loop-control" with "rw" mode, "block-loop" and "block-blkext" with "rwm" mode to
"DeviceAllow". See systemd.resource-control(5) for the details about "DevicePolicy" or "DeviceAllow".
Also, see "PrivateDevices" below, as it may change the setting of "DevicePolicy".

Units making use of "RootImage" automatically gain an "After" dependency on "systemd-udevd.service".

RootImageOptions
Takes a comma-separated list of mount options that will be used on disk images specified by "RootImage".
Optionally a partition name can be prefixed, followed by colon, in case the image has multiple
partitions, otherwise partition name "root" is implied. Options for multiple partitions can be specified
in a single line with space separators. Assigning an empty string removes previous assignments.
Duplicated options are ignored. For a list of valid mount options, please refer to mount(8).

Valid partition names follow the Discoverable Partitions Specification <https://uapi-
group.org/specifications/specs/discoverable_partitions_specification>: "root", "usr", "home", "srv",
"esp", "xbootldr", "tmp", "var". Optional. Type uniline.

RootEphemeral
Takes a boolean argument. If enabled, executed processes will run in an ephemeral copy of the root
directory or root image. The ephemeral copy is placed in "/var/lib/systemd/ephemeral-trees/" while the
service is active and is cleaned up when the service is stopped or restarted. If "RootDirectory" is used
and the root directory is a subvolume, the ephemeral copy will be created by making a snapshot of the
subvolume.

To make sure making ephemeral copies can be made efficiently, the root directory or root image should be
located on the same filesystem as "/var/lib/systemd/ephemeral-trees/". When using "RootEphemeral" with
root directories, btrfs(5) should be used as the filesystem and the root directory should ideally be a
subvolume which systemd can snapshot to make the ephemeral copy. For root images, a filesystem with
support for reflinks should be used to ensure an efficient ephemeral copy. Optional. Type boolean.

RootHash
Takes a data integrity (dm-verity) root hash specified in hexadecimal, or the path to a file containing a
root hash in ASCII hexadecimal format. This option enables data integrity checks using dm-verity, if the
used image contains the appropriate integrity data (see above) or if "RootVerity" is used. The specified
hash must match the root hash of integrity data, and is usually at least 256 bits (and hence 64 formatted
hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but the
image file carries the "user.verity.roothash" extended file attribute (see xattr(7)), then the root hash
is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found
(or is not supported by the underlying file system), but a file with the ".roothash" suffix is found next
to the image file, bearing otherwise the same name (except if the image has the ".raw" suffix, in which
case the root hash file must not have it in its name), the root hash is read from it and automatically
used, also as formatted hexadecimal characters.

If the disk image contains a separate "/usr/" partition it may also be Verity protected, in which case
the root hash may configured via an extended attribute "user.verity.usrhash" or a ".usrhash" file
adjacent to the disk image. There's currently no option to configure the root hash for the "/usr/" file
system via the unit file directly. Optional. Type uniline.

RootHashSignature
Takes a PKCS7 signature of the "RootHash" option as a path to a DER-encoded signature file, or as an
ASCII base64 string encoding of a DER-encoded signature prefixed by "base64:". The dm-verity volume will
only be opened if the signature of the root hash is valid and signed by a public key present in the
kernel keyring. If this option is not specified, but a file with the ".roothash.p7s" suffix is found next
to the image file, bearing otherwise the same name (except if the image has the ".raw" suffix, in which
case the signature file must not have it in its name), the signature is read from it and automatically
used.

If the disk image contains a separate "/usr/" partition it may also be Verity protected, in which case
the signature for the root hash may configured via a ".usrhash.p7s" file adjacent to the disk image.
There's currently no option to configure the root hash signature for the "/usr/" via the unit file
directly. Optional. Type uniline.

RootVerity
Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks using dm-
verity, if "RootImage" is used and a root-hash is passed and if the used image itself does not contain
the integrity data. The integrity data must be matched by the root hash. If this option is not specified,
but a file with the ".verity" suffix is found next to the image file, bearing otherwise the same name
(except if the image has the ".raw" suffix, in which case the verity data file must not have it in its
name), the verity data is read from it and automatically used.

This option is supported only for disk images that contain a single file system, without an enveloping
partition table. Images that contain a GPT partition table should instead include both root file system
and matching Verity data in the same image, implementing the Discoverable Partitions Specification
<https://uapi-group.org/specifications/specs/discoverable_partitions_specification>. Optional. Type
uniline.

RootImagePolicy
Takes an image policy string as per systemd.image-policy(7) to use when mounting the disk images (DDI)
specified in "RootImage", "MountImage", "ExtensionImage", respectively. If not specified the following
policy string is the default for "RootImagePolicy" and "MountImagePolicy":

root=verity+signed+encrypted+unprotected+absent: \
usr=verity+signed+encrypted+unprotected+absent: \
home=encrypted+unprotected+absent: \
srv=encrypted+unprotected+absent: \
tmp=encrypted+unprotected+absent: \
var=encrypted+unprotected+absent

The default policy for "ExtensionImagePolicy" is:

root=verity+signed+encrypted+unprotected+absent: \
usr=verity+signed+encrypted+unprotected+absent
. I< Optional. Type uniline. >

MountImagePolicy
Takes an image policy string as per systemd.image-policy(7) to use when mounting the disk images (DDI)
specified in "RootImage", "MountImage", "ExtensionImage", respectively. If not specified the following
policy string is the default for "RootImagePolicy" and "MountImagePolicy":

The default policy for "ExtensionImagePolicy" is:

root=verity+signed+encrypted+unprotected+absent: \
usr=verity+signed+encrypted+unprotected+absent
. I< Optional. Type uniline. >

ExtensionImagePolicy
Takes an image policy string as per systemd.image-policy(7) to use when mounting the disk images (DDI)
specified in "RootImage", "MountImage", "ExtensionImage", respectively. If not specified the following
policy string is the default for "RootImagePolicy" and "MountImagePolicy":

The default policy for "ExtensionImagePolicy" is:

root=verity+signed+encrypted+unprotected+absent: \
usr=verity+signed+encrypted+unprotected+absent
. I< Optional. Type uniline. >

MountAPIVFS
Takes a boolean argument. If on, a private mount namespace for the unit's processes is created and the
API file systems "/proc/", "/sys/", "/dev/" and "/run/" (as an empty "tmpfs") are mounted inside of it,
unless they are already mounted. Note that this option has no effect unless used in conjunction with
"RootDirectory"/"RootImage" as these four mounts are generally mounted in the host anyway, and unless the
root directory is changed, the private mount namespace will be a 1:1 copy of the host's, and include
these four mounts. Note that the "/dev/" file system of the host is bind mounted if this option is used
without "PrivateDevices". To run the service with a private, minimal version of "/dev/", combine this
option with "PrivateDevices".

In order to allow propagating mounts at runtime in a safe manner, "/run/systemd/propagate/" on the host
will be used to set up new mounts, and "/run/host/incoming/" in the private namespace will be used as an
intermediate step to store them before being moved to the final mount point. Optional. Type boolean.

ProtectProc
Takes one of "noaccess", "invisible", "ptraceable" or "default" (which it defaults to). When set, this
controls the "hidepid=" mount option of the "procfs" instance for the unit that controls which
directories with process metainformation ("/proc/PID") are visible and accessible: when set to "noaccess"
the ability to access most of other users' process metadata in "/proc/" is taken away for processes of
the service. When set to "invisible" processes owned by other users are hidden from "/proc/". If
"ptraceable" all processes that cannot be ptrace()'ed by a process are hidden to it. If "default" no
restrictions on "/proc/" access or visibility are made. For further details see The /proc Filesystem
<https://docs.kernel.org/filesystems/proc.html#mount-options>. It is generally recommended to run most
system services with this option set to "invisible". This option is implemented via file system
namespacing, and thus cannot be used with services that shall be able to install mount points in the host
file system hierarchy. Note that the root user is unaffected by this option, so to be effective it has to
be used together with "User" or "DynamicUser=yes", and also without the "CAP_SYS_PTRACE" capability,
which also allows a process to bypass this feature. It cannot be used for services that need to access
metainformation about other users' processes. This option implies "MountAPIVFS".

If the kernel doesn't support per-mount point "hidepid=" mount options this setting remains without
effect, and the unit's processes will be able to access and see other process as if the option was not
used. Optional. Type enum. choice: 'default', 'invisible', 'noaccess', 'ptraceable'.

ProcSubset
Takes one of "all" (the default) and "pid". If "pid", all files and directories not directly associated
with process management and introspection are made invisible in the "/proc/" file system configured for
the unit's processes. This controls the "subset=" mount option of the "procfs" instance for the unit. For
further details see The /proc Filesystem <https://docs.kernel.org/filesystems/proc.html#mount-options>.
Note that Linux exposes various kernel APIs via "/proc/", which are made unavailable with this setting.
Since these APIs are used frequently this option is useful only in a few, specific cases, and is not
suitable for most non-trivial programs.

Much like "ProtectProc" above, this is implemented via file system mount namespacing, and hence the same
restrictions apply: it is only available to system services, it disables mount propagation to the host
mount table, and it implies "MountAPIVFS". Also, like "ProtectProc" this setting is gracefully disabled
if the used kernel does not support the "subset=" mount option of "procfs". Optional. Type enum. choice:
'all', 'pid'.

BindPaths
Configures unit-specific bind mounts. A bind mount makes a particular file or directory available at an
additional place in the unit's view of the file system. Any bind mounts created with this option are
specific to the unit, and are not visible in the host's mount table. This option expects a whitespace
separated list of bind mount definitions. Each definition consists of a colon-separated triple of source
path, destination path and option string, where the latter two are optional. If only a source path is
specified the source and destination is taken to be the same. The option string may be either "rbind" or
"norbind" for configuring a recursive or non-recursive bind mount. If the destination path is omitted,
the option string must be omitted too. Each bind mount definition may be prefixed with "-", in which
case it will be ignored when its source path does not exist.

"BindPaths" creates regular writable bind mounts (unless the source file system mount is already marked
read-only), while "BindReadOnlyPaths" creates read-only bind mounts. These settings may be used more than
once, each usage appends to the unit's list of bind mounts. If the empty string is assigned to either of
these two options the entire list of bind mounts defined prior to this is reset. Note that in this case
both read-only and regular bind mounts are reset, regardless which of the two settings is used.

Using this option implies that a mount namespace is allocated for the unit, i.e. it implies the effect of
"PrivateMounts" (see below).

This option is particularly useful when "RootDirectory"/"RootImage" is used. In this case the source path
refers to a path on the host file system, while the destination path refers to a path below the root
directory of the unit.

Note that the destination directory must exist or systemd must be able to create it. Thus, it is not
possible to use those options for mount points nested underneath paths specified in "InaccessiblePaths",
or under "/home/" and other protected directories if "ProtectHome=yes" is specified.
"TemporaryFileSystem" with ":ro" or "ProtectHome=tmpfs" should be used instead. Optional. Type list of
uniline.

BindReadOnlyPaths
Configures unit-specific bind mounts. A bind mount makes a particular file or directory available at an
additional place in the unit's view of the file system. Any bind mounts created with this option are
specific to the unit, and are not visible in the host's mount table. This option expects a whitespace
separated list of bind mount definitions. Each definition consists of a colon-separated triple of source
path, destination path and option string, where the latter two are optional. If only a source path is
specified the source and destination is taken to be the same. The option string may be either "rbind" or
"norbind" for configuring a recursive or non-recursive bind mount. If the destination path is omitted,
the option string must be omitted too. Each bind mount definition may be prefixed with "-", in which
case it will be ignored when its source path does not exist.

Using this option implies that a mount namespace is allocated for the unit, i.e. it implies the effect of
"PrivateMounts" (see below).

MountImages
This setting is similar to "RootImage" in that it mounts a file system hierarchy from a block device node
or loopback file, but the destination directory can be specified as well as mount options. This option
expects a whitespace separated list of mount definitions. Each definition consists of a colon-separated
tuple of source path and destination definitions, optionally followed by another colon and a list of
mount options.

Mount options may be defined as a single comma-separated list of options, in which case they will be
implicitly applied to the root partition on the image, or a series of colon-separated tuples of partition
name and mount options. Valid partition names and mount options are the same as for "RootImageOptions"
setting described above.

Each mount definition may be prefixed with "-", in which case it will be ignored when its source path
does not exist. The source argument is a path to a block device node or regular file. If source or
destination contain a ":", it needs to be escaped as "\:". The device node or file system image file
needs to follow the same rules as specified for "RootImage". Any mounts created with this option are
specific to the unit, and are not visible in the host's mount table.

These settings may be used more than once, each usage appends to the unit's list of mount paths. If the
empty string is assigned, the entire list of mount paths defined prior to this is reset.

ExtensionImages
This setting is similar to "MountImages" in that it mounts a file system hierarchy from a block device
node or loopback file, but instead of providing a destination path, an overlay will be set up. This
option expects a whitespace separated list of mount definitions. Each definition consists of a source
path, optionally followed by a colon and a list of mount options.

A read-only OverlayFS will be set up on top of "/usr/" and "/opt/" hierarchies for sysext images and
"/etc/" hierarchy for confext images. The order in which the images are listed will determine the order
in which the overlay is laid down: images specified first to last will result in overlayfs layers bottom
to top.

Each mount definition may be prefixed with "-", in which case it will be ignored when its source path
does not exist. The source argument is a path to a block device node or regular file. If the source path
contains a ":", it needs to be escaped as "\:". The device node or file system image file needs to follow
the same rules as specified for "RootImage". Any mounts created with this option are specific to the
unit, and are not visible in the host's mount table.

These settings may be used more than once, each usage appends to the unit's list of image paths. If the
empty string is assigned, the entire list of mount paths defined prior to this is reset.

Each sysext image must carry a "/usr/lib/extension-release.d/extension-release.IMAGE" file while each
confext image must carry a "/etc/extension-release.d/extension-release.IMAGE" file, with the appropriate
metadata which matches "RootImage"/"RootDirectory" or the host. See: os-release(5). To disable the
safety check that the extension-release file name matches the image file name, the
"x-systemd.relax-extension-release-check" mount option may be appended.

ExtensionDirectories
This setting is similar to "BindReadOnlyPaths" in that it mounts a file system hierarchy from a
directory, but instead of providing a destination path, an overlay will be set up. This option expects a
whitespace separated list of source directories.

A read-only OverlayFS will be set up on top of "/usr/" and "/opt/" hierarchies for sysext images and
"/etc/" hierarchy for confext images. The order in which the directories are listed will determine the
order in which the overlay is laid down: directories specified first to last will result in overlayfs
layers bottom to top.

Each directory listed in "ExtensionDirectories" may be prefixed with "-", in which case it will be
ignored when its source path does not exist. Any mounts created with this option are specific to the
unit, and are not visible in the host's mount table.

These settings may be used more than once, each usage appends to the unit's list of directories paths. If
the empty string is assigned, the entire list of mount paths defined prior to this is reset.

Each sysext directory must contain a "/usr/lib/extension-release.d/extension-release.IMAGE" file while
each confext directory must carry a "/etc/extension-release.d/extension-release.IMAGE" file, with the
appropriate metadata which matches "RootImage"/"RootDirectory" or the host. See: os-release(5).

Note that usage from user units requires overlayfs support in unprivileged user namespaces, which was
first introduced in kernel v5.11. Optional. Type list of uniline.

User
Set the UNIX user or group that the processes are executed as, respectively. Takes a single user or group
name, or a numeric ID as argument. For system services (services run by the system service manager, i.e.
managed by PID 1) and for user services of the root user (services managed by root's instance of systemd
--user), the default is "root", but "User" may be used to specify a different user. For user services of
any other user, switching user identity is not permitted, hence the only valid setting is the same user
the user's service manager is running as. If no group is set, the default group of the user is used. This
setting does not affect commands whose command line is prefixed with "+".

Note that this enforces only weak restrictions on the user/group name syntax, but will generate warnings
in many cases where user/group names do not adhere to the following rules: the specified name should
consist only of the characters a-z, A-Z, 0-9, "_" and "-", except for the first character which must be
one of a-z, A-Z and "_" (i.e. digits and "-" are not permitted as first character). The user/group name
must have at least one character, and at most 31. These restrictions are made in order to avoid
ambiguities and to ensure user/group names and unit files remain portable among Linux systems. For
further details on the names accepted and the names warned about see User/Group Name Syntax
<https://systemd.io/USER_NAMES>.

When used in conjunction with "DynamicUser" the user/group name specified is dynamically allocated at the
time the service is started, and released at the time the service is stopped — unless it is already
allocated statically (see below). If "DynamicUser" is not used the specified user and group must have
been created statically in the user database no later than the moment the service is started, for example
using the sysusers.d(5) facility, which is applied at boot or package install time. If the user does not
exist by then program invocation will fail.

If the "User" setting is used the supplementary group list is initialized from the specified user's
default group list, as defined in the system's user and group database. Additional groups may be
configured through the "SupplementaryGroups" setting (see below). Optional. Type uniline.

Group
Set the UNIX user or group that the processes are executed as, respectively. Takes a single user or group
name, or a numeric ID as argument. For system services (services run by the system service manager, i.e.
managed by PID 1) and for user services of the root user (services managed by root's instance of systemd
--user), the default is "root", but "User" may be used to specify a different user. For user services of
any other user, switching user identity is not permitted, hence the only valid setting is the same user
the user's service manager is running as. If no group is set, the default group of the user is used. This
setting does not affect commands whose command line is prefixed with "+".

DynamicUser
Takes a boolean parameter. If set, a UNIX user and group pair is allocated dynamically when the unit is
started, and released as soon as it is stopped. The user and group will not be added to "/etc/passwd" or
"/etc/group", but are managed transiently during runtime. The nss-systemd(8) glibc NSS module provides
integration of these dynamic users/groups into the system's user and group databases. The user and group
name to use may be configured via "User" and "Group" (see above). If these options are not used and
dynamic user/group allocation is enabled for a unit, the name of the dynamic user/group is implicitly
derived from the unit name. If the unit name without the type suffix qualifies as valid user name it is
used directly, otherwise a name incorporating a hash of it is used. If a statically allocated user or
group of the configured name already exists, it is used and no dynamic user/group is allocated. Note that
if "User" is specified and the static group with the name exists, then it is required that the static
user with the name already exists. Similarly, if "Group" is specified and the static user with the name
exists, then it is required that the static group with the name already exists. Dynamic users/groups are
allocated from the UID/GID range 61184…65519. It is recommended to avoid this range for regular system or
login users. At any point in time each UID/GID from this range is only assigned to zero or one
dynamically allocated users/groups in use. However, UID/GIDs are recycled after a unit is terminated.
Care should be taken that any processes running as part of a unit for which dynamic users/groups are
enabled do not leave files or directories owned by these users/groups around, as a different unit might
get the same UID/GID assigned later on, and thus gain access to these files or directories. If
"DynamicUser" is enabled, "RemoveIPC" and "PrivateTmp" are implied (and cannot be turned off). This
ensures that the lifetime of IPC objects and temporary files created by the executed processes is bound
to the runtime of the service, and hence the lifetime of the dynamic user/group. Since "/tmp/" and
"/var/tmp/" are usually the only world-writable directories on a system this ensures that a unit making
use of dynamic user/group allocation cannot leave files around after unit termination. Furthermore
"NoNewPrivileges" and "RestrictSUIDSGID" are implicitly enabled (and cannot be disabled), to ensure that
processes invoked cannot take benefit or create SUID/SGID files or directories. Moreover
"ProtectSystem=strict" and "ProtectHome=read-only" are implied, thus prohibiting the service to write to
arbitrary file system locations. In order to allow the service to write to certain directories, they have
to be allow-listed using "ReadWritePaths", but care must be taken so that UID/GID recycling doesn't
create security issues involving files created by the service. Use "RuntimeDirectory" (see below) in
order to assign a writable runtime directory to a service, owned by the dynamic user/group and removed
automatically when the unit is terminated. Use "StateDirectory", "CacheDirectory" and "LogsDirectory" in
order to assign a set of writable directories for specific purposes to the service in a way that they are
protected from vulnerabilities due to UID reuse (see below). If this option is enabled, care should be
taken that the unit's processes do not get access to directories outside of these explicitly configured
and managed ones. Specifically, do not use "BindPaths" and be careful with "AF_UNIX" file descriptor
passing for directory file descriptors, as this would permit processes to create files or directories
owned by the dynamic user/group that are not subject to the lifecycle and access guarantees of the
service. Note that this option is currently incompatible with D-Bus policies, thus a service using this
option may currently not allocate a D-Bus service name (note that this does not affect calling into other
D-Bus services). Defaults to off. Optional. Type boolean.

SupplementaryGroups
Sets the supplementary Unix groups the processes are executed as. This takes a space-separated list of
group names or IDs. This option may be specified more than once, in which case all listed groups are set
as supplementary groups. When the empty string is assigned, the list of supplementary groups is reset,
and all assignments prior to this one will have no effect. In any way, this option does not override, but
extends the list of supplementary groups configured in the system group database for the user. This does
not affect commands prefixed with "+". Optional. Type list of uniline.

SetLoginEnvironment
Takes a boolean parameter that controls whether to set the $HOME, $LOGNAME, and $SHELL environment
variables. If not set, this defaults to true if "User", "DynamicUser" or "PAMName" are set, false
otherwise. If set to true, the variables will always be set for system services, i.e. even when the
default user "root" is used. If set to false, the mentioned variables are not set by the service manager,
no matter whether "User", "DynamicUser", or "PAMName" are used or not. This option normally has no effect
on services of the per-user service manager, since in that case these variables are typically inherited
from user manager's own environment anyway. Optional. Type boolean.

PAMName
Sets the PAM service name to set up a session as. If set, the executed process will be registered as a
PAM session under the specified service name. This is only useful in conjunction with the "User" setting,
and is otherwise ignored. If not set, no PAM session will be opened for the executed processes. See
pam(8) for details.

Note that for each unit making use of this option a PAM session handler process will be maintained as
part of the unit and stays around as long as the unit is active, to ensure that appropriate actions can
be taken when the unit and hence the PAM session terminates. This process is named "(sd-pam)" and is an
immediate child process of the unit's main process.

Note that when this option is used for a unit it is very likely (depending on PAM configuration) that the
main unit process will be migrated to its own session scope unit when it is activated. This process will
hence be associated with two units: the unit it was originally started from (and for which "PAMName" was
configured), and the session scope unit. Any child processes of that process will however be associated
with the session scope unit only. This has implications when used in combination with
"NotifyAccess""all", as these child processes will not be able to affect changes in the original unit
through notification messages. These messages will be considered belonging to the session scope unit and
not the original unit. It is hence not recommended to use "PAMName" in combination with
"NotifyAccess""all". Optional. Type uniline.

CapabilityBoundingSet
Controls which capabilities to include in the capability bounding set for the executed process. See
capabilities(7) for details. Takes a whitespace-separated list of capability names, e.g. "CAP_SYS_ADMIN",
"CAP_DAC_OVERRIDE", "CAP_SYS_PTRACE". Capabilities listed will be included in the bounding set, all
others are removed. If the list of capabilities is prefixed with "~", all but the listed capabilities
will be included, the effect of the assignment inverted. Note that this option also affects the
respective capabilities in the effective, permitted and inheritable capability sets. If this option is
not used, the capability bounding set is not modified on process execution, hence no limits on the
capabilities of the process are enforced. This option may appear more than once, in which case the
bounding sets are merged by "OR", or by "AND" if the lines are prefixed with "~" (see below). If the
empty string is assigned to this option, the bounding set is reset to the empty capability set, and all
prior settings have no effect. If set to "~" (without any further argument), the bounding set is reset to
the full set of available capabilities, also undoing any previous settings. This does not affect commands
prefixed with "+".

Use systemd-analyze(1)'s capability command to retrieve a list of capabilities defined on the local
system.

Example: if a unit has the following,

CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=CAP_B CAP_C

then "CAP_A", "CAP_B", and "CAP_C" are set. If the second line is prefixed with "~", e.g.,

CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=~CAP_B CAP_C

then, only "CAP_A" is set. Optional. Type uniline.

AmbientCapabilities
Controls which capabilities to include in the ambient capability set for the executed process. Takes a
whitespace-separated list of capability names, e.g. "CAP_SYS_ADMIN", "CAP_DAC_OVERRIDE",
"CAP_SYS_PTRACE". This option may appear more than once, in which case the ambient capability sets are
merged (see the above examples in "CapabilityBoundingSet"). If the list of capabilities is prefixed with
"~", all but the listed capabilities will be included, the effect of the assignment inverted. If the
empty string is assigned to this option, the ambient capability set is reset to the empty capability set,
and all prior settings have no effect. If set to "~" (without any further argument), the ambient
capability set is reset to the full set of available capabilities, also undoing any previous settings.
Note that adding capabilities to the ambient capability set adds them to the process's inherited
capability set.

Ambient capability sets are useful if you want to execute a process as a non-privileged user but still
want to give it some capabilities. Note that in this case option "keep-caps" is automatically added to
"SecureBits" to retain the capabilities over the user change. "AmbientCapabilities" does not affect
commands prefixed with "+". Optional. Type uniline.

NoNewPrivileges
Takes a boolean argument. If true, ensures that the service process and all its children can never gain
new privileges through execve() (e.g. via setuid or setgid bits, or filesystem capabilities). This is the
simplest and most effective way to ensure that a process and its children can never elevate privileges
again. Defaults to false. In case the service will be run in a new mount namespace anyway and SELinux is
disabled, all file systems are mounted with "MS_NOSUID" flag. Also see No New Privileges Flag
<https://docs.kernel.org/userspace-api/no_new_privs.html>.

Note that this setting only has an effect on the unit's processes themselves (or any processes directly
or indirectly forked off them). It has no effect on processes potentially invoked on request of them
through tools such as at(1), crontab(1), systemd-run(1), or arbitrary IPC services. Optional. Type
boolean.

SecureBits
Controls the secure bits set for the executed process. Takes a space-separated combination of options
from the following list: "keep-caps", "keep-caps-locked", "no-setuid-fixup", "no-setuid-fixup-locked",
"noroot", and "noroot-locked". This option may appear more than once, in which case the secure bits are
ORed. If the empty string is assigned to this option, the bits are reset to 0. This does not affect
commands prefixed with "+". See capabilities(7) for details. Optional. Type uniline.

SELinuxContext
Set the SELinux security context of the executed process. If set, this will override the automated domain
transition. However, the policy still needs to authorize the transition. This directive is ignored if
SELinux is disabled. If prefixed by "-", failing to set the SELinux security context will be ignored, but
it's still possible that the subsequent execve() may fail if the policy doesn't allow the transition for
the non-overridden context. This does not affect commands prefixed with "+". See setexeccon(3) for
details. Optional. Type uniline.

AppArmorProfile
Takes a profile name as argument. The process executed by the unit will switch to this profile when
started. Profiles must already be loaded in the kernel, or the unit will fail. If prefixed by "-", all
errors will be ignored. This setting has no effect if AppArmor is not enabled. This setting does not
affect commands prefixed with "+". Optional. Type uniline.

SmackProcessLabel
Takes a "SMACK64" security label as argument. The process executed by the unit will be started under this
label and SMACK will decide whether the process is allowed to run or not, based on it. The process will
continue to run under the label specified here unless the executable has its own "SMACK64EXEC" label, in
which case the process will transition to run under that label. When not specified, the label that
systemd is running under is used. This directive is ignored if SMACK is disabled.

The value may be prefixed by "-", in which case all errors will be ignored. An empty value may be
specified to unset previous assignments. This does not affect commands prefixed with "+". Optional. Type
uniline.

LimitCPU
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

Note that most process resource limits configured with these options are per-process, and processes may
fork in order to acquire a new set of resources that are accounted independently of the original process,
and may thus escape limits set. Also note that "LimitRSS" is not implemented on Linux, and setting it has
no effect. Often it is advisable to prefer the resource controls listed in systemd.resource-control(5)
over these per-process limits, as they apply to services as a whole, may be altered dynamically at
runtime, and are generally more expressive. For example, "MemoryMax" is a more powerful (and working)
replacement for "LimitRSS".

Note that "LimitNPROC" will limit the number of processes from one (real) UID and not the number of
processes started (forked) by the service. Therefore the limit is cumulative for all processes running
under the same UID. Please also note that the "LimitNPROC" will not be enforced if the service is running
as root (and not dropping privileges). Due to these limitations, "TasksMax" (see
systemd.resource-control(5)) is typically a better choice than "LimitNPROC".

Resource limits not configured explicitly for a unit default to the value configured in the various
"DefaultLimitCPU", "DefaultLimitFSIZE", … options available in systemd-system.conf(5), and – if not
configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user
services, see below).

For system units these resource limits may be chosen freely. When these settings are configured in a user
service (i.e. a service run by the per-user instance of the service manager) they cannot be used to raise
the limits above those set for the user manager itself when it was first invoked, as the user's service
manager generally lacks the privileges to do so. In user context these configuration options are hence
only useful to lower the limits passed in or to raise the soft limit to the maximum of the hard limit as
configured for the user. To raise the user's limits further, the available configuration mechanisms
differ between operating systems, but typically require privileges. In most cases it is possible to
configure higher per-user resource limits via PAM or by setting limits on the system service
encapsulating the user's service manager, i.e. the user's instance of "user@.service". After making such
changes, make sure to restart the user's service manager. Optional. Type uniline.

LimitFSIZE
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitDATA
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitSTACK
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitCORE
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitRSS
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitNOFILE
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitAS
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitNPROC
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitMEMLOCK
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitLOCKS
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitSIGPENDING
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitMSGQUEUE
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitNICE
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitRTPRIO
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

LimitRTTIME
Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the
process resource limit concept. Process resource limits may be specified in two formats: either as single
value to set a specific soft and hard limit to the same value, or as colon-separated pair "soft:hard" to
set both limits individually (e.g. "LimitAS=4G:16G"). Use the string "infinity" to configure no limit on
a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for
resource limits measured in bytes (e.g. "LimitAS=16G"). For the limits referring to time values, the
usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no
time unit is specified for "LimitCPU" the default unit of seconds is implied, while for "LimitRTTIME" the
default unit of microseconds is implied. Also, note that the effective granularity of the limits might
influence their enforcement. For example, time limits specified for "LimitCPU" will be rounded up
implicitly to multiples of 1s. For "LimitNICE" the value may be specified in two syntaxes: if prefixed
with "+" or "-", the value is understood as regular Linux nice value in the range -20…19. If not prefixed
like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being
equivalent to 1).

UMask
Controls the file mode creation mask. Takes an access mode in octal notation. See umask(2) for details.
Defaults to 0022 for system units. For user units the default value is inherited from the per-user
service manager (whose default is in turn inherited from the system service manager, and thus typically
also is 0022 — unless overridden by a PAM module). In order to change the per-user mask for all user
services, consider setting the "UMask" setting of the user's "user@.service" system service instance. The
per-user umask may also be set via the "umask" field of a user's JSON User Record
<https://systemd.io/USER_RECORD> (for users managed by systemd-homed.service(8) this field may be
controlled via homectl --umask=). It may also be set via a PAM module, such as pam_umask(8). Optional.
Type uniline.

CoredumpFilter
Controls which types of memory mappings will be saved if the process dumps core (using the
"/proc/pid/coredump_filter" file). Takes a whitespace-separated combination of mapping type names or
numbers (with the default base 16). Mapping type names are "private-anonymous", "shared-anonymous",
"private-file-backed", "shared-file-backed", "elf-headers", "private-huge", "shared-huge", "private-dax",
"shared-dax", and the special values "all" (all types) and "default" (the kernel default of
"private-anonymous""shared-anonymous" "elf-headers""private-huge"). See core(5) for the meaning of the
mapping types. When specified multiple times, all specified masks are ORed. When not set, or if the empty
value is assigned, the inherited value is not changed. Optional. Type uniline.

KeyringMode
Controls how the kernel session keyring is set up for the service (see session-keyring(7) for details on
the session keyring). Takes one of "inherit", "private", "shared". If set to "inherit" no special keyring
setup is done, and the kernel's default behaviour is applied. If "private" is used a new session keyring
is allocated when a service process is invoked, and it is not linked up with any user keyring. This is
the recommended setting for system services, as this ensures that multiple services running under the
same system user ID (in particular the root user) do not share their key material among each other. If
"shared" is used a new session keyring is allocated as for "private", but the user keyring of the user
configured with "User" is linked into it, so that keys assigned to the user may be requested by the
unit's processes. In this mode multiple units running processes under the same user ID may share key
material. Unless "inherit" is selected the unique invocation ID for the unit (see below) is added as a
protected key by the name "invocation_id" to the newly created session keyring. Defaults to "private" for
services of the system service manager and to "inherit" for non-service units and for services of the
user service manager. Optional. Type enum. choice: 'inherit', 'private', 'shared'.

OOMScoreAdjust
Sets the adjustment value for the Linux kernel's Out-Of-Memory (OOM) killer score for executed processes.
Takes an integer between -1000 (to disable OOM killing of processes of this unit) and 1000 (to make
killing of processes of this unit under memory pressure very likely). See The /proc Filesystem
<https://docs.kernel.org/filesystems/proc.html> for details. If not specified defaults to the OOM score
adjustment level of the service manager itself, which is normally at 0.

Use the "OOMPolicy" setting of service units to configure how the service manager shall react to the
kernel OOM killer or systemd-oomd terminating a process of the service. See systemd.service(5) for
details. Optional. Type integer.

TimerSlackNSec
Sets the timer slack in nanoseconds for the executed processes. The timer slack controls the accuracy of
wake-ups triggered by timers. See prctl(2) for more information. Note that in contrast to most other time
span definitions this parameter takes an integer value in nano-seconds if no unit is specified. The usual
time units are understood too. Optional. Type uniline.

Personality
Controls which kernel architecture uname(2) shall report, when invoked by unit processes. Takes one of
the architecture identifiers "arm64", "arm64-be", "arm", "arm-be", "x86", "x86-64", "ppc", "ppc-le",
"ppc64", "ppc64-le", "s390" or "s390x". Which personality architectures are supported depends on the
kernel's native architecture. Usually the 64-bit versions of the various system architectures support
their immediate 32-bit personality architecture counterpart, but no others. For example, "x86-64" systems
support the "x86-64" and "x86" personalities but no others. The personality feature is useful when
running 32-bit services on a 64-bit host system. If not specified, the personality is left unmodified and
thus reflects the personality of the host system's kernel. This option is not useful on architectures for
which only one native word width was ever available, such as "m68k" (32-bit only) or "alpha" (64-bit
only). Optional. Type enum. choice: 'arm', 'arm-be', 'arm64', 'arm64-be', 'ppc', 'ppc-le', 'ppc64',
'ppc64-le', 's390', 's390x', 'x86', 'x86-64'.

IgnoreSIGPIPE
Takes a boolean argument. If true, "SIGPIPE" is ignored in the executed process. Defaults to true since
"SIGPIPE" is generally only useful in shell pipelines. Optional. Type boolean.

Nice
Sets the default nice level (scheduling priority) for executed processes. Takes an integer between -20
(highest priority) and 19 (lowest priority). In case of resource contention, smaller values mean more
resources will be made available to the unit's processes, larger values mean less resources will be made
available. See setpriority(2) for details. Optional. Type integer.

CPUSchedulingPolicy
Sets the CPU scheduling policy for executed processes. Takes one of "other", "batch", "idle", "fifo" or
"rr". See sched_setscheduler(2) for details. Optional. Type enum. choice: 'batch', 'fifo', 'idle',
'other', 'rr'.

CPUSchedulingPriority
Sets the CPU scheduling priority for executed processes. The available priority range depends on the
selected CPU scheduling policy (see above). For real-time scheduling policies an integer between 1
(lowest priority) and 99 (highest priority) can be used. In case of CPU resource contention, smaller
values mean less CPU time is made available to the service, larger values mean more. See
sched_setscheduler(2) for details. Optional. Type uniline.

CPUSchedulingResetOnFork
Takes a boolean argument. If true, elevated CPU scheduling priorities and policies will be reset when the
executed processes call fork(2), and can hence not leak into child processes. See sched_setscheduler(2)
for details. Defaults to false. Optional. Type boolean.

CPUAffinity
Controls the CPU affinity of the executed processes. Takes a list of CPU indices or ranges separated by
either whitespace or commas. Alternatively, takes a special "numa" value in which case systemd
automatically derives allowed CPU range based on the value of "NUMAMask" option. CPU ranges are specified
by the lower and upper CPU indices separated by a dash. This option may be specified more than once, in
which case the specified CPU affinity masks are merged. If the empty string is assigned, the mask is
reset, all assignments prior to this will have no effect. See sched_setaffinity(2) for details.
Optional. Type list of uniline.

NUMAPolicy
Controls the NUMA memory policy of the executed processes. Takes a policy type, one of: "default",
"preferred", "bind", "interleave" and "local". A list of NUMA nodes that should be associated with the
policy must be specified in "NUMAMask". For more details on each policy please see, set_mempolicy(2). For
overall overview of NUMA support in Linux see, numa(7). Optional. Type uniline.

NUMAMask
Controls the NUMA node list which will be applied alongside with selected NUMA policy. Takes a list of
NUMA nodes and has the same syntax as a list of CPUs for "CPUAffinity" option or special "all" value
which will include all available NUMA nodes in the mask. Note that the list of NUMA nodes is not required
for "default" and "local" policies and for "preferred" policy we expect a single NUMA node. Optional.
Type uniline.

IOSchedulingClass
Sets the I/O scheduling class for executed processes. Takes one of the strings "realtime", "best-effort"
or "idle". The kernel's default scheduling class is "best-effort" at a priority of 4. If the empty string
is assigned to this option, all prior assignments to both "IOSchedulingClass" and "IOSchedulingPriority"
have no effect. See ioprio_set(2) for details. Optional. Type enum. choice: '0', '1', '2', '3', 'none',
'realtime', 'best-effort', 'idle'.

IOSchedulingPriority
Sets the I/O scheduling priority for executed processes. Takes an integer between 0 (highest priority)
and 7 (lowest priority). In case of I/O contention, smaller values mean more I/O bandwidth is made
available to the unit's processes, larger values mean less bandwidth. The available priorities depend on
the selected I/O scheduling class (see above). If the empty string is assigned to this option, all prior
assignments to both "IOSchedulingClass" and "IOSchedulingPriority" have no effect. For the kernel's
default scheduling class ("best-effort") this defaults to 4. See ioprio_set(2) for details. Optional.
Type integer.

upstream_default value :
4

ProtectSystem
Takes a boolean argument or the special values "full" or "strict". If true, mounts the "/usr/" and the
boot loader directories ("/boot" and "/efi") read-only for processes invoked by this unit. If set to
"full", the "/etc/" directory is mounted read-only, too. If set to "strict" the entire file system
hierarchy is mounted read-only, except for the API file system subtrees "/dev/", "/proc/" and "/sys/"
(protect these directories using "PrivateDevices", "ProtectKernelTunables", "ProtectControlGroups"). This
setting ensures that any modification of the vendor-supplied operating system (and optionally its
configuration, and local mounts) is prohibited for the service. It is recommended to enable this setting
for all long-running services, unless they are involved with system updates or need to modify the
operating system in other ways. If this option is used, "ReadWritePaths" may be used to exclude specific
directories from being made read-only. Similar, "StateDirectory", "LogsDirectory", … and related
directory settings (see below) also exclude the specific directories from the effect of "ProtectSystem".
This setting is implied if "DynamicUser" is set. This setting cannot ensure protection in all cases. In
general it has the same limitations as "ReadOnlyPaths", see below. Defaults to off. Optional. Type enum.
choice: 'full', 'no', 'strict', 'yes'.

ProtectHome
Takes a boolean argument or the special values "read-only" or "tmpfs". If true, the directories "/home/",
"/root", and "/run/user" are made inaccessible and empty for processes invoked by this unit. If set to
"read-only", the three directories are made read-only instead. If set to "tmpfs", temporary file systems
are mounted on the three directories in read-only mode. The value "tmpfs" is useful to hide home
directories not relevant to the processes invoked by the unit, while still allowing necessary directories
to be made visible when listed in "BindPaths" or "BindReadOnlyPaths".

Setting this to "yes" is mostly equivalent to setting the three directories in "InaccessiblePaths".
Similarly, "read-only" is mostly equivalent to "ReadOnlyPaths", and "tmpfs" is mostly equivalent to
"TemporaryFileSystem" with ":ro".

It is recommended to enable this setting for all long-running services (in particular network-facing
ones), to ensure they cannot get access to private user data, unless the services actually require access
to the user's private data. This setting is implied if "DynamicUser" is set. This setting cannot ensure
protection in all cases. In general it has the same limitations as "ReadOnlyPaths", see below. Optional.
Type enum. choice: 'no', 'read-only', 'tmpfs', 'yes'.

RuntimeDirectory
These options take a whitespace-separated list of directory names. The specified directory names must be
relative, and may not include "..". If set, when the unit is started, one or more directories by the
specified names will be created (including their parents) below the locations defined in the following
table. Also, the corresponding environment variable will be defined with the full paths of the
directories. If multiple directories are set, then in the environment variable the paths are concatenated
with colon (":").

In case of "RuntimeDirectory" the innermost subdirectories are removed when the unit is stopped. It is
possible to preserve the specified directories in this case if "RuntimeDirectoryPreserve" is configured
to "restart" or "yes" (see below). The directories specified with "StateDirectory", "CacheDirectory",
"LogsDirectory", "ConfigurationDirectory" are not removed when the unit is stopped.

Except in case of "ConfigurationDirectory", the innermost specified directories will be owned by the user
and group specified in "User" and "Group". If the specified directories already exist and their owning
user or group do not match the configured ones, all files and directories below the specified directories
as well as the directories themselves will have their file ownership recursively changed to match what is
configured. As an optimization, if the specified directories are already owned by the right user and
group, files and directories below of them are left as-is, even if they do not match what is requested.
The innermost specified directories will have their access mode adjusted to the what is specified in
"RuntimeDirectoryMode", "StateDirectoryMode", "CacheDirectoryMode", "LogsDirectoryMode" and
"ConfigurationDirectoryMode".

These options imply "BindPaths" for the specified paths. When combined with "RootDirectory" or
"RootImage" these paths always reside on the host and are mounted from there into the unit's file system
namespace.

If "DynamicUser" is used, the logic for "CacheDirectory", "LogsDirectory" and "StateDirectory" is
slightly altered: the directories are created below "/var/cache/private", "/var/log/private" and
"/var/lib/private", respectively, which are host directories made inaccessible to unprivileged users,
which ensures that access to these directories cannot be gained through dynamic user ID recycling.
Symbolic links are created to hide this difference in behaviour. Both from perspective of the host and
from inside the unit, the relevant directories hence always appear directly below "/var/cache",
"/var/log" and "/var/lib".

Use "RuntimeDirectory" to manage one or more runtime directories for the unit and bind their lifetime to
the daemon runtime. This is particularly useful for unprivileged daemons that cannot create runtime
directories in "/run/" due to lack of privileges, and to make sure the runtime directory is cleaned up
automatically after use. For runtime directories that require more complex or different configuration or
lifetime guarantees, please consider using tmpfiles.d(5).

"RuntimeDirectory", "StateDirectory", "CacheDirectory" and "LogsDirectory" optionally support a second
parameter, separated by ":". The second parameter will be interpreted as a destination path that will be
created as a symlink to the directory. The symlinks will be created after any "BindPaths" or
"TemporaryFileSystem" options have been set up, to make ephemeral symlinking possible. The same source
can have multiple symlinks, by using the same first parameter, but a different second parameter.

The directories defined by these options are always created under the standard paths used by systemd
("/var/", "/run/", "/etc/", …). If the service needs directories in a different location, a different
mechanism has to be used to create them.

tmpfiles.d(5) provides functionality that overlaps with these options. Using these options is
recommended, because the lifetime of the directories is tied directly to the lifetime of the unit, and it
is not necessary to ensure that the "tmpfiles.d" configuration is executed before the unit is started.

To remove any of the directories created by these settings, use the systemctl clean … command on the
relevant units, see systemctl(1) for details.