view release on metacpan or  search on metacpan

lib/Config/Model/models/Systemd/Common/Exec.pl  view on Meta::CPAN

L<prctl(2)>.',
      'MemoryTHP' => 'Transparent Hugepages (THPs) is a Linux kernel feature that manages memory
using larger pages (2MB on x86, compared to the default 4KB). The main goal is to improve memory management
efficiency and system performance, especially for memory-intensive applications.
However, it can cause drawbacks in some scenarios, such as memory regression and latency spikes.
THP policy is governed for the entire system via C</sys/kernel/mm/transparent_hugepage/enabled>.
However, it can be overridden for individual workloads via
L<prctl(2)>.
C<MemoryTHP> may be used to disable THPs at process invocation time to stop providing
THPs for workloads where the drawbacks outweigh the advantages.
When C<MemoryTHP> is set to C<inherit> or not set at all, systemd
inherits THP settings from the process that starts it and no
L<prctl(2)>C<PR_SET_THP_DISABLE> call is made.
When set to C<disable>, C<MemoryTHP> disables THPs completely for the process,
irrespecitive of global THP controls.
When set to C<madvise>, C<MemoryTHP> disables THPs for the process except when
specifically requested via L<madvise(2)>
by the process with C<MADV_HUGEPAGE> or C<MADV_COLLAPSE>.
When set to C<system>, C<MemoryTHP> resets the THP policy to system wide policy.
This can be used when the process that starts systemd has already disabled THPs via
C<PR_SET_THP_DISABLE>, and we want to restore the system default THP setting at
process invocation time. For details, see
L<Transparent Hugepage Support|https://docs.kernel.org/admin-guide/mm/transhuge.html>
in the kernel documentation.

Note that this functionality might not be available, for example if THP is disabled in the
kernel, or the kernel does not support controlling THP at the process level through
L<prctl(2)>.',
      'MountAPIVFS' => 'Takes a boolean argument. If on, a private mount namespace for the unit\'s processes is created
and the API file systems C</proc/>, C</sys/>, C</dev/> and
C</run/> (as an empty C<tmpfs>) are mounted inside of it, unless they are
already mounted. Note that this option has no effect unless used in conjunction with
C<RootDirectory>/C<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 C</dev/> file
system of the host is bind mounted if this option is used without C<PrivateDevices>. To run
the service with a private, minimal version of C</dev/>, combine this option with
C<PrivateDevices>.

In order to allow propagating mounts at runtime in a safe manner, C</run/systemd/propagate/>
on the host will be used to set up new mounts, and C</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.',
      'MountFlags' => "Takes a mount propagation setting: C<shared>, C<slave> or
C<private>, which controls whether file system mount points in the file system namespaces set up
for this unit's processes will receive or propagate mounts and unmounts from other file system namespaces. See
L<mount(2)>
for details on mount propagation, and the three propagation flags in particular.

This setting only controls the final propagation setting in effect on all mount
points of the file system namespace created for each process of this unit. Other file system namespacing unit
settings (see the discussion in C<PrivateMounts> above) will implicitly disable mount and
unmount propagation from the unit's processes towards the host by changing the propagation setting of all mount
points in the unit's file system namespace to C<slave> first. Setting this option to
C<shared> does not reestablish propagation in that case.

If not set \x{2013} but file system namespaces are enabled through another file system namespace unit setting \x{2013}
C<shared> mount propagation is used, but \x{2014} as mentioned \x{2014} as C<slave> is applied
first, propagation from the unit's processes to the host is still turned off.

It is not recommended to use C<private> mount propagation for units, as this means
temporary mounts (such as removable media) of the host will stay mounted and thus indefinitely busy in forked
off processes, as unmount propagation events will not be received by the file system namespace of the unit.

Usually, it is best to leave this setting unmodified, and use higher level file system namespacing
options instead, in particular C<PrivateMounts>, see above.",
      'MountImagePolicy' => '*ExtensionImagePolicy',
      'MountImages' => 'This setting is similar to C<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
C<RootImageOptions> setting described above.

Each mount definition may be prefixed with C<->, 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 C<:>, it needs to be escaped as
C<\\:>. The device node or file system image file needs to follow the same rules as
specified for C<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.

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
C<InaccessiblePaths>, or under C</home/> and other protected
directories if C<ProtectHome=yes> is specified.

When C<DevicePolicy> is set to C<closed> or
C<strict>, or set to C<auto> and C<DeviceAllow> is
set, then this setting adds C</dev/loop-control> with C<rw> mode,
C<block-loop> and C<block-blkext> with C<rwm> mode
to C<DeviceAllow>. See
L<systemd.resource-control(5)>
for the details about C<DevicePolicy> or C<DeviceAllow>. Also, see
C<PrivateDevices> below, as it may change the setting of
C<DevicePolicy>.',
      '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 C<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 C<default> and C<local>
policies and for C<preferred> policy we expect a single NUMA node.',
      'NUMAPolicy' => 'Controls the NUMA memory policy of the executed processes. Takes a policy type, one of:
C<default>, C<preferred>, C<bind>, C<interleave> and
C<local>. A list of NUMA nodes that should be associated with the policy must be specified
in C<NUMAMask>. For more details on each policy please see,
L<set_mempolicy(2)>. For overall
overview of NUMA support in Linux see,
L<numa(7)>.
',
      'NetworkNamespacePath' => 'Takes an absolute file system path referring to a Linux network namespace
pseudo-file (i.e. a file like C</proc/$PID/ns/net> or a bind mount or symlink to
one). When set the invoked processes are added to the network namespace referenced by that path. The
path has to point to a valid namespace file at the moment the processes are forked off. If this
option is used C<PrivateNetwork> has no effect. If this option is used together with
C<JoinsNamespaceOf> then it only has an effect if this unit is started before any of