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

Provided by: libconfig-model-systemd-perl_0.249.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 a service is requested under a certain name but no unit configuration file is found, systemd looks for
a SysV init script by the same name (with the ".service" suffix removed) and dynamically creates a
service unit from that script. This is useful for compatibility with SysV. Note that this compatibility
is quite comprehensive but not 100%. For details about the incompatibilities, see the Incompatibilities
with SysV <https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities> document.

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). Optional. Type boolean.

CPUWeight
Assign the specified CPU time weight to the processes executed, if the unified control group hierarchy is
used on the system. These options take an integer value and control the "cpu.weight" control group
attribute. The allowed range is 1 to 10000. Defaults to 100. For details about this control group
attribute, see Control Groups v2 <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html> and
CFS Scheduler <https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html>. The available
CPU time is split up among all units within one slice relative to their CPU time weight. A higher weight
means more CPU time, a lower weight means less.

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

These settings replace "CPUShares" and "StartupCPUShares". Optional. Type integer.

upstream_default value :
100

StartupCPUWeight
Assign the specified CPU time weight to the processes executed, if the unified control group hierarchy is
used on the system. These options take an integer value and control the "cpu.weight" control group
attribute. The allowed range is 1 to 10000. Defaults to 100. For details about this control group
attribute, see Control Groups v2 <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html> and
CFS Scheduler <https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html>. The available
CPU time is split up among all units within one slice relative to their CPU time weight. A higher weight
means more CPU time, a lower weight means less.

These settings replace "CPUShares" and "StartupCPUShares". Optional. Type integer.

upstream_default value :
100

CPUQuota
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://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html> and sched-bwc.txt
<https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt>.

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

CPUQuotaPeriodSec
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://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html> and CFS Scheduler
<https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html>.

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

AllowedCPUs
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" 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".

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

AllowedMemoryNodes
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" 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".

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

MemoryAccounting
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
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://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-
interface-files>.

This setting is supported only if the unified control group hierarchy is used and disables "MemoryLimit".

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

MemoryHigh
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://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-
interface-files>.

This setting is supported only if the unified control group hierarchy is used and disables "MemoryLimit".
Optional. Type uniline.

MemoryMax
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://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-
files>.

This setting replaces "MemoryLimit". Optional. Type uniline.

MemorySwapMax
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. If assigned the
special value "infinity", no swap limit is applied. This controls the "memory.swap.max" control group
attribute. For details about this control group attribute, see Memory Interface Files
<https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-files>.

This setting is supported only if the unified control group hierarchy is used and disables "MemoryLimit".
Optional. Type uniline.

TasksAccounting
Turn on task accounting for this unit. Takes a boolean argument. If enabled, the system manager will keep
track of the number of tasks in the unit. The number of tasks accounted this way includes both kernel
threads and userspace processes, with each thread counting 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
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, see Process Number
Controller <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/pids.html>.

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

IOAccounting
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).

This setting replaces "BlockIOAccounting" and disables settings prefixed with "BlockIO" or
"StartupBlockIO". Optional. Type boolean.

IOWeight
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://www.kernel.org/doc/html/latest/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" only applies to the startup phase of the system, "IOWeight" applies to the later
runtime of the system, and if the former is not set also to the startup phase. This allows prioritizing
specific services at boot-up differently than during runtime.

These settings replace "BlockIOWeight" and "StartupBlockIOWeight" and disable settings prefixed with
"BlockIO" or "StartupBlockIO". Optional. Type uniline.

StartupIOWeight
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://www.kernel.org/doc/html/latest/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.

These settings replace "BlockIOWeight" and "StartupBlockIOWeight" and disable settings prefixed with
"BlockIO" or "StartupBlockIO". Optional. Type uniline.

IODeviceWeight
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://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#io-interface-files>.

This setting replaces "BlockIODeviceWeight" and disables settings prefixed with "BlockIO" or
"StartupBlockIO".

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
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://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#io-interface-files>.

These settings replace "BlockIOReadBandwidth" and "BlockIOWriteBandwidth" and disable settings prefixed
with "BlockIO" or "StartupBlockIO".

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

IOWriteBandwidthMax
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://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#io-interface-files>.

These settings replace "BlockIOReadBandwidth" and "BlockIOWriteBandwidth" and disable settings prefixed
with "BlockIO" or "StartupBlockIO".

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

IOReadIOPSMax
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://www.kernel.org/doc/html/latest/admin-
guide/cgroup-v2.html#io-interface-files>.

These settings are supported only if the unified control group hierarchy is used and disable settings
prefixed with "BlockIO" or "StartupBlockIO".

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

IOWriteIOPSMax
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://www.kernel.org/doc/html/latest/admin-
guide/cgroup-v2.html#io-interface-files>.

These settings are supported only if the unified control group hierarchy is used and disable settings
prefixed with "BlockIO" or "StartupBlockIO".

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

IODeviceLatencyTargetSec
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://www.kernel.org/doc/html/latest/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 X 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). 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" X 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 usecase.

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:

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

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
Add a custom cgroup BPF program.

"BPFProgram" allows attaching BPF hooks to the cgroup of a systemd unit. (This generalizes the
functionality exposed via "IPEgressFilterPath" for egress and "IPIngressFilterPath" for ingress.)
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
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf.h>. For
general BPF documentation please refer to <https://www.kernel.org/doc/html/latest/bpf/index.html>.

The specification of BPF program consists of a type followed by a program-path with ":" as the separator:
type":"program-path.

type is the string name of BPF attach type also used in bpftool. type can be one of "egress", "ingress",
"sock_create", "sock_ops", "device", "bind4", "bind6", "connect4", "connect6", "post_bind4",
"post_bind6", "sendmsg4", "sendmsg6", "sysctl", "recvmsg4", "recvmsg6", "getsockopt", "setsockopt".

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

Multiple assignments of the same type:program-path value have the same effect as a single assignment: the
program with the path program-path will be attached to cgroup hook type 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.

SocketBindAllow
Allow or deny binding a socket address to a socket by matching it with the bind-rule and applying a
corresponding action if there is a match.

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 1X65535 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 1X65535 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.

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

SocketBindDeny
Allow or deny binding a socket address to a socket by matching it with the bind-rule and applying a
corresponding action if there is a match.

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.

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 node(s) by the unit (mknod), respectively. On cgroup-v1 this controls the
"devices.allow" control group attribute. For details about this control group attribute, see Device
Whitelist Controller <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/devices.html>. In the
unified cgroup hierarchy this functionality is implemented using eBPF filtering.

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:
X
[Unit]
Wants=modprobe@loop.service
After=modprobe@loop.service
[Service]
DeviceAllow=block-loop
DeviceAllow=/dev/loop-control
X 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 above the unit's control group (i.e. towards the root
control group) is owned and managed by the service manager of the host, while the control group tree
below the unit's control group is owned and managed by the unit itself. Takes either a boolean argument
or a list of control group controller names. If true, delegation is turned on, and all supported
controllers are enabled for the unit, making them available to the unit's processes for management. If
false, delegation is turned off entirely (and no additional controllers are enabled). If set to a list of
controllers, delegation is turned on, and the specified controllers are enabled for the unit. Note that
additional controllers than the ones specified might be made available as well, depending on
configuration of the containing slice unit or other units contained in it. Note that assigning the empty
string will enable delegation, but reset the list of controllers, all assignments prior to this will have
no effect. Defaults to false.

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.

For further details on the delegation model consult Control Group APIs and Delegation
<https://systemd.io/CGROUP_DELEGATION>. 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 child units
being able to implicitly or explicitly enable a controller. Defaults to not disabling any controllers.

It may not be possible to successfully disable a controller 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.

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

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

When set to "kill", systemd-oomd will actively monitor this unit's cgroup metrics to decide whether it
needs to act. If the cgroup passes the limits set by oomd.conf(5) or its overrides, systemd-oomd will
send a "SIGKILL" to all of the processes under the chosen candidate cgroup. Note that only descendant
cgroups can be eligible candidates for killing; the unit that set its property to "kill" is not a
candidate (unless one of its ancestors set their property to "kill"). 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 automatically acquire "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
an eligible candidate for systemd-oomd to act on. Optional. Type enum. choice: 'auto', 'kill'.

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

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". Additionally,
systemd-oomd will ignore these extended attributes if the unit's cgroup is not owned by the root user.

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: 'none', 'avoid', 'omit'.

CPUShares
Assign the specified CPU time share weight to the processes executed. These options take an integer value
and control the "cpu.shares" control group attribute. The allowed range is 2 to 262144. Defaults to 1024.
For details about this control group attribute, see CFS Scheduler
<https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html>. The available CPU time is
split up among all units within one slice relative to their CPU time share weight.

While "StartupCPUShares" only applies to the startup phase of the system, "CPUShares" applies to normal
runtime of the system, and if the former is not set also to the startup phase. Using "StartupCPUShares"
allows prioritizing specific services at boot-up differently than during normal runtime.

Implies "CPUAccounting=yes".

These settings are deprecated. Use "CPUWeight" and "StartupCPUWeight" instead. Optional. Type integer.

upstream_default value :
1024

StartupCPUShares
Assign the specified CPU time share weight to the processes executed. These options take an integer value
and control the "cpu.shares" control group attribute. The allowed range is 2 to 262144. Defaults to 1024.
For details about this control group attribute, see CFS Scheduler
<https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html>. The available CPU time is
split up among all units within one slice relative to their CPU time share weight.

Implies "CPUAccounting=yes".

These settings are deprecated. Use "CPUWeight" and "StartupCPUWeight" instead. Optional. Type integer.

upstream_default value :
1024

MemoryLimit
Specify the limit on maximum memory usage of the executed processes. The limit specifies how much process
and kernel memory can be used by tasks in this unit. Takes a memory size in bytes. If the value is
suffixed with K, M, G or T, the specified memory size is parsed as Kilobytes, Megabytes, Gigabytes, or
Terabytes (with the base 1024), respectively. Alternatively, a percentage value may be specified, which
is taken relative to the installed physical memory on the system. If assigned the special value
"infinity", no memory limit is applied. This controls the "memory.limit_in_bytes" control group
attribute. For details about this control group attribute, see Memory Resource Controller
<https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/memory.html>.

Implies "MemoryAccounting=yes".

This setting is deprecated. Use "MemoryMax" instead. Optional. Type uniline.

BlockIOAccounting
Turn on Block I/O accounting for this unit, if the legacy control group hierarchy is used on the system.
Takes a boolean argument. Note that turning on block I/O accounting for one unit will also implicitly
turn it on for all units contained in the same slice and all for its parent slices and the units
contained therein. The system default for this setting may be controlled with "DefaultBlockIOAccounting"
in systemd-system.conf(5).

This setting is deprecated. Use "IOAccounting" instead. Optional. Type boolean.

BlockIOWeight
Set the default overall block I/O weight for the executed processes, if the legacy control group
hierarchy is used on the system. Takes a single weight value (between 10 and 1000) to set the default
block I/O weight. This controls the "blkio.weight" control group attribute, which defaults to 500. For
details about this control group attribute, see Block IO Controller
<https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/blkio-controller.html>. The available I/O
bandwidth is split up among all units within one slice relative to their block I/O weight.

While "StartupBlockIOWeight" only applies to the startup phase of the system, "BlockIOWeight" applies to
the later runtime of the system, and if the former is not set also to the startup phase. This allows
prioritizing specific services at boot-up differently than during runtime.

Implies "BlockIOAccounting=yes".

These settings are deprecated. Use "IOWeight" and "StartupIOWeight" instead. Optional. Type uniline.

StartupBlockIOWeight
Set the default overall block I/O weight for the executed processes, if the legacy control group
hierarchy is used on the system. Takes a single weight value (between 10 and 1000) to set the default
block I/O weight. This controls the "blkio.weight" control group attribute, which defaults to 500. For
details about this control group attribute, see Block IO Controller
<https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/blkio-controller.html>. The available I/O
bandwidth is split up among all units within one slice relative to their block I/O weight.

Implies "BlockIOAccounting=yes".

These settings are deprecated. Use "IOWeight" and "StartupIOWeight" instead. Optional. Type uniline.

BlockIODeviceWeight
Set the per-device overall block I/O weight for the executed processes, if the legacy control group
hierarchy is used on the system. Takes a space-separated pair of a file path and a weight value to
specify the device specific weight value, between 10 and 1000. (Example: "/dev/sda 500"). The file path
may be specified as path to a block device node or as any other file, in which case the backing block
device of the file system of the file is determined. This controls the "blkio.weight_device" control
group attribute, which defaults to 1000. Use this option multiple times to set weights for multiple
devices. For details about this control group attribute, see Block IO Controller
<https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/blkio-controller.html>.

Implies "BlockIOAccounting=yes".

This setting is deprecated. Use "IODeviceWeight" instead. Optional. Type uniline.

BlockIOReadBandwidth
Set the per-device overall block I/O bandwidth limit for the executed processes, if the legacy control
group hierarchy is used on the system. Takes a space-separated pair of a file path and a bandwidth value
(in bytes per second) to specify the device specific bandwidth. The file path may be a path to a block
device node, or as any other file in which case the backing block device of the file system of the file
is used. If the bandwidth is suffixed with K, M, G, or T, the specified bandwidth is parsed as Kilobytes,
Megabytes, Gigabytes, or Terabytes, respectively, to the base of 1000. (Example:
"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This controls the "blkio.throttle.read_bps_device"
and "blkio.throttle.write_bps_device" control group attributes. Use this option multiple times to set
bandwidth limits for multiple devices. For details about these control group attributes, see Block IO
Controller <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/blkio-controller.html>.

Implies "BlockIOAccounting=yes".

These settings are deprecated. Use "IOReadBandwidthMax" and "IOWriteBandwidthMax" instead. Optional.
Type uniline.

BlockIOWriteBandwidth
Set the per-device overall block I/O bandwidth limit for the executed processes, if the legacy control
group hierarchy is used on the system. Takes a space-separated pair of a file path and a bandwidth value
(in bytes per second) to specify the device specific bandwidth. The file path may be a path to a block
device node, or as any other file in which case the backing block device of the file system of the file
is used. If the bandwidth is suffixed with K, M, G, or T, the specified bandwidth is parsed as Kilobytes,
Megabytes, Gigabytes, or Terabytes, respectively, to the base of 1000. (Example:
"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This controls the "blkio.throttle.read_bps_device"
and "blkio.throttle.write_bps_device" control group attributes. Use this option multiple times to set
bandwidth limits for multiple devices. For details about these control group attributes, see Block IO
Controller <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/blkio-controller.html>.

Implies "BlockIOAccounting=yes".

These settings are deprecated. Use "IOReadBandwidthMax" and "IOWriteBandwidthMax" instead. Optional.
Type 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 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
chroot() jail. 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: 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://systemd.io/DISCOVERABLE_PARTITIONS>.

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

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://systemd.io/DISCOVERABLE_PARTITIONS>: "root", "usr", "home", "srv", "esp", "xbootldr", "tmp",
"var". Optional. Type uniline.

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 contains
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://systemd.io/DISCOVERABLE_PARTITIONS>. 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://www.kernel.org/doc/html/latest/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: 'noaccess', 'invisible', 'ptraceable', 'default'.

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://www.kernel.org/doc/html/latest/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.

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.

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

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 X 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 61184X65519. 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. 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.

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 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, but certain settings override this and ignore the value of this setting. This
is the case when "DynamicUser", "LockPersonality", "MemoryDenyWriteExecute", "PrivateDevices",
"ProtectClock", "ProtectHostname", "ProtectKernelLogs", "ProtectKernelModules", "ProtectKernelTunables",
"RestrictAddressFamilies", "RestrictNamespaces", "RestrictRealtime", "RestrictSUIDSGID",
"SystemCallArchitectures", "SystemCallFilter", or "SystemCallLog" are specified. Note that even if this
setting is overridden by them, systemctl show shows the original value of this setting. 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://www.kernel.org/doc/html/latest/userspace-
api/no_new_privs.html>. 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 "-", all errors will be ignored. 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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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".

Resource limits not configured explicitly for a unit default to the value configured in the various
"DefaultLimitCPU", "DefaultLimitFSIZE", X options available in systemd-system.conf(5), and X if not
configured there X 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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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
resource limit concept. 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 -20X19. If not prefixed like this the value is
understood as raw resource limit parameter in the range 0X40 (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 X 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 modes 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 proc.txt
<https://www.kernel.org/doc/Documentation/filesystems/proc.txt> 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 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 "x86", "x86-64", "ppc", "ppc-le", "ppc64", "ppc64-le", "s390" or "s390x".
Which personality architectures are supported depends on the system architecture. Usually the 64bit
versions of the various system architectures support their immediate 32bit 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. Optional. Type enum. choice: 'x86', 'x86-64', 'ppc', 'ppc-le', 'ppc64', 'ppc64-le', 's390',
's390x'.

IgnoreSIGPIPE
Takes a boolean argument. If true, causes "SIGPIPE" to be ignored in the executed process. Defaults to
true because "SIGPIPE" generally is useful only 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: 'other', 'batch', 'idle',
'fifo', '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 an integer between 0 and 3 or one of the
strings "none", "realtime", "best-effort" or "idle". 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. See ioprio_set(2) for
details. Optional. Type integer.

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. 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: 'no', 'yes', 'full', 'strict'.

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 set 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', 'yes', 'read-only', 'tmpfs'.

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

The directories defined by these options are always created under the standard paths used by systemd
("/var/", "/run/", "/etc/", X). 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 X command on the
relevant units, see systemctl(1) for details.