view release on metacpan or  search on metacpan

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

If, in the time interval defined by C<LogRateLimitIntervalSec>, more messages than
specified in C<LogRateLimitBurst> are logged by a service, all further messages
within the interval are dropped until the interval is over. A message about the number of dropped
messages is generated. The time specification for C<LogRateLimitIntervalSec> may be
specified in the following units: \"s\", \"min\", \"h\", \"ms\", \"us\". See
L<systemd.time(7)> for
details. The default settings are set by C<RateLimitIntervalSec> and
C<RateLimitBurst> configured in
L<journald.conf(5)>.
Note that this only applies to log messages that are processed by the logging subsystem, i.e. by
L<systemd-journald.service(8)>.
This means that if you connect a service's stderr directly to a file via
C<StandardOutput=file:\x{2026}> or a similar setting, the rate limiting will not be applied
to messages written that way (but it will be enforced for messages generated via
L<syslog(3)>
and similar functions).",
      'LogRateLimitIntervalSec' => '*LogRateLimitBurst',
      'LogsDirectory' => '*CacheDirectory',
      'LogsDirectoryAccounting' => '*CacheDirectoryAccounting',
      'LogsDirectoryMode' => '*CacheDirectoryMode',
      'LogsDirectoryQuota' => '*CacheDirectoryQuota',
      'MemoryDenyWriteExecute' => 'Takes a boolean argument. If set, attempts to create memory mappings that are writable and
executable at the same time, or to change existing memory mappings to become executable, or mapping shared
memory segments as executable, are prohibited. Specifically, a system call filter is added (or
preferably, an equivalent kernel check is enabled with
L<prctl(2)>) that
rejects L<mmap(2)>
system calls with both C<PROT_EXEC> and C<PROT_WRITE> set,
L<mprotect(2)> or
L<pkey_mprotect(2)> system calls
with C<PROT_EXEC> set and
L<shmat(2)> system calls with
C<SHM_EXEC> set. Note that this option is incompatible with programs and libraries that
generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code
"trampoline" feature of various C compilers. This option improves service security, as it makes harder for
software exploits to change running code dynamically. However, the protection can be circumvented, if
the service can write to a filesystem, which is not mounted with C<noexec> (such as
C</dev/shm>), or it can use memfd_create(). This can be
prevented by making such file systems inaccessible to the service
(e.g. C<InaccessiblePaths=/dev/shm>) and installing further system call filters
(C<SystemCallFilter=~memfd_create>). Note that this feature is fully available on
x86-64, and partially on x86. Specifically, the shmat() protection is not
available on x86. Note that on systems supporting multiple ABIs (such as x86/x86-64) it is
recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the
restrictions of this option. Specifically, it is recommended to combine this option with
C<SystemCallArchitectures=native> or similar.',
      'MemoryKSM' => 'Takes a boolean argument. When set, it enables KSM (kernel samepage merging) for
the processes. KSM is a memory-saving de-duplication feature. Anonymous memory pages with identical
content can be replaced by a single write-protected page. This feature should only be enabled for
jobs that share the same security domain. For details, see
L<Kernel Samepage Merging|https://docs.kernel.org/admin-guide/mm/ksm.html> in the
kernel documentation.

Note that this functionality might not be available, for example if KSM is disabled in the
kernel, or the kernel does not support controlling KSM at the process level through
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',