mirror of
https://github.com/systemd/systemd-stable.git
synced 2024-12-24 21:34:08 +03:00
2740 lines
173 KiB
XML
2740 lines
173 KiB
XML
<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
|
||
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
||
|
||
<!--
|
||
SPDX-License-Identifier: LGPL-2.1+
|
||
|
||
This file is part of systemd.
|
||
|
||
Copyright 2010 Lennart Poettering
|
||
-->
|
||
|
||
<refentry id="systemd.exec">
|
||
<refentryinfo>
|
||
<title>systemd.exec</title>
|
||
<productname>systemd</productname>
|
||
|
||
<authorgroup>
|
||
<author>
|
||
<contrib>Developer</contrib>
|
||
<firstname>Lennart</firstname>
|
||
<surname>Poettering</surname>
|
||
<email>lennart@poettering.net</email>
|
||
</author>
|
||
</authorgroup>
|
||
</refentryinfo>
|
||
|
||
<refmeta>
|
||
<refentrytitle>systemd.exec</refentrytitle>
|
||
<manvolnum>5</manvolnum>
|
||
</refmeta>
|
||
|
||
<refnamediv>
|
||
<refname>systemd.exec</refname>
|
||
<refpurpose>Execution environment configuration</refpurpose>
|
||
</refnamediv>
|
||
|
||
<refsynopsisdiv>
|
||
<para><filename><replaceable>service</replaceable>.service</filename>,
|
||
<filename><replaceable>socket</replaceable>.socket</filename>,
|
||
<filename><replaceable>mount</replaceable>.mount</filename>,
|
||
<filename><replaceable>swap</replaceable>.swap</filename></para>
|
||
</refsynopsisdiv>
|
||
|
||
<refsect1>
|
||
<title>Description</title>
|
||
|
||
<para>Unit configuration files for services, sockets, mount points, and swap devices share a subset of
|
||
configuration options which define the execution environment of spawned processes.</para>
|
||
|
||
<para>This man page lists the configuration options shared by these four unit types. See
|
||
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for the common
|
||
options of all unit configuration files, and
|
||
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>, and
|
||
<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more
|
||
information on the specific unit configuration files. The execution specific configuration options are configured
|
||
in the [Service], [Socket], [Mount], or [Swap] sections, depending on the unit type.</para>
|
||
|
||
<para>In addition, options which control resources through Linux Control Groups (cgroups) are listed in
|
||
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
||
Those options complement options listed here.</para>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>Implicit Dependencies</title>
|
||
|
||
<para>A few execution parameters result in additional, automatic dependencies to be added:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem><para>Units with <varname>WorkingDirectory=</varname>, <varname>RootDirectory=</varname>,
|
||
<varname>RootImage=</varname>, <varname>RuntimeDirectory=</varname>, <varname>StateDirectory=</varname>,
|
||
<varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname> or
|
||
<varname>ConfigurationDirectory=</varname> set automatically gain dependencies of type
|
||
<varname>Requires=</varname> and <varname>After=</varname> on all mount units required to access the specified
|
||
paths. This is equivalent to having them listed explicitly in
|
||
<varname>RequiresMountsFor=</varname>.</para></listitem>
|
||
|
||
<listitem><para>Similar, units with <varname>PrivateTmp=</varname> enabled automatically get mount unit
|
||
dependencies for all mounts required to access <filename>/tmp</filename> and <filename>/var/tmp</filename>. They
|
||
will also gain an automatic <varname>After=</varname> dependency on
|
||
<citerefentry><refentrytitle>systemd-tmpfiles-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para></listitem>
|
||
|
||
<listitem><para>Units whose standard output or error output is connected to <option>journal</option>,
|
||
<option>syslog</option> or <option>kmsg</option> (or their combinations with console output, see below)
|
||
automatically acquire dependencies of type <varname>After=</varname> on
|
||
<filename>systemd-journald.socket</filename>.</para></listitem>
|
||
</itemizedlist>
|
||
</refsect1>
|
||
|
||
<!-- We don't have any default dependency here. -->
|
||
|
||
<refsect1>
|
||
<title>Paths</title>
|
||
|
||
<variablelist class='unit-directives'>
|
||
|
||
<varlistentry>
|
||
<term><varname>WorkingDirectory=</varname></term>
|
||
|
||
<listitem><para>Takes a directory path relative to the service's root directory specified by
|
||
<varname>RootDirectory=</varname>, or the special value <literal>~</literal>. Sets the working directory for
|
||
executed processes. If set to <literal>~</literal>, the home directory of the user specified in
|
||
<varname>User=</varname> 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
|
||
<literal>-</literal> character, a missing working directory is not considered fatal. If
|
||
<varname>RootDirectory=</varname>/<varname>RootImage=</varname> is not set, then
|
||
<varname>WorkingDirectory=</varname> 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).</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>RootDirectory=</varname></term>
|
||
|
||
<listitem><para>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 <citerefentry
|
||
project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system
|
||
call. If this is used, it must be ensured that the process binary and all its auxiliary files are available in
|
||
the <function>chroot()</function> jail. Note that setting this parameter might result in additional
|
||
dependencies to be added to the unit (see above).</para>
|
||
|
||
<para>The <varname>MountAPIVFS=</varname> and <varname>PrivateUsers=</varname> settings are particularly useful
|
||
in conjunction with <varname>RootDirectory=</varname>. For details, see below.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>RootImage=</varname></term>
|
||
|
||
<listitem><para>Takes a path to a block device node or regular file as argument. This call is similar to
|
||
<varname>RootDirectory=</varname> 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 <ulink
|
||
url="https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/">Discoverable Partitions
|
||
Specification</ulink>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>MountAPIVFS=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If on, a private mount namespace for the unit's processes is created
|
||
and the API file systems <filename>/proc</filename>, <filename>/sys</filename>, and <filename>/dev</filename>
|
||
are mounted inside of it, unless they are already mounted. Note that this option has no effect unless used in
|
||
conjunction with <varname>RootDirectory=</varname>/<varname>RootImage=</varname> as these three 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 three mounts. Note that the <filename>/dev</filename> file
|
||
system of the host is bind mounted if this option is used without <varname>PrivateDevices=</varname>. To run
|
||
the service with a private, minimal version of <filename>/dev/</filename>, combine this option with
|
||
<varname>PrivateDevices=</varname>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>BindPaths=</varname></term>
|
||
<term><varname>BindReadOnlyPaths=</varname></term>
|
||
|
||
<listitem><para>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
|
||
<literal>rbind</literal> or <literal>norbind</literal> 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 <literal>-</literal>, in which case it will be ignored
|
||
when its source path does not exist.</para>
|
||
|
||
<para><varname>BindPaths=</varname> creates regular writable bind mounts (unless the source file system mount
|
||
is already marked read-only), while <varname>BindReadOnlyPaths=</varname> 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.</para>
|
||
|
||
<para>This option is particularly useful when <varname>RootDirectory=</varname>/<varname>RootImage=</varname>
|
||
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.</para></listitem>
|
||
</varlistentry>
|
||
|
||
</variablelist>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>Credentials</title>
|
||
|
||
<variablelist class='unit-directives'>
|
||
|
||
<varlistentry>
|
||
<term><varname>User=</varname></term>
|
||
<term><varname>Group=</varname></term>
|
||
|
||
<listitem><para>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
|
||
<command>systemd --user</command>), the default is <literal>root</literal>, but <varname>User=</varname> 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 <literal>+</literal>.</para>
|
||
|
||
<para>Note that restrictions on the user/group name syntax are enforced: the specified name must consist only
|
||
of the characters a-z, A-Z, 0-9, <literal>_</literal> and <literal>-</literal>, except for the first character
|
||
which must be one of a-z, A-Z or <literal>_</literal> (i.e. numbers and <literal>-</literal> are not permitted
|
||
as first character). The user/group name must have at least one character, and at most 31. These restrictions
|
||
are enforced in order to avoid ambiguities and to ensure user/group names and unit files remain portable among
|
||
Linux systems.</para>
|
||
|
||
<para>When used in conjunction with <varname>DynamicUser=</varname> the user/group name specified is
|
||
dynamically allocated at the time the service is started, and released at the time the service is stopped —
|
||
unless it is already allocated statically (see below). If <varname>DynamicUser=</varname> 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
|
||
<citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> facility, which
|
||
is applied at boot or package install time.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>DynamicUser=</varname></term>
|
||
|
||
<listitem><para>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
|
||
<filename>/etc/passwd</filename> or <filename>/etc/group</filename>, but are managed transiently during
|
||
runtime. The <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||
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 <varname>User=</varname> and
|
||
<varname>Group=</varname> (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 <varname>User=</varname> 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
|
||
<varname>Group=</varname> is specified and the static user with the name exists, then it is required that the
|
||
static group with the name already exists. Dynamic users/groups are allocated from the UID/GID range
|
||
61184…65519. It is recommended to avoid this range for regular system or login users. At any point in time
|
||
each UID/GID from this range is only assigned to zero or one dynamically allocated users/groups in
|
||
use. However, UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running
|
||
as part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by these
|
||
users/groups around, as a different unit might get the same UID/GID assigned later on, and thus gain access to
|
||
these files or directories. If <varname>DynamicUser=</varname> is enabled, <varname>RemoveIPC=</varname>,
|
||
<varname>PrivateTmp=</varname> are implied. 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 <filename>/tmp</filename> and <filename>/var/tmp</filename> 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. Moreover <varname>ProtectSystem=strict</varname> and
|
||
<varname>ProtectHome=read-only</varname> 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 whitelisted
|
||
using <varname>ReadWritePaths=</varname>, but care must be taken so that UID/GID recycling doesn't create
|
||
security issues involving files created by the service. Use <varname>RuntimeDirectory=</varname> (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 <varname>StateDirectory=</varname>,
|
||
<varname>CacheDirectory=</varname> and <varname>LogsDirectory=</varname> 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). Defaults to off.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>SupplementaryGroups=</varname></term>
|
||
|
||
<listitem><para>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 <literal>+</literal>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>PAMName=</varname></term>
|
||
|
||
<listitem><para>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
|
||
<varname>User=</varname> setting, and is otherwise ignored. If not set, no PAM session will be opened for the
|
||
executed processes. See <citerefentry
|
||
project='man-pages'><refentrytitle>pam</refentrytitle><manvolnum>8</manvolnum></citerefentry> for
|
||
details.</para>
|
||
|
||
<para>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 <literal>(sd-pam)</literal> and
|
||
is an immediate child process of the unit's main process.</para>
|
||
|
||
<para>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
|
||
<varname>PAMName=</varname> 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 <varname>NotifyAccess=</varname><option>all</option>, 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 <varname>PAMName=</varname> in
|
||
combination with <varname>NotifyAccess=</varname><option>all</option>.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
</variablelist>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>Capabilities</title>
|
||
|
||
<variablelist class='unit-directives'>
|
||
|
||
<varlistentry>
|
||
<term><varname>CapabilityBoundingSet=</varname></term>
|
||
|
||
<listitem><para>Controls which capabilities to include in the capability bounding set for the executed
|
||
process. See <citerefentry
|
||
project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
||
details. Takes a whitespace-separated list of capability names, e.g. <constant>CAP_SYS_ADMIN</constant>,
|
||
<constant>CAP_DAC_OVERRIDE</constant>, <constant>CAP_SYS_PTRACE</constant>. Capabilities listed will be
|
||
included in the bounding set, all others are removed. If the list of capabilities is prefixed with
|
||
<literal>~</literal>, 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 <constant>OR</constant>, or by <constant>AND</constant> if
|
||
the lines are prefixed with <literal>~</literal> (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
|
||
<literal>~</literal> (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
|
||
<literal>+</literal>.</para>
|
||
|
||
<para>Example: if a unit has the following,
|
||
<programlisting>CapabilityBoundingSet=CAP_A CAP_B
|
||
CapabilityBoundingSet=CAP_B CAP_C</programlisting>
|
||
then <constant>CAP_A</constant>, <constant>CAP_B</constant>, and <constant>CAP_C</constant> are set.
|
||
If the second line is prefixed with <literal>~</literal>, e.g.,
|
||
<programlisting>CapabilityBoundingSet=CAP_A CAP_B
|
||
CapabilityBoundingSet=~CAP_B CAP_C</programlisting>
|
||
then, only <constant>CAP_A</constant> is set.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>AmbientCapabilities=</varname></term>
|
||
|
||
<listitem><para>Controls which capabilities to include in the ambient capability set for the executed
|
||
process. Takes a whitespace-separated list of capability names, e.g. <constant>CAP_SYS_ADMIN</constant>,
|
||
<constant>CAP_DAC_OVERRIDE</constant>, <constant>CAP_SYS_PTRACE</constant>. This option may appear more than
|
||
once in which case the ambient capability sets are merged (see the above examples in
|
||
<varname>CapabilityBoundingSet=</varname>). If the list of capabilities is prefixed with <literal>~</literal>,
|
||
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 <literal>~</literal> (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. </para><para>
|
||
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 <constant>keep-caps</constant> is automatically added
|
||
to <varname>SecureBits=</varname> to retain the capabilities over the user
|
||
change. <varname>AmbientCapabilities=</varname> does not affect commands prefixed with
|
||
<literal>+</literal>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
</variablelist>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>Security</title>
|
||
|
||
<variablelist class='unit-directives'>
|
||
|
||
<varlistentry>
|
||
<term><varname>NoNewPrivileges=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If true, ensures that the service process and all its children can
|
||
never gain new privileges through <function>execve()</function> (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 <varname>SystemCallFilter=</varname>,
|
||
<varname>SystemCallArchitectures=</varname>, <varname>RestrictAddressFamilies=</varname>,
|
||
<varname>RestrictNamespaces=</varname>, <varname>PrivateDevices=</varname>,
|
||
<varname>ProtectKernelTunables=</varname>, <varname>ProtectKernelModules=</varname>,
|
||
<varname>MemoryDenyWriteExecute=</varname>, <varname>RestrictRealtime=</varname>, or
|
||
<varname>LockPersonality=</varname> are specified. Note that even if this setting is overridden by them,
|
||
<command>systemctl show</command> shows the original value of this setting. Also see
|
||
<ulink url="https://www.kernel.org/doc/html/latest/userspace-api/no_new_privs.html">No New Privileges
|
||
Flag</ulink>. </para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>SecureBits=</varname></term>
|
||
|
||
<listitem><para>Controls the secure bits set for the executed process. Takes a space-separated combination of
|
||
options from the following list: <option>keep-caps</option>, <option>keep-caps-locked</option>,
|
||
<option>no-setuid-fixup</option>, <option>no-setuid-fixup-locked</option>, <option>noroot</option>, and
|
||
<option>noroot-locked</option>. 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 <literal>+</literal>. See <citerefentry
|
||
project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
||
details.</para></listitem>
|
||
</varlistentry>
|
||
|
||
</variablelist>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>Mandatory Access Control</title>
|
||
<variablelist>
|
||
|
||
<varlistentry>
|
||
<term><varname>SELinuxContext=</varname></term>
|
||
|
||
<listitem><para>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 <literal>-</literal>, all errors will be ignored. This does not
|
||
affect commands prefixed with <literal>+</literal>. See <citerefentry
|
||
project='die-net'><refentrytitle>setexeccon</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
|
||
details.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>AppArmorProfile=</varname></term>
|
||
|
||
<listitem><para>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. This result in a non
|
||
operation if AppArmor is not enabled. If prefixed by <literal>-</literal>, all errors will be ignored. This
|
||
does not affect commands prefixed with <literal>+</literal>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>SmackProcessLabel=</varname></term>
|
||
|
||
<listitem><para>Takes a <option>SMACK64</option> 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
|
||
<option>SMACK64EXEC</option> 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.</para>
|
||
|
||
<para>The value may be prefixed by <literal>-</literal>, 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
|
||
<literal>+</literal>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
</variablelist>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>Process Properties</title>
|
||
|
||
<variablelist>
|
||
|
||
<varlistentry>
|
||
<term><varname>LimitCPU=</varname></term>
|
||
<term><varname>LimitFSIZE=</varname></term>
|
||
<term><varname>LimitDATA=</varname></term>
|
||
<term><varname>LimitSTACK=</varname></term>
|
||
<term><varname>LimitCORE=</varname></term>
|
||
<term><varname>LimitRSS=</varname></term>
|
||
<term><varname>LimitNOFILE=</varname></term>
|
||
<term><varname>LimitAS=</varname></term>
|
||
<term><varname>LimitNPROC=</varname></term>
|
||
<term><varname>LimitMEMLOCK=</varname></term>
|
||
<term><varname>LimitLOCKS=</varname></term>
|
||
<term><varname>LimitSIGPENDING=</varname></term>
|
||
<term><varname>LimitMSGQUEUE=</varname></term>
|
||
<term><varname>LimitNICE=</varname></term>
|
||
<term><varname>LimitRTPRIO=</varname></term>
|
||
<term><varname>LimitRTTIME=</varname></term>
|
||
|
||
<listitem><para>Set soft and hard limits on various resources for executed processes. See
|
||
<citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry> 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 <option>soft:hard</option> to set
|
||
both limits individually (e.g. <literal>LimitAS=4G:16G</literal>). Use the string <option>infinity</option> 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
|
||
<citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
||
details). Note that if no time unit is specified for <varname>LimitCPU=</varname> the default unit of seconds
|
||
is implied, while for <varname>LimitRTTIME=</varname> 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 <varname>LimitCPU=</varname> will be rounded up implicitly to multiples of 1s. For
|
||
<varname>LimitNICE=</varname> the value may be specified in two syntaxes: if prefixed with <literal>+</literal>
|
||
or <literal>-</literal>, the value is understood as regular Linux nice value in the range -20..19. If not
|
||
prefixed like this the value is understood as raw resource limit parameter in the range 0..40 (with 0 being
|
||
equivalent to 1).</para>
|
||
|
||
<para>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 <varname>LimitRSS=</varname> is not implemented on Linux, and
|
||
setting it has no effect. Often it is advisable to prefer the resource controls listed in
|
||
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||
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, <varname>MemoryLimit=</varname> is a more powerful (and working)
|
||
replacement for <varname>LimitRSS=</varname>.</para>
|
||
|
||
<para>For system units these resource limits may be chosen freely. For user units however (i.e. units run by a
|
||
per-user instance of
|
||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>), these limits are
|
||
bound by (possibly more restrictive) per-user limits enforced by the OS.</para>
|
||
|
||
<para>Resource limits not configured explicitly for a unit default to the value configured in the various
|
||
<varname>DefaultLimitCPU=</varname>, <varname>DefaultLimitFSIZE=</varname>, … options available in
|
||
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, and –
|
||
if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user
|
||
services, see above).</para>
|
||
|
||
<table>
|
||
<title>Resource limit directives, their equivalent <command>ulimit</command> shell commands and the unit used</title>
|
||
|
||
<tgroup cols='3'>
|
||
<colspec colname='directive' />
|
||
<colspec colname='equivalent' />
|
||
<colspec colname='unit' />
|
||
<thead>
|
||
<row>
|
||
<entry>Directive</entry>
|
||
<entry><command>ulimit</command> equivalent</entry>
|
||
<entry>Unit</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry>LimitCPU=</entry>
|
||
<entry>ulimit -t</entry>
|
||
<entry>Seconds</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitFSIZE=</entry>
|
||
<entry>ulimit -f</entry>
|
||
<entry>Bytes</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitDATA=</entry>
|
||
<entry>ulimit -d</entry>
|
||
<entry>Bytes</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitSTACK=</entry>
|
||
<entry>ulimit -s</entry>
|
||
<entry>Bytes</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitCORE=</entry>
|
||
<entry>ulimit -c</entry>
|
||
<entry>Bytes</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitRSS=</entry>
|
||
<entry>ulimit -m</entry>
|
||
<entry>Bytes</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitNOFILE=</entry>
|
||
<entry>ulimit -n</entry>
|
||
<entry>Number of File Descriptors</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitAS=</entry>
|
||
<entry>ulimit -v</entry>
|
||
<entry>Bytes</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitNPROC=</entry>
|
||
<entry>ulimit -u</entry>
|
||
<entry>Number of Processes</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitMEMLOCK=</entry>
|
||
<entry>ulimit -l</entry>
|
||
<entry>Bytes</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitLOCKS=</entry>
|
||
<entry>ulimit -x</entry>
|
||
<entry>Number of Locks</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitSIGPENDING=</entry>
|
||
<entry>ulimit -i</entry>
|
||
<entry>Number of Queued Signals</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitMSGQUEUE=</entry>
|
||
<entry>ulimit -q</entry>
|
||
<entry>Bytes</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitNICE=</entry>
|
||
<entry>ulimit -e</entry>
|
||
<entry>Nice Level</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitRTPRIO=</entry>
|
||
<entry>ulimit -r</entry>
|
||
<entry>Realtime Priority</entry>
|
||
</row>
|
||
<row>
|
||
<entry>LimitRTTIME=</entry>
|
||
<entry>No equivalent</entry>
|
||
<entry>Microseconds</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>UMask=</varname></term>
|
||
|
||
<listitem><para>Controls the file mode creation mask. Takes an access mode in octal notation. See
|
||
<citerefentry><refentrytitle>umask</refentrytitle><manvolnum>2</manvolnum></citerefentry> for details. Defaults
|
||
to 0022.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>KeyringMode=</varname></term>
|
||
|
||
<listitem><para>Controls how the kernel session keyring is set up for the service (see <citerefentry
|
||
project='man-pages'><refentrytitle>session-keyring</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
||
details on the session keyring). Takes one of <option>inherit</option>, <option>private</option>,
|
||
<option>shared</option>. If set to <option>inherit</option> no special keyring setup is done, and the kernel's
|
||
default behaviour is applied. If <option>private</option> 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 <option>shared</option> is used a new
|
||
session keyring is allocated as for <option>private</option>, but the user keyring of the user configured with
|
||
<varname>User=</varname> 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
|
||
<option>inherit</option> is selected the unique invocation ID for the unit (see below) is added as a protected
|
||
key by the name <literal>invocation_id</literal> to the newly created session keyring. Defaults to
|
||
<option>private</option> for services of the system service manager and to <option>inherit</option> for
|
||
non-service units and for services of the user service manager.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>OOMScoreAdjust=</varname></term>
|
||
|
||
<listitem><para>Sets the adjustment level for the Out-Of-Memory killer for executed processes. Takes an integer
|
||
between -1000 (to disable OOM killing for this process) and 1000 (to make killing of this process under memory
|
||
pressure very likely). See <ulink
|
||
url="https://www.kernel.org/doc/Documentation/filesystems/proc.txt">proc.txt</ulink> for
|
||
details.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>TimerSlackNSec=</varname></term>
|
||
<listitem><para>Sets the timer slack in nanoseconds for the executed processes. The timer slack controls the
|
||
accuracy of wake-ups triggered by timers. See
|
||
<citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> 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.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>Personality=</varname></term>
|
||
|
||
<listitem><para>Controls which kernel architecture <citerefentry
|
||
project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry> shall report,
|
||
when invoked by unit processes. Takes one of the architecture identifiers <constant>x86</constant>,
|
||
<constant>x86-64</constant>, <constant>ppc</constant>, <constant>ppc-le</constant>, <constant>ppc64</constant>,
|
||
<constant>ppc64-le</constant>, <constant>s390</constant> or <constant>s390x</constant>. 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, <constant>x86-64</constant> systems support the <constant>x86-64</constant> and
|
||
<constant>x86</constant> 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.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>IgnoreSIGPIPE=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If true, causes <constant>SIGPIPE</constant> to be ignored in the
|
||
executed process. Defaults to true because <constant>SIGPIPE</constant> generally is useful only in shell
|
||
pipelines.</para></listitem>
|
||
</varlistentry>
|
||
|
||
</variablelist>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>Scheduling</title>
|
||
|
||
<variablelist>
|
||
|
||
<varlistentry>
|
||
<term><varname>Nice=</varname></term>
|
||
|
||
<listitem><para>Sets the default nice level (scheduling priority) for executed processes. Takes an integer
|
||
between -20 (highest priority) and 19 (lowest priority). See
|
||
<citerefentry><refentrytitle>setpriority</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
|
||
details.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>CPUSchedulingPolicy=</varname></term>
|
||
|
||
<listitem><para>Sets the CPU scheduling policy for executed processes. Takes one of <option>other</option>,
|
||
<option>batch</option>, <option>idle</option>, <option>fifo</option> or <option>rr</option>. See
|
||
<citerefentry><refentrytitle>sched_setscheduler</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
|
||
details.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>CPUSchedulingPriority=</varname></term>
|
||
|
||
<listitem><para>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. See
|
||
<citerefentry><refentrytitle>sched_setscheduler</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
|
||
details. </para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>CPUSchedulingResetOnFork=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If true, elevated CPU scheduling priorities and policies will be
|
||
reset when the executed processes fork, and can hence not leak into child processes. See
|
||
<citerefentry><refentrytitle>sched_setscheduler</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
|
||
details. Defaults to false.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>CPUAffinity=</varname></term>
|
||
|
||
<listitem><para>Controls the CPU affinity of the executed processes. 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. 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
|
||
<citerefentry><refentrytitle>sched_setaffinity</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
|
||
details.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>IOSchedulingClass=</varname></term>
|
||
|
||
<listitem><para>Sets the I/O scheduling class for executed processes. Takes an integer between 0 and 3 or one
|
||
of the strings <option>none</option>, <option>realtime</option>, <option>best-effort</option> or
|
||
<option>idle</option>. If the empty string is assigned to this option, all prior assignments to both
|
||
<varname>IOSchedulingClass=</varname> and <varname>IOSchedulingPriority=</varname> have no effect. See
|
||
<citerefentry><refentrytitle>ioprio_set</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
|
||
details.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>IOSchedulingPriority=</varname></term>
|
||
|
||
<listitem><para>Sets the I/O scheduling priority for executed processes. Takes an integer between 0 (highest
|
||
priority) and 7 (lowest priority). 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
|
||
<varname>IOSchedulingClass=</varname> and <varname>IOSchedulingPriority=</varname> have no effect.
|
||
See <citerefentry><refentrytitle>ioprio_set</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
|
||
details.</para></listitem>
|
||
</varlistentry>
|
||
|
||
</variablelist>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>Sandboxing</title>
|
||
|
||
<variablelist>
|
||
|
||
<varlistentry>
|
||
<term><varname>ProtectSystem=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument or the special values <literal>full</literal> or
|
||
<literal>strict</literal>. If true, mounts the <filename>/usr</filename> and <filename>/boot</filename>
|
||
directories read-only for processes invoked by this unit. If set to <literal>full</literal>, the
|
||
<filename>/etc</filename> directory is mounted read-only, too. If set to <literal>strict</literal> the entire
|
||
file system hierarchy is mounted read-only, except for the API file system subtrees <filename>/dev</filename>,
|
||
<filename>/proc</filename> and <filename>/sys</filename> (protect these directories using
|
||
<varname>PrivateDevices=</varname>, <varname>ProtectKernelTunables=</varname>,
|
||
<varname>ProtectControlGroups=</varname>). 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,
|
||
<varname>ReadWritePaths=</varname> may be used to exclude specific directories from being made read-only. This
|
||
setting is implied if <varname>DynamicUser=</varname> is set. For this setting the same restrictions regarding
|
||
mount propagation and privileges apply as for <varname>ReadOnlyPaths=</varname> and related calls, see
|
||
below. Defaults to off.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>ProtectHome=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument or the special values <literal>read-only</literal> or
|
||
<literal>tmpfs</literal>. If true, the directories <filename>/home</filename>, <filename>/root</filename> and
|
||
<filename>/run/user</filename> are made inaccessible and empty for processes invoked by this unit. If set to
|
||
<literal>read-only</literal>, the three directories are made read-only instead. If set to <literal>tmpfs</literal>,
|
||
temporary file systems are mounted on the three directories in read-only mode. The value <literal>tmpfs</literal>
|
||
is useful to hide home directories not relevant to the processes invoked by the unit, while necessary directories
|
||
are still visible by combining with <varname>BindPaths=</varname> or <varname>BindReadOnlyPaths=</varname>.</para>
|
||
|
||
<para>Setting this to <literal>yes</literal> is mostly equivalent to set the three directories in
|
||
<varname>InaccessiblePaths=</varname>. Similary, <literal>read-only</literal> is mostly equivalent to
|
||
<varname>ReadOnlyPaths=</varname>, and <literal>tmpfs</literal> is mostly equivalent to
|
||
<varname>TemporaryFileSystem=</varname>.</para>
|
||
|
||
<para> 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 <varname>DynamicUser=</varname> is set. For this setting the same
|
||
restrictions regarding mount propagation and privileges apply as for <varname>ReadOnlyPaths=</varname> and related
|
||
calls, see below.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>RuntimeDirectory=</varname></term>
|
||
<term><varname>StateDirectory=</varname></term>
|
||
<term><varname>CacheDirectory=</varname></term>
|
||
<term><varname>LogsDirectory=</varname></term>
|
||
<term><varname>ConfigurationDirectory=</varname></term>
|
||
|
||
<listitem><para>These options take a whitespace-separated list of directory names. The specified directory
|
||
names must be relative, and may not include <literal>.</literal> or <literal>..</literal>. If set, one or more
|
||
directories by the specified names will be created (including their parents) below <filename>/run</filename>
|
||
(or <varname>$XDG_RUNTIME_DIR</varname> for user services), <filename>/var/lib</filename> (or
|
||
<varname>$XDG_CONFIG_HOME</varname> for user services), <filename>/var/cache</filename> (or
|
||
<varname>$XDG_CACHE_HOME</varname> for user services), <filename>/var/log</filename> (or
|
||
<varname>$XDG_CONFIG_HOME</varname><filename>/log</filename> for user services), or <filename>/etc</filename>
|
||
(or <varname>$XDG_CONFIG_HOME</varname> for user services), respectively, when the unit is started.</para>
|
||
|
||
<para>In case of <varname>RuntimeDirectory=</varname> the lowest subdirectories are removed when the unit is
|
||
stopped. It is possible to preserve the specified directories in this case if
|
||
<varname>RuntimeDirectoryPreserve=</varname> is configured to <option>restart</option> or <option>yes</option>
|
||
(see below). The directories specified with <varname>StateDirectory=</varname>,
|
||
<varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname>,
|
||
<varname>ConfigurationDirectory=</varname> are not removed when the unit is stopped.</para>
|
||
|
||
<para>Except in case of <varname>ConfigurationDirectory=</varname>, the innermost specified directories will be
|
||
owned by the user and group specified in <varname>User=</varname> and <varname>Group=</varname>. 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 <varname>RuntimeDirectoryMode=</varname>, <varname>StateDirectoryMode=</varname>,
|
||
<varname>CacheDirectoryMode=</varname>, <varname>LogsDirectoryMode=</varname> and
|
||
<varname>ConfigurationDirectoryMode=</varname>.</para>
|
||
|
||
<para>These options imply <varname>BindPaths=</varname> for the specified paths. When combined with
|
||
<varname>RootDirectory=</varname> or <varname>RootImage=</varname> these paths always reside on the host and
|
||
are mounted from there into the unit's file system namespace.</para>
|
||
|
||
<para>If <varname>DynamicUser=</varname> is used in conjunction with <varname>StateDirectory=</varname>,
|
||
<varname>CacheDirectory=</varname> and <varname>LogsDirectory=</varname> is slightly altered: the directories
|
||
are created below <filename>/var/lib/private</filename>, <filename>/var/cache/private</filename> and
|
||
<filename>/var/log/private</filename>, 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
|
||
<filename>/var/lib</filename>, <filename>/var/cache</filename> and <filename>/var/log</filename>.</para>
|
||
|
||
<para>Use <varname>RuntimeDirectory=</varname> 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 <filename>/run</filename> 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
|
||
<citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
|
||
|
||
<para>Example: if a system service unit has the following,
|
||
<programlisting>RuntimeDirectory=foo/bar baz</programlisting>
|
||
the service manager creates <filename>/run/foo</filename> (if it does not exist),
|
||
<filename>/run/foo/bar</filename>, and <filename>/run/baz</filename>. The directories
|
||
<filename>/run/foo/bar</filename> and <filename>/run/baz</filename> except <filename>/run/foo</filename> are
|
||
owned by the user and group specified in <varname>User=</varname> and <varname>Group=</varname>, and removed
|
||
when the service is stopped.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>RuntimeDirectoryMode=</varname></term>
|
||
<term><varname>StateDirectoryMode=</varname></term>
|
||
<term><varname>CacheDirectoryMode=</varname></term>
|
||
<term><varname>LogsDirectoryMode=</varname></term>
|
||
<term><varname>ConfigurationDirectoryMode=</varname></term>
|
||
|
||
<listitem><para>Specifies the access mode of the directories specified in <varname>RuntimeDirectory=</varname>,
|
||
<varname>StateDirectory=</varname>, <varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname>, or
|
||
<varname>ConfigurationDirectory=</varname>, respectively, as an octal number. Defaults to
|
||
<constant>0755</constant>. See "Permissions" in <citerefentry
|
||
project='man-pages'><refentrytitle>path_resolution</refentrytitle><manvolnum>7</manvolnum></citerefentry> for a
|
||
discussion of the meaning of permission bits.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>RuntimeDirectoryPreserve=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument or <option>restart</option>. If set to <option>no</option> (the
|
||
default), the directories specified in <varname>RuntimeDirectory=</varname> are always removed when the service
|
||
stops. If set to <option>restart</option> the directories are preserved when the service is both automatically
|
||
and manually restarted. Here, the automatic restart means the operation specified in
|
||
<varname>Restart=</varname>, and manual restart means the one triggered by <command>systemctl restart
|
||
foo.service</command>. If set to <option>yes</option>, then the directories are not removed when the service is
|
||
stopped. Note that since the runtime directory <filename>/run</filename> is a mount point of
|
||
<literal>tmpfs</literal>, then for system services the directories specified in
|
||
<varname>RuntimeDirectory=</varname> are removed when the system is rebooted.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>ReadWritePaths=</varname></term>
|
||
<term><varname>ReadOnlyPaths=</varname></term>
|
||
<term><varname>InaccessiblePaths=</varname></term>
|
||
|
||
<listitem><para>Sets up a new file system namespace for executed processes. These options may be used to limit
|
||
access a process might have to the file system hierarchy. Each setting takes a space-separated list of paths
|
||
relative to the host's root directory (i.e. the system running the service manager). Note that if paths
|
||
contain symlinks, they are resolved relative to the root directory set with
|
||
<varname>RootDirectory=</varname>/<varname>RootImage=</varname>.</para>
|
||
|
||
<para>Paths listed in <varname>ReadWritePaths=</varname> are accessible from within the namespace with the same
|
||
access modes as from outside of it. Paths listed in <varname>ReadOnlyPaths=</varname> are accessible for
|
||
reading only, writing will be refused even if the usual file access controls would permit this. Nest
|
||
<varname>ReadWritePaths=</varname> inside of <varname>ReadOnlyPaths=</varname> in order to provide writable
|
||
subdirectories within read-only directories. Use <varname>ReadWritePaths=</varname> in order to whitelist
|
||
specific paths for write access if <varname>ProtectSystem=strict</varname> is used.</para>
|
||
|
||
<para>Paths listed in <varname>InaccessiblePaths=</varname> will be made inaccessible for processes inside
|
||
the namespace along with everything below them in the file system hierarchy. This may be more restrictive than
|
||
desired, because it is not possible to nest <varname>ReadWritePaths=</varname>, <varname>ReadOnlyPaths=</varname>,
|
||
<varname>BindPaths=</varname>, or <varname>BindReadOnlyPaths=</varname> inside it. For a more flexible option,
|
||
see <varname>TemporaryFileSystem=</varname>.</para>
|
||
|
||
<para>Note that restricting access with these options does not extend to submounts of a directory that are
|
||
created later on. Non-directory paths may be specified as well. These options may be specified more than once,
|
||
in which case all paths listed will have limited access from within the namespace. If the empty string is
|
||
assigned to this option, the specific list is reset, and all prior assignments have no effect.</para>
|
||
|
||
<para>Paths in <varname>ReadWritePaths=</varname>, <varname>ReadOnlyPaths=</varname> and
|
||
<varname>InaccessiblePaths=</varname> may be prefixed with <literal>-</literal>, in which case they will be
|
||
ignored when they do not exist. If prefixed with <literal>+</literal> the paths are taken relative to the root
|
||
directory of the unit, as configured with <varname>RootDirectory=</varname>/<varname>RootImage=</varname>,
|
||
instead of relative to the root directory of the host (see above). When combining <literal>-</literal> and
|
||
<literal>+</literal> on the same path make sure to specify <literal>-</literal> first, and <literal>+</literal>
|
||
second.</para>
|
||
|
||
<para>Note that using this setting will disconnect propagation of mounts from the service to the host
|
||
(propagation in the opposite direction continues to work). This means that this setting may not be used for
|
||
services which shall be able to install mount points in the main mount namespace. Note that the effect of these
|
||
settings may be undone by privileged processes. In order to set up an effective sandboxed environment for a
|
||
unit it is thus recommended to combine these settings with either
|
||
<varname>CapabilityBoundingSet=~CAP_SYS_ADMIN</varname> or
|
||
<varname>SystemCallFilter=~@mount</varname>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>TemporaryFileSystem=</varname></term>
|
||
|
||
<listitem><para>Takes a space-separated list of mount points for temporary file systems (tmpfs). If set, a new file
|
||
system namespace is set up for executed processes, and a temporary file system is mounted on each mount point.
|
||
This option may be specified more than once, in which case temporary file systems are mounted on all listed mount
|
||
points. If the empty string is assigned to this option, the list is reset, and all prior assignments have no effect.
|
||
Each mount point may optionally be suffixed with a colon (<literal>:</literal>) and mount options such as
|
||
<literal>size=10%</literal> or <literal>ro</literal>. By default, each temporary file system is mounted
|
||
with <literal>nodev,strictatime,mode=0755</literal>. These can be disabled by explicitly specifying the corresponding
|
||
mount options, e.g., <literal>dev</literal> or <literal>nostrictatime</literal>.</para>
|
||
|
||
<para>This is useful to hide files or directories not relevant to the processes invoked by the unit, while necessary
|
||
files or directories can be still accessed by combining with <varname>BindPaths=</varname> or
|
||
<varname>BindReadOnlyPaths=</varname>. See the example below.</para>
|
||
|
||
<para>Example: if a unit has the following,
|
||
<programlisting>TemporaryFileSystem=/var:ro
|
||
BindReadOnlyPaths=/var/lib/systemd</programlisting>
|
||
then the invoked processes by the unit cannot see any files or directories under <filename>/var</filename> except for
|
||
<filename>/var/lib/systemd</filename> or its contents.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>PrivateTmp=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If true, sets up a new file system namespace for the executed
|
||
processes and mounts private <filename>/tmp</filename> and <filename>/var/tmp</filename> directories inside it
|
||
that is not shared by processes outside of the namespace. This is useful to secure access to temporary files of
|
||
the process, but makes sharing between processes via <filename>/tmp</filename> or <filename>/var/tmp</filename>
|
||
impossible. If this is enabled, all temporary files created by a service in these directories will be removed
|
||
after the service is stopped. Defaults to false. It is possible to run two or more units within the same
|
||
private <filename>/tmp</filename> and <filename>/var/tmp</filename> namespace by using the
|
||
<varname>JoinsNamespaceOf=</varname> directive, see
|
||
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
|
||
details. This setting is implied if <varname>DynamicUser=</varname> is set. For this setting the same
|
||
restrictions regarding mount propagation and privileges apply as for <varname>ReadOnlyPaths=</varname> and
|
||
related calls, see above. Enabling this setting has the side effect of adding <varname>Requires=</varname> and
|
||
<varname>After=</varname> dependencies on all mount units necessary to access <filename>/tmp</filename> and
|
||
<filename>/var/tmp</filename>. Moreover an implicitly <varname>After=</varname> ordering on
|
||
<citerefentry><refentrytitle>systemd-tmpfiles-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||
is added.</para>
|
||
|
||
<para>Note that the implementation of this setting might be impossible (for example if mount namespaces are not
|
||
available), and the unit should be written in a way that does not solely rely on this setting for
|
||
security.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>PrivateDevices=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If true, sets up a new <filename>/dev</filename> mount for the
|
||
executed processes and only adds API pseudo devices such as <filename>/dev/null</filename>,
|
||
<filename>/dev/zero</filename> or <filename>/dev/random</filename> (as well as the pseudo TTY subsystem) to it,
|
||
but no physical devices such as <filename>/dev/sda</filename>, system memory <filename>/dev/mem</filename>,
|
||
system ports <filename>/dev/port</filename> and others. This is useful to securely turn off physical device
|
||
access by the executed process. Defaults to false. Enabling this option will install a system call filter to
|
||
block low-level I/O system calls that are grouped in the <varname>@raw-io</varname> set, will also remove
|
||
<constant>CAP_MKNOD</constant> and <constant>CAP_SYS_RAWIO</constant> from the capability bounding set for the
|
||
unit (see above), and set <varname>DevicePolicy=closed</varname> (see
|
||
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||
for details). Note that using this setting will disconnect propagation of mounts from the service to the host
|
||
(propagation in the opposite direction continues to work). This means that this setting may not be used for
|
||
services which shall be able to install mount points in the main mount namespace. The new
|
||
<filename>/dev</filename> will be mounted read-only and 'noexec'. The latter may break old programs which try
|
||
to set up executable memory by using
|
||
<citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> of
|
||
<filename>/dev/zero</filename> instead of using <constant>MAP_ANON</constant>. For this setting the same
|
||
restrictions regarding mount propagation and privileges apply as for <varname>ReadOnlyPaths=</varname> and
|
||
related calls, see above. If turned on and if running in user mode, or in system mode, but without the
|
||
<constant>CAP_SYS_ADMIN</constant> capability (e.g. setting <varname>User=</varname>),
|
||
<varname>NoNewPrivileges=yes</varname> is implied.</para>
|
||
|
||
<para>Note that the implementation of this setting might be impossible (for example if mount namespaces are not
|
||
available), and the unit should be written in a way that does not solely rely on this setting for
|
||
security.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>PrivateNetwork=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If true, sets up a new network namespace for the executed processes
|
||
and configures only the loopback network device <literal>lo</literal> inside it. No other network devices will
|
||
be available to the executed process. This is useful to turn off network access by the executed process.
|
||
Defaults to false. It is possible to run two or more units within the same private network namespace by using
|
||
the <varname>JoinsNamespaceOf=</varname> directive, see
|
||
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
|
||
details. Note that this option will disconnect all socket families from the host, this includes AF_NETLINK and
|
||
AF_UNIX. The latter has the effect that AF_UNIX sockets in the abstract socket namespace will become
|
||
unavailable to the processes (however, those located in the file system will continue to be accessible).</para>
|
||
|
||
<para>Note that the implementation of this setting might be impossible (for example if network namespaces are
|
||
not available), and the unit should be written in a way that does not solely rely on this setting for
|
||
security.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>PrivateUsers=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If true, sets up a new user namespace for the executed processes and
|
||
configures a minimal user and group mapping, that maps the <literal>root</literal> user and group as well as
|
||
the unit's own user and group to themselves and everything else to the <literal>nobody</literal> user and
|
||
group. This is useful to securely detach the user and group databases used by the unit from the rest of the
|
||
system, and thus to create an effective sandbox environment. All files, directories, processes, IPC objects and
|
||
other resources owned by users/groups not equaling <literal>root</literal> or the unit's own will stay visible
|
||
from within the unit but appear owned by the <literal>nobody</literal> user and group. If this mode is enabled,
|
||
all unit processes are run without privileges in the host user namespace (regardless if the unit's own
|
||
user/group is <literal>root</literal> or not). Specifically this means that the process will have zero process
|
||
capabilities on the host's user namespace, but full capabilities within the service's user namespace. Settings
|
||
such as <varname>CapabilityBoundingSet=</varname> will affect only the latter, and there's no way to acquire
|
||
additional capabilities in the host's user namespace. Defaults to off.</para>
|
||
|
||
<para>This setting is particularly useful in conjunction with
|
||
<varname>RootDirectory=</varname>/<varname>RootImage=</varname>, as the need to synchronize the user and group
|
||
databases in the root directory and on the host is reduced, as the only users and groups who need to be matched
|
||
are <literal>root</literal>, <literal>nobody</literal> and the unit's own user and group.</para>
|
||
|
||
<para>Note that the implementation of this setting might be impossible (for example if user namespaces are not
|
||
available), and the unit should be written in a way that does not solely rely on this setting for
|
||
security.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>ProtectKernelTunables=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If true, kernel variables accessible through
|
||
<filename>/proc/sys</filename>, <filename>/sys</filename>, <filename>/proc/sysrq-trigger</filename>,
|
||
<filename>/proc/latency_stats</filename>, <filename>/proc/acpi</filename>,
|
||
<filename>/proc/timer_stats</filename>, <filename>/proc/fs</filename> and <filename>/proc/irq</filename> will
|
||
be made read-only to all processes of the unit. Usually, tunable kernel variables should be initialized only at
|
||
boot-time, for example with the
|
||
<citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> mechanism. Few
|
||
services need to write to these at runtime; it is hence recommended to turn this on for most services. For this
|
||
setting the same restrictions regarding mount propagation and privileges apply as for
|
||
<varname>ReadOnlyPaths=</varname> and related calls, see above. Defaults to off. If turned on and if running
|
||
in user mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. services
|
||
for which <varname>User=</varname> is set), <varname>NoNewPrivileges=yes</varname> is implied. Note that this
|
||
option does not prevent indirect changes to kernel tunables effected by IPC calls to other processes. However,
|
||
<varname>InaccessiblePaths=</varname> may be used to make relevant IPC file system objects inaccessible. If
|
||
<varname>ProtectKernelTunables=</varname> is set, <varname>MountAPIVFS=yes</varname> is
|
||
implied.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>ProtectKernelModules=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If true, explicit module loading will be denied. This allows to turn
|
||
off module load and unload operations on modular kernels. It is recommended to turn this on for most services
|
||
that do not need special file systems or extra kernel modules to work. Defaults to off. Enabling this option
|
||
removes <constant>CAP_SYS_MODULE</constant> from the capability bounding set for the unit, and installs a
|
||
system call filter to block module system calls, also <filename>/usr/lib/modules</filename> is made
|
||
inaccessible. For this setting the same restrictions regarding mount propagation and privileges apply as for
|
||
<varname>ReadOnlyPaths=</varname> and related calls, see above. Note that limited automatic module loading due
|
||
to user configuration or kernel mapping tables might still happen as side effect of requested user operations,
|
||
both privileged and unprivileged. To disable module auto-load feature please see
|
||
<citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||
<constant>kernel.modules_disabled</constant> mechanism and
|
||
<filename>/proc/sys/kernel/modules_disabled</filename> documentation. If turned on and if running in user
|
||
mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting
|
||
<varname>User=</varname>), <varname>NoNewPrivileges=yes</varname> is implied.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>ProtectControlGroups=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If true, the Linux Control Groups (<citerefentry
|
||
project='man-pages'><refentrytitle>cgroups</refentrytitle><manvolnum>7</manvolnum></citerefentry>) hierarchies
|
||
accessible through <filename>/sys/fs/cgroup</filename> will be made read-only to all processes of the
|
||
unit. Except for container managers no services should require write access to the control groups hierarchies;
|
||
it is hence recommended to turn this on for most services. For this setting the same restrictions regarding
|
||
mount propagation and privileges apply as for <varname>ReadOnlyPaths=</varname> and related calls, see
|
||
above. Defaults to off. If <varname>ProtectControlGroups=</varname> is set, <varname>MountAPIVFS=yes</varname>
|
||
is implied.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>RestrictAddressFamilies=</varname></term>
|
||
|
||
<listitem><para>Restricts the set of socket address families accessible to the processes of this unit. Takes a
|
||
space-separated list of address family names to whitelist, such as <constant>AF_UNIX</constant>,
|
||
<constant>AF_INET</constant> or <constant>AF_INET6</constant>. When prefixed with <constant>~</constant> the
|
||
listed address families will be applied as blacklist, otherwise as whitelist. Note that this restricts access
|
||
to the <citerefentry
|
||
project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call
|
||
only. Sockets passed into the process by other means (for example, by using socket activation with socket
|
||
units, see <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
|
||
are unaffected. Also, sockets created with <function>socketpair()</function> (which creates connected AF_UNIX
|
||
sockets only) are unaffected. Note that this option has no effect on 32-bit x86, s390, s390x, mips, mips-le,
|
||
ppc, ppc-le, pcc64, ppc64-le and is ignored (but works correctly on other ABIs, including x86-64). 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 <varname>SystemCallArchitectures=native</varname> or similar. If
|
||
running in user mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> capability
|
||
(e.g. setting <varname>User=nobody</varname>), <varname>NoNewPrivileges=yes</varname> is implied. By default,
|
||
no restrictions apply, all address families are accessible to processes. If assigned the empty string, any
|
||
previous address familiy restriction changes are undone. This setting does not affect commands prefixed with
|
||
<literal>+</literal>.</para>
|
||
|
||
<para>Use this option to limit exposure of processes to remote access, in particular via exotic and sensitive
|
||
network protocols, such as <constant>AF_PACKET</constant>. Note that in most cases, the local
|
||
<constant>AF_UNIX</constant> address family should be included in the configured whitelist as it is frequently
|
||
used for local communication, including for
|
||
<citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
||
logging.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>RestrictNamespaces=</varname></term>
|
||
|
||
<listitem><para>Restricts access to Linux namespace functionality for the processes of this unit. For details
|
||
about Linux namespaces, see <citerefentry
|
||
project='man-pages'><refentrytitle>namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry>. Either
|
||
takes a boolean argument, or a space-separated list of namespace type identifiers. If false (the default), no
|
||
restrictions on namespace creation and switching are made. If true, access to any kind of namespacing is
|
||
prohibited. Otherwise, a space-separated list of namespace type identifiers must be specified, consisting of
|
||
any combination of: <constant>cgroup</constant>, <constant>ipc</constant>, <constant>net</constant>,
|
||
<constant>mnt</constant>, <constant>pid</constant>, <constant>user</constant> and <constant>uts</constant>. Any
|
||
namespace type listed is made accessible to the unit's processes, access to namespace types not listed is
|
||
prohibited (whitelisting). By prepending the list with a single tilde character (<literal>~</literal>) the
|
||
effect may be inverted: only the listed namespace types will be made inaccessible, all unlisted ones are
|
||
permitted (blacklisting). If the empty string is assigned, the default namespace restrictions are applied,
|
||
which is equivalent to false. This option may appear more than once, in which case the namespace types are
|
||
merged by <constant>OR</constant>, or by <constant>AND</constant> if the lines are prefixed with
|
||
<literal>~</literal> (see examples below). Internally, this setting limits access to the
|
||
<citerefentry><refentrytitle>unshare</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>clone</refentrytitle><manvolnum>2</manvolnum></citerefentry> and
|
||
<citerefentry><refentrytitle>setns</refentrytitle><manvolnum>2</manvolnum></citerefentry> system calls, taking
|
||
the specified flags parameters into account. Note that — if this option is used — in addition to restricting
|
||
creation and switching of the specified types of namespaces (or all of them, if true) access to the
|
||
<function>setns()</function> system call with a zero flags parameter is prohibited. This setting is only
|
||
supported on x86, x86-64, mips, mips-le, mips64, mips64-le, mips64-n32, mips64-le-n32, ppc64, ppc64-le, s390
|
||
and s390x, and enforces no restrictions on other architectures. If running in user mode, or in system mode, but
|
||
without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting <varname>User=</varname>),
|
||
<varname>NoNewPrivileges=yes</varname> is implied.</para>
|
||
|
||
<para>Example: if a unit has the following,
|
||
<programlisting>RestrictNamespaces=cgroup ipc
|
||
RestrictNamespaces=cgroup net</programlisting>
|
||
then <constant>cgroup</constant>, <constant>ipc</constant>, and <constant>net</constant> are set.
|
||
If the second line is prefixed with <literal>~</literal>, e.g.,
|
||
<programlisting>RestrictNamespaces=cgroup ipc
|
||
RestrictNamespaces=~cgroup net</programlisting>
|
||
then, only <constant>ipc</constant> is set.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>LockPersonality=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If set, locks down the <citerefentry
|
||
project='man-pages'><refentrytitle>personality</refentrytitle><manvolnum>2</manvolnum></citerefentry> system
|
||
call so that the kernel execution domain may not be changed from the default or the personality selected with
|
||
<varname>Personality=</varname> directive. This may be useful to improve security, because odd personality
|
||
emulations may be poorly tested and source of vulnerabilities. If running in user mode, or in system mode, but
|
||
without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting <varname>User=</varname>),
|
||
<varname>NoNewPrivileges=yes</varname> is implied.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>MemoryDenyWriteExecute=</varname></term>
|
||
|
||
<listitem><para>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 that rejects
|
||
<citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> system calls with both
|
||
<constant>PROT_EXEC</constant> and <constant>PROT_WRITE</constant> set,
|
||
<citerefentry><refentrytitle>mprotect</refentrytitle><manvolnum>2</manvolnum></citerefentry> or
|
||
<citerefentry><refentrytitle>pkey_mprotect</refentrytitle><manvolnum>2</manvolnum></citerefentry> system calls
|
||
with <constant>PROT_EXEC</constant> set and
|
||
<citerefentry><refentrytitle>shmat</refentrytitle><manvolnum>2</manvolnum></citerefentry> system calls with
|
||
<constant>SHM_EXEC</constant> 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. Note that this feature is fully available on x86-64, and
|
||
partially on x86. Specifically, the <function>shmat()</function> 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 <varname>SystemCallArchitectures=native</varname> or similar. If
|
||
running in user mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> capability
|
||
(e.g. setting <varname>User=</varname>), <varname>NoNewPrivileges=yes</varname> is implied.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>RestrictRealtime=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If set, any attempts to enable realtime scheduling in a process of
|
||
the unit are refused. This restricts access to realtime task scheduling policies such as
|
||
<constant>SCHED_FIFO</constant>, <constant>SCHED_RR</constant> or <constant>SCHED_DEADLINE</constant>. See
|
||
<citerefentry project='man-pages'><refentrytitle>sched</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||
for details about these scheduling policies. If running in user mode, or in system mode, but without the
|
||
<constant>CAP_SYS_ADMIN</constant> capability (e.g. setting <varname>User=</varname>),
|
||
<varname>NoNewPrivileges=yes</varname> is implied. Realtime scheduling policies may be used to monopolize CPU
|
||
time for longer periods of time, and may hence be used to lock up or otherwise trigger Denial-of-Service
|
||
situations on the system. It is hence recommended to restrict access to realtime scheduling to the few programs
|
||
that actually require them. Defaults to off.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>RemoveIPC=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean parameter. If set, all System V and POSIX IPC objects owned by the user and
|
||
group the processes of this unit are run as are removed when the unit is stopped. This setting only has an
|
||
effect if at least one of <varname>User=</varname>, <varname>Group=</varname> and
|
||
<varname>DynamicUser=</varname> are used. It has no effect on IPC objects owned by the root user. Specifically,
|
||
this removes System V semaphores, as well as System V and POSIX shared memory segments and message queues. If
|
||
multiple units use the same user or group the IPC objects are removed when the last of these units is
|
||
stopped. This setting is implied if <varname>DynamicUser=</varname> is set.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>MountFlags=</varname></term>
|
||
|
||
<listitem><para>Takes a mount propagation flag: <option>shared</option>, <option>slave</option> or
|
||
<option>private</option>, which control whether mounts in the file system namespace set up for this unit's
|
||
processes will receive or propagate mounts and unmounts. See <citerefentry
|
||
project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
|
||
details. Defaults to <option>shared</option>. Use <option>shared</option> to ensure that mounts and unmounts
|
||
are propagated from systemd's namespace to the service's namespace and vice versa. Use <option>slave</option>
|
||
to run processes so that none of their mounts and unmounts will propagate to the host. Use
|
||
<option>private</option> to also ensure that no mounts and unmounts from the host will propagate into the unit
|
||
processes' namespace. If this is set to <option>slave</option> or <option>private</option>, any mounts created
|
||
by spawned processes will be unmounted after the completion of the current command line of
|
||
<varname>ExecStartPre=</varname>, <varname>ExecStartPost=</varname>, <varname>ExecStart=</varname>, and
|
||
<varname>ExecStopPost=</varname>. Note that <option>slave</option> means that file systems mounted on the host
|
||
might stay mounted continuously in the unit's namespace, and thus keep the device busy. Note that the file
|
||
system namespace related options (<varname>PrivateTmp=</varname>, <varname>PrivateDevices=</varname>,
|
||
<varname>ProtectSystem=</varname>, <varname>ProtectHome=</varname>, <varname>ProtectKernelTunables=</varname>,
|
||
<varname>ProtectControlGroups=</varname>, <varname>ReadOnlyPaths=</varname>,
|
||
<varname>InaccessiblePaths=</varname>, <varname>ReadWritePaths=</varname>) require that mount and unmount
|
||
propagation from the unit's file system namespace is disabled, and hence downgrade <option>shared</option> to
|
||
<option>slave</option>. </para></listitem>
|
||
</varlistentry>
|
||
|
||
</variablelist>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>System Call Filtering</title>
|
||
<variablelist>
|
||
|
||
<varlistentry>
|
||
<term><varname>SystemCallFilter=</varname></term>
|
||
|
||
<listitem><para>Takes a space-separated list of system call names. If this setting is used, all system calls
|
||
executed by the unit processes except for the listed ones will result in immediate process termination with the
|
||
<constant>SIGSYS</constant> signal (whitelisting). If the first character of the list is <literal>~</literal>,
|
||
the effect is inverted: only the listed system calls will result in immediate process termination
|
||
(blacklisting). Blacklisted system calls and system call groups may optionally be suffixed with a colon
|
||
(<literal>:</literal>) and <literal>errno</literal> error number (between 0 and 4095) or errno name such as
|
||
<constant>EPERM</constant>, <constant>EACCES</constant> or <constant>EUCLEAN</constant>. This value will be
|
||
returned when a blacklisted system call is triggered, instead of terminating the processes immediately. This
|
||
value takes precedence over the one given in <varname>SystemCallErrorNumber=</varname>. If running in user
|
||
mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting
|
||
<varname>User=nobody</varname>), <varname>NoNewPrivileges=yes</varname> is implied. This feature makes use of
|
||
the Secure Computing Mode 2 interfaces of the kernel ('seccomp filtering') and is useful for enforcing a
|
||
minimal sandboxing environment. Note that the <function>execve</function>, <function>exit</function>,
|
||
<function>exit_group</function>, <function>getrlimit</function>, <function>rt_sigreturn</function>,
|
||
<function>sigreturn</function> system calls and the system calls for querying time and sleeping are implicitly
|
||
whitelisted and do not need to be listed explicitly. This option may be specified more than once, in which case
|
||
the filter masks are merged. If the empty string is assigned, the filter is reset, all prior assignments will
|
||
have no effect. This does not affect commands prefixed with <literal>+</literal>.</para>
|
||
|
||
<para>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
|
||
<varname>SystemCallArchitectures=native</varname> or similar.</para>
|
||
|
||
<para>Note that strict system call filters may impact execution and error handling code paths of the service
|
||
invocation. Specifically, access to the <function>execve</function> system call is required for the execution
|
||
of the service binary — if it is blocked service invocation will necessarily fail. Also, if execution of the
|
||
service binary fails for some reason (for example: missing service executable), the error handling logic might
|
||
require access to an additional set of system calls in order to process and log this failure correctly. It
|
||
might be necessary to temporarily disable system call filters in order to simplify debugging of such
|
||
failures.</para>
|
||
|
||
<para>If you specify both types of this option (i.e. whitelisting and blacklisting), the first encountered
|
||
will take precedence and will dictate the default action (termination or approval of a system call). Then the
|
||
next occurrences of this option will add or delete the listed system calls from the set of the filtered system
|
||
calls, depending of its type and the default action. (For example, if you have started with a whitelisting of
|
||
<function>read</function> and <function>write</function>, and right after it add a blacklisting of
|
||
<function>write</function>, then <function>write</function> will be removed from the set.)</para>
|
||
|
||
<para>As the number of possible system calls is large, predefined sets of system calls are provided. A set
|
||
starts with <literal>@</literal> character, followed by name of the set.
|
||
|
||
<table>
|
||
<title>Currently predefined system call sets</title>
|
||
|
||
<tgroup cols='2'>
|
||
<colspec colname='set' />
|
||
<colspec colname='description' />
|
||
<thead>
|
||
<row>
|
||
<entry>Set</entry>
|
||
<entry>Description</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry>@aio</entry>
|
||
<entry>Asynchronous I/O (<citerefentry project='man-pages'><refentrytitle>io_setup</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>io_submit</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@basic-io</entry>
|
||
<entry>System calls for basic I/O: reading, writing, seeking, file descriptor duplication and closing (<citerefentry project='man-pages'><refentrytitle>read</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>write</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@chown</entry>
|
||
<entry>Changing file ownership (<citerefentry project='man-pages'><refentrytitle>chown</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>fchownat</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@clock</entry>
|
||
<entry>System calls for changing the system clock (<citerefentry project='man-pages'><refentrytitle>adjtimex</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>settimeofday</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@cpu-emulation</entry>
|
||
<entry>System calls for CPU emulation functionality (<citerefentry project='man-pages'><refentrytitle>vm86</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@debug</entry>
|
||
<entry>Debugging, performance monitoring and tracing functionality (<citerefentry project='man-pages'><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>perf_event_open</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@file-system</entry>
|
||
<entry>File system operations: opening, creating files and directories for read and write, renaming and removing them, reading file properties, or creating hard and symbolic links.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@io-event</entry>
|
||
<entry>Event loop system calls (<citerefentry project='man-pages'><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>select</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>eventfd</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@ipc</entry>
|
||
<entry>Pipes, SysV IPC, POSIX Message Queues and other IPC (<citerefentry project='man-pages'><refentrytitle>mq_overview</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>svipc</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@keyring</entry>
|
||
<entry>Kernel keyring access (<citerefentry project='man-pages'><refentrytitle>keyctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@memlock</entry>
|
||
<entry>Locking of memory into RAM (<citerefentry project='man-pages'><refentrytitle>mlock</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>mlockall</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@module</entry>
|
||
<entry>Loading and unloading of kernel modules (<citerefentry project='man-pages'><refentrytitle>init_module</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>delete_module</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@mount</entry>
|
||
<entry>Mounting and unmounting of file systems (<citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@network-io</entry>
|
||
<entry>Socket I/O (including local AF_UNIX): <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>unix</refentrytitle><manvolnum>7</manvolnum></citerefentry></entry>
|
||
</row>
|
||
<row>
|
||
<entry>@obsolete</entry>
|
||
<entry>Unusual, obsolete or unimplemented (<citerefentry project='man-pages'><refentrytitle>create_module</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>gtty</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@privileged</entry>
|
||
<entry>All system calls which need super-user capabilities (<citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@process</entry>
|
||
<entry>Process control, execution, namespaceing operations (<citerefentry project='man-pages'><refentrytitle>clone</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry>, …</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@raw-io</entry>
|
||
<entry>Raw I/O port access (<citerefentry project='man-pages'><refentrytitle>ioperm</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>iopl</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <function>pciconfig_read()</function>, …)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@reboot</entry>
|
||
<entry>System calls for rebooting and reboot preparation (<citerefentry project='man-pages'><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <function>kexec()</function>, …)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@resources</entry>
|
||
<entry>System calls for changing resource limits, memory and scheduling parameters (<citerefentry project='man-pages'><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>setpriority</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@setuid</entry>
|
||
<entry>System calls for changing user ID and group ID credentials, (<citerefentry project='man-pages'><refentrytitle>setuid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>setgid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>setresuid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@signal</entry>
|
||
<entry>System calls for manipulating and handling process signals (<citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@swap</entry>
|
||
<entry>System calls for enabling/disabling swap devices (<citerefentry project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>swapoff</refentrytitle><manvolnum>2</manvolnum></citerefentry>)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@sync</entry>
|
||
<entry>Synchronizing files and memory to disk: (<citerefentry project='man-pages'><refentrytitle>fsync</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>msync</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>@timer</entry>
|
||
<entry>System calls for scheduling operations by time (<citerefentry project='man-pages'><refentrytitle>alarm</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>timer_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
|
||
Note, that as new system calls are added to the kernel, additional system calls might be added to the groups
|
||
above. Contents of the sets may also change between systemd versions. In addition, the list of system calls
|
||
depends on the kernel version and architecture for which systemd was compiled. Use
|
||
<command>systemd-analyze syscall-filter</command> to list the actual list of system calls in each
|
||
filter.</para>
|
||
|
||
<para>It is recommended to combine the file system namespacing related options with
|
||
<varname>SystemCallFilter=~@mount</varname>, in order to prohibit the unit's processes to undo the
|
||
mappings. Specifically these are the options <varname>PrivateTmp=</varname>,
|
||
<varname>PrivateDevices=</varname>, <varname>ProtectSystem=</varname>, <varname>ProtectHome=</varname>,
|
||
<varname>ProtectKernelTunables=</varname>, <varname>ProtectControlGroups=</varname>,
|
||
<varname>ReadOnlyPaths=</varname>, <varname>InaccessiblePaths=</varname> and
|
||
<varname>ReadWritePaths=</varname>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>SystemCallErrorNumber=</varname></term>
|
||
|
||
<listitem><para>Takes an <literal>errno</literal> error number (between 1 and 4095) or errno name such as
|
||
<constant>EPERM</constant>, <constant>EACCES</constant> or <constant>EUCLEAN</constant>, to return when the
|
||
system call filter configured with <varname>SystemCallFilter=</varname> is triggered, instead of terminating
|
||
the process immediately. When this setting is not used, or when the empty string is assigned, the process will
|
||
be terminated immediately when the filter is triggered.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>SystemCallArchitectures=</varname></term>
|
||
|
||
<listitem><para>Takes a space-separated list of architecture identifiers to include in the system call
|
||
filter. The known architecture identifiers are the same as for <varname>ConditionArchitecture=</varname>
|
||
described in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
||
as well as <constant>x32</constant>, <constant>mips64-n32</constant>, <constant>mips64-le-n32</constant>, and
|
||
the special identifier <constant>native</constant>. The special identifier <constant>native</constant>
|
||
implicitly maps to the native architecture of the system (or more precisely: to the architecture the system
|
||
manager is compiled for). If running in user mode, or in system mode, but without the
|
||
<constant>CAP_SYS_ADMIN</constant> capability (e.g. setting <varname>User=nobody</varname>),
|
||
<varname>NoNewPrivileges=yes</varname> is implied. By default, this option is set to the empty list, i.e. no
|
||
system call architecture filtering is applied.</para>
|
||
|
||
<para>If this setting is used, processes of this unit will only be permitted to call native system calls, and
|
||
system calls of the specified architectures. For the purposes of this option, the x32 architecture is treated
|
||
as including x86-64 system calls. However, this setting still fulfills its purpose, as explained below, on
|
||
x32.</para>
|
||
|
||
<para>System call filtering is not equally effective on all architectures. For example, on x86
|
||
filtering of network socket-related calls is not possible, due to ABI limitations — a limitation that x86-64
|
||
does not have, however. On systems supporting multiple ABIs at the same time — such as x86/x86-64 — it is hence
|
||
recommended to limit the set of permitted system call architectures so that secondary ABIs may not be used to
|
||
circumvent the restrictions applied to the native ABI of the system. In particular, setting
|
||
<varname>SystemCallArchitectures=native</varname> is a good choice for disabling non-native ABIs.</para>
|
||
|
||
<para>System call architectures may also be restricted system-wide via the
|
||
<varname>SystemCallArchitectures=</varname> option in the global configuration. See
|
||
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
|
||
details.</para></listitem>
|
||
</varlistentry>
|
||
|
||
</variablelist>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>Environment</title>
|
||
|
||
<variablelist>
|
||
|
||
<varlistentry>
|
||
<term><varname>Environment=</varname></term>
|
||
|
||
<listitem><para>Sets environment variables for executed processes. Takes a space-separated list of variable
|
||
assignments. This option may be specified more than once, in which case all listed variables will be set. If
|
||
the same variable is set twice, the later setting will override the earlier setting. If the empty string is
|
||
assigned to this option, the list of environment variables is reset, all prior assignments have no
|
||
effect. Variable expansion is not performed inside the strings, however, specifier expansion is possible. The $
|
||
character has no special meaning. If you need to assign a value containing spaces or the equals sign to a
|
||
variable, use double quotes (") for the assignment.</para>
|
||
|
||
<para>Example:
|
||
<programlisting>Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6"</programlisting>
|
||
gives three variables <literal>VAR1</literal>,
|
||
<literal>VAR2</literal>, <literal>VAR3</literal>
|
||
with the values <literal>word1 word2</literal>,
|
||
<literal>word3</literal>, <literal>$word 5 6</literal>.
|
||
</para>
|
||
|
||
<para>
|
||
See <citerefentry
|
||
project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details
|
||
about environment variables.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>EnvironmentFile=</varname></term>
|
||
|
||
<listitem><para>Similar to <varname>Environment=</varname> but reads the environment variables from a text
|
||
file. The text file should contain new-line-separated variable assignments. Empty lines, lines without an
|
||
<literal>=</literal> separator, or lines starting with ; or # will be ignored, which may be used for
|
||
commenting. A line ending with a backslash will be concatenated with the following one, allowing multiline
|
||
variable definitions. The parser strips leading and trailing whitespace from the values of assignments, unless
|
||
you use double quotes (").</para>
|
||
|
||
<para>The argument passed should be an absolute filename or wildcard expression, optionally prefixed with
|
||
<literal>-</literal>, which indicates that if the file does not exist, it will not be read and no error or
|
||
warning message is logged. This option may be specified more than once in which case all specified files are
|
||
read. If the empty string is assigned to this option, the list of file to read is reset, all prior assignments
|
||
have no effect.</para>
|
||
|
||
<para>The files listed with this directive will be read shortly before the process is executed (more
|
||
specifically, after all processes from a previous unit state terminated. This means you can generate these
|
||
files in one unit state, and read it with this option in the next).</para>
|
||
|
||
<para>Settings from these files override settings made with <varname>Environment=</varname>. If the same
|
||
variable is set twice from these files, the files will be read in the order they are specified and the later
|
||
setting will override the earlier setting.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>PassEnvironment=</varname></term>
|
||
|
||
<listitem><para>Pass environment variables set for the system service manager to executed processes. Takes a
|
||
space-separated list of variable names. This option may be specified more than once, in which case all listed
|
||
variables will be passed. If the empty string is assigned to this option, the list of environment variables to
|
||
pass is reset, all prior assignments have no effect. Variables specified that are not set for the system
|
||
manager will not be passed and will be silently ignored. Note that this option is only relevant for the system
|
||
service manager, as system services by default do not automatically inherit any environment variables set for
|
||
the service manager itself. However, in case of the user service manager all environment variables are passed
|
||
to the executed processes anyway, hence this option is without effect for the user service manager.</para>
|
||
|
||
<para>Variables set for invoked processes due to this setting are subject to being overridden by those
|
||
configured with <varname>Environment=</varname> or <varname>EnvironmentFile=</varname>.</para>
|
||
|
||
<para>Example:
|
||
<programlisting>PassEnvironment=VAR1 VAR2 VAR3</programlisting>
|
||
passes three variables <literal>VAR1</literal>,
|
||
<literal>VAR2</literal>, <literal>VAR3</literal>
|
||
with the values set for those variables in PID1.</para>
|
||
|
||
<para>
|
||
See <citerefentry
|
||
project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details
|
||
about environment variables.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>UnsetEnvironment=</varname></term>
|
||
|
||
<listitem><para>Explicitly unset environment variable assignments that would normally be passed from the
|
||
service manager to invoked processes of this unit. Takes a space-separated list of variable names or variable
|
||
assignments. This option may be specified more than once, in which case all listed variables/assignments will
|
||
be unset. If the empty string is assigned to this option, the list of environment variables/assignments to
|
||
unset is reset. If a variable assignment is specified (that is: a variable name, followed by
|
||
<literal>=</literal>, followed by its value), then any environment variable matching this precise assignment is
|
||
removed. If a variable name is specified (that is a variable name without any following <literal>=</literal> or
|
||
value), then any assignment matching the variable name, regardless of its value is removed. Note that the
|
||
effect of <varname>UnsetEnvironment=</varname> is applied as final step when the environment list passed to
|
||
executed processes is compiled. That means it may undo assignments from any configuration source, including
|
||
assignments made through <varname>Environment=</varname> or <varname>EnvironmentFile=</varname>, inherited from
|
||
the system manager's global set of environment variables, inherited via <varname>PassEnvironment=</varname>,
|
||
set by the service manager itself (such as <varname>$NOTIFY_SOCKET</varname> and such), or set by a PAM module
|
||
(in case <varname>PAMName=</varname> is used).</para>
|
||
|
||
<para>
|
||
See <citerefentry
|
||
project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details
|
||
about environment variables.</para></listitem>
|
||
</varlistentry>
|
||
|
||
</variablelist>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>Logging and Standard Input/Output</title>
|
||
|
||
<variablelist>
|
||
<varlistentry>
|
||
|
||
<term><varname>StandardInput=</varname></term>
|
||
|
||
<listitem><para>Controls where file descriptor 0 (STDIN) of the executed processes is connected to. Takes one
|
||
of <option>null</option>, <option>tty</option>, <option>tty-force</option>, <option>tty-fail</option>,
|
||
<option>data</option>, <option>file:<replaceable>path</replaceable></option>, <option>socket</option> or
|
||
<option>fd:<replaceable>name</replaceable></option>.</para>
|
||
|
||
<para>If <option>null</option> is selected, standard input will be connected to <filename>/dev/null</filename>,
|
||
i.e. all read attempts by the process will result in immediate EOF.</para>
|
||
|
||
<para>If <option>tty</option> is selected, standard input is connected to a TTY (as configured by
|
||
<varname>TTYPath=</varname>, see below) and the executed process becomes the controlling process of the
|
||
terminal. If the terminal is already being controlled by another process, the executed process waits until the
|
||
current controlling process releases the terminal.</para>
|
||
|
||
<para><option>tty-force</option> is similar to <option>tty</option>, but the executed process is forcefully and
|
||
immediately made the controlling process of the terminal, potentially removing previous controlling processes
|
||
from the terminal.</para>
|
||
|
||
<para><option>tty-fail</option> is similar to <option>tty</option>, but if the terminal already has a
|
||
controlling process start-up of the executed process fails.</para>
|
||
|
||
<para>The <option>data</option> option may be used to configure arbitrary textual or binary data to pass via
|
||
standard input to the executed process. The data to pass is configured via
|
||
<varname>StandardInputText=</varname>/<varname>StandardInputData=</varname> (see below). Note that the actual
|
||
file descriptor type passed (memory file, regular file, UNIX pipe, …) might depend on the kernel and available
|
||
privileges. In any case, the file descriptor is read-only, and when read returns the specified data followed by
|
||
EOF.</para>
|
||
|
||
<para>The <option>file:<replaceable>path</replaceable></option> option may be used to connect a specific file
|
||
system object to standard input. An absolute path following the <literal>:</literal> character is expected,
|
||
which may refer to a regular file, a FIFO or special file. If an <constant>AF_UNIX</constant> socket in the
|
||
file system is specified, a stream socket is connected to it. The latter is useful for connecting standard
|
||
input of processes to arbitrary system services.</para>
|
||
|
||
<para>The <option>socket</option> option is valid in socket-activated services only, and requires the relevant
|
||
socket unit file (see
|
||
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details)
|
||
to have <varname>Accept=yes</varname> set, or to specify a single socket only. If this option is set, standard
|
||
input will be connected to the socket the service was activated from, which is primarily useful for
|
||
compatibility with daemons designed for use with the traditional <citerefentry
|
||
project='freebsd'><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry> socket activation
|
||
daemon.</para>
|
||
|
||
<para>The <option>fd:<replaceable>name</replaceable></option> option connects standard input to a specific,
|
||
named file descriptor provided by a socket unit. The name may be specified as part of this option, following a
|
||
<literal>:</literal> character (e.g. <literal>fd:foobar</literal>). If no name is specified, the name
|
||
<literal>stdin</literal> is implied (i.e. <literal>fd</literal> is equivalent to <literal>fd:stdin</literal>).
|
||
At least one socket unit defining the specified name must be provided via the <varname>Sockets=</varname>
|
||
option, and the file descriptor name may differ from the name of its containing socket unit. If multiple
|
||
matches are found, the first one will be used. See <varname>FileDescriptorName=</varname> in
|
||
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more
|
||
details about named file descriptors and their ordering.</para>
|
||
|
||
<para>This setting defaults to <option>null</option>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>StandardOutput=</varname></term>
|
||
|
||
<listitem><para>Controls where file descriptor 1 (STDOUT) of the executed processes is connected to. Takes one
|
||
of <option>inherit</option>, <option>null</option>, <option>tty</option>, <option>journal</option>,
|
||
<option>syslog</option>, <option>kmsg</option>, <option>journal+console</option>,
|
||
<option>syslog+console</option>, <option>kmsg+console</option>,
|
||
<option>file:<replaceable>path</replaceable></option>, <option>socket</option> or
|
||
<option>fd:<replaceable>name</replaceable></option>.</para>
|
||
|
||
<para><option>inherit</option> duplicates the file descriptor of standard input for standard output.</para>
|
||
|
||
<para><option>null</option> connects standard output to <filename>/dev/null</filename>, i.e. everything written
|
||
to it will be lost.</para>
|
||
|
||
<para><option>tty</option> connects standard output to a tty (as configured via <varname>TTYPath=</varname>,
|
||
see below). If the TTY is used for output only, the executed process will not become the controlling process of
|
||
the terminal, and will not fail or wait for other processes to release the terminal.</para>
|
||
|
||
<para><option>journal</option> connects standard output with the journal which is accessible via
|
||
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. Note that
|
||
everything that is written to syslog or kmsg (see below) is implicitly stored in the journal as well, the
|
||
specific two options listed below are hence supersets of this one.</para>
|
||
|
||
<para><option>syslog</option> connects standard output to the <citerefentry
|
||
project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> system syslog
|
||
service, in addition to the journal. Note that the journal daemon is usually configured to forward everything
|
||
it receives to syslog anyway, in which case this option is no different from <option>journal</option>.</para>
|
||
|
||
<para><option>kmsg</option> connects standard output with the kernel log buffer which is accessible via
|
||
<citerefentry project='man-pages'><refentrytitle>dmesg</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
||
in addition to the journal. The journal daemon might be configured to send all logs to kmsg anyway, in which
|
||
case this option is no different from <option>journal</option>.</para>
|
||
|
||
<para><option>journal+console</option>, <option>syslog+console</option> and <option>kmsg+console</option> work
|
||
in a similar way as the three options above but copy the output to the system console as well.</para>
|
||
|
||
<para>The <option>file:<replaceable>path</replaceable></option> option may be used to connect a specific file
|
||
system object to standard output. The semantics are similar to the same option of
|
||
<varname>StandardInput=</varname>, see above. If standard input and output are directed to the same file path,
|
||
it is opened only once, for reading as well as writing and duplicated. This is particular useful when the
|
||
specified path refers to an <constant>AF_UNIX</constant> socket in the file system, as in that case only a
|
||
single stream connection is created for both input and output.</para>
|
||
|
||
<para><option>socket</option> connects standard output to a socket acquired via socket activation. The
|
||
semantics are similar to the same option of <varname>StandardInput=</varname>, see above.</para>
|
||
|
||
<para>The <option>fd:<replaceable>name</replaceable></option> option connects standard output to a specific,
|
||
named file descriptor provided by a socket unit. A name may be specified as part of this option, following a
|
||
<literal>:</literal> character (e.g. <literal>fd:foobar</literal>). If no name is specified, the name
|
||
<literal>stdout</literal> is implied (i.e. <literal>fd</literal> is equivalent to
|
||
<literal>fd:stdout</literal>). At least one socket unit defining the specified name must be provided via the
|
||
<varname>Sockets=</varname> option, and the file descriptor name may differ from the name of its containing
|
||
socket unit. If multiple matches are found, the first one will be used. See
|
||
<varname>FileDescriptorName=</varname> in
|
||
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more
|
||
details about named descriptors and their ordering.</para>
|
||
|
||
<para>If the standard output (or error output, see below) of a unit is connected to the journal, syslog or the
|
||
kernel log buffer, the unit will implicitly gain a dependency of type <varname>After=</varname> on
|
||
<filename>systemd-journald.socket</filename> (also see the "Implicit Dependencies" section above). Also note
|
||
that in this case stdout (or stderr, see below) will be an <constant>AF_UNIX</constant> stream socket, and not
|
||
a pipe or FIFO that can be re-opened. This means when executing shell scripts the construct <command>echo
|
||
"hello" > /dev/stderr</command> for writing text to stderr will not work. To mitigate this use the construct
|
||
<command>echo "hello" >&2</command> instead, which is mostly equivalent and avoids this pitfall.</para>
|
||
|
||
<para>This setting defaults to the value set with <varname>DefaultStandardOutput=</varname> in
|
||
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, which
|
||
defaults to <option>journal</option>. Note that setting this parameter might result in additional dependencies
|
||
to be added to the unit (see above).</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>StandardError=</varname></term>
|
||
|
||
<listitem><para>Controls where file descriptor 2 (STDERR) of the executed processes is connected to. The
|
||
available options are identical to those of <varname>StandardOutput=</varname>, with some exceptions: if set to
|
||
<option>inherit</option> the file descriptor used for standard output is duplicated for standard error, while
|
||
<option>fd:<replaceable>name</replaceable></option> will use a default file descriptor name of
|
||
<literal>stderr</literal>.</para>
|
||
|
||
<para>This setting defaults to the value set with <varname>DefaultStandardError=</varname> in
|
||
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, which
|
||
defaults to <option>inherit</option>. Note that setting this parameter might result in additional dependencies
|
||
to be added to the unit (see above).</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>StandardInputText=</varname></term>
|
||
<term><varname>StandardInputData=</varname></term>
|
||
|
||
<listitem><para>Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to the
|
||
executed processes. These settings have no effect unless <varname>StandardInput=</varname> is set to
|
||
<option>data</option>. Use this option to embed process input data directly in the unit file.</para>
|
||
|
||
<para><varname>StandardInputText=</varname> accepts arbitrary textual data. C-style escapes for special
|
||
characters as well as the usual <literal>%</literal>-specifiers are resolved. Each time this setting is used
|
||
the the specified text is appended to the per-unit data buffer, followed by a newline character (thus every use
|
||
appends a new line to the end of the buffer). Note that leading and trailing whitespace of lines configured
|
||
with this option is removed. If an empty line is specified the buffer is cleared (hence, in order to insert an
|
||
empty line, add an additional <literal>\n</literal> to the end or beginning of a line).</para>
|
||
|
||
<para><varname>StandardInputData=</varname> accepts arbitrary binary data, encoded in <ulink
|
||
url="https://tools.ietf.org/html/rfc2045#section-6.8">Base64</ulink>. No escape sequences or specifiers are
|
||
resolved. Any whitespace in the encoded version is ignored during decoding.</para>
|
||
|
||
<para>Note that <varname>StandardInputText=</varname> and <varname>StandardInputData=</varname> operate on the
|
||
same data buffer, and may be mixed in order to configure both binary and textual data for the same input
|
||
stream. The textual or binary data is joined strictly in the order the settings appear in the unit
|
||
file. Assigning an empty string to either will reset the data buffer.</para>
|
||
|
||
<para>Please keep in mind that in order to maintain readability long unit file settings may be split into
|
||
multiple lines, by suffixing each line (except for the last) with a <literal>\</literal> character (see
|
||
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
|
||
details). This is particularly useful for large data configured with these two options. Example:</para>
|
||
|
||
<programlisting>…
|
||
StandardInput=data
|
||
StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy4KSWNrIGtpZWtl \
|
||
LCBzdGF1bmUsIHd1bmRyZSBtaXIsCnVmZiBlZW1hbCBqZWh0IHNlIHVmZiBkaWUgVMO8ci4KTmFu \
|
||
dSwgZGVuayBpY2ssIGljayBkZW5rIG5hbnUhCkpldHogaXNzZSB1ZmYsIGVyc2NodCB3YXIgc2Ug \
|
||
enUhCkljayBqZWhlIHJhdXMgdW5kIGJsaWNrZSDigJQKdW5kIHdlciBzdGVodCBkcmF1w59lbj8g \
|
||
SWNrZSEK
|
||
…</programlisting></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>LogLevelMax=</varname></term>
|
||
|
||
<listitem><para>Configures filtering by log level of log messages generated by this unit. Takes a
|
||
<command>syslog</command> log level, one of <option>emerg</option> (lowest log level, only highest priority
|
||
messages), <option>alert</option>, <option>crit</option>, <option>err</option>, <option>warning</option>,
|
||
<option>notice</option>, <option>info</option>, <option>debug</option> (highest log level, also lowest priority
|
||
messages). See <citerefentry
|
||
project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
|
||
details. By default no filtering is applied (i.e. the default maximum log level is <option>debug</option>). Use
|
||
this option to configure the logging system to drop log messages of a specific service above the specified
|
||
level. For example, set <varname>LogLevelMax=</varname><option>info</option> in order to turn off debug logging
|
||
of a particularly chatty unit. Note that the the configured level is applied to any log messages written by any
|
||
of the processes belonging to this unit, sent via any supported logging protocol. The filtering is applied
|
||
early in the logging pipeline, before any kind of further processing is done. Moreover, messages which pass
|
||
through this filter successfully might still be dropped by filters applied at a later stage in the logging
|
||
subsystem. For example, <varname>MaxLevelStore=</varname> configured in
|
||
<citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> might
|
||
prohibit messages of higher log levels to be stored on disk, even though the per-unit
|
||
<varname>LogLevelMax=</varname> permitted it to be processed.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>LogExtraFields=</varname></term>
|
||
|
||
<listitem><para>Configures additional log metadata fields to include in all log records generated by processes
|
||
associated with this unit. This setting takes one or more journal field assignments in the format
|
||
<literal>FIELD=VALUE</literal> separated by whitespace. See
|
||
<citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
||
details on the journal field concept. Even though the underlying journal implementation permits binary field
|
||
values, this setting accepts only valid UTF-8 values. To include space characters in a journal field value,
|
||
enclose the assignment in double quotes ("). The usual specifiers are expanded in all assignments (see
|
||
below). Note that this setting is not only useful for attaching additional metadata to log records of a unit,
|
||
but given that all fields and values are indexed may also be used to implement cross-unit log record
|
||
matching. Assign an empty string to reset the list.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>SyslogIdentifier=</varname></term>
|
||
|
||
<listitem><para>Sets the process name ("<command>syslog</command> tag") to prefix log lines sent to the logging
|
||
system or the kernel log buffer with. If not set, defaults to the process name of the executed process. This
|
||
option is only useful when <varname>StandardOutput=</varname> or <varname>StandardError=</varname> are set to
|
||
<option>journal</option>, <option>syslog</option> or <option>kmsg</option> (or to the same settings in
|
||
combination with <option>+console</option>) and only applies to log messages written to stdout or
|
||
stderr.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>SyslogFacility=</varname></term>
|
||
|
||
<listitem><para>Sets the <command>syslog</command> facility identifier to use when logging. One of
|
||
<option>kern</option>, <option>user</option>, <option>mail</option>, <option>daemon</option>,
|
||
<option>auth</option>, <option>syslog</option>, <option>lpr</option>, <option>news</option>,
|
||
<option>uucp</option>, <option>cron</option>, <option>authpriv</option>, <option>ftp</option>,
|
||
<option>local0</option>, <option>local1</option>, <option>local2</option>, <option>local3</option>,
|
||
<option>local4</option>, <option>local5</option>, <option>local6</option> or <option>local7</option>. See
|
||
<citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||
for details. This option is only useful when <varname>StandardOutput=</varname> or
|
||
<varname>StandardError=</varname> are set to <option>journal</option>, <option>syslog</option> or
|
||
<option>kmsg</option> (or to the same settings in combination with <option>+console</option>), and only applies
|
||
to log messages written to stdout or stderr. Defaults to <option>daemon</option>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>SyslogLevel=</varname></term>
|
||
|
||
<listitem><para>The default <command>syslog</command> log level to use when logging to the logging system or
|
||
the kernel log buffer. One of <option>emerg</option>, <option>alert</option>, <option>crit</option>,
|
||
<option>err</option>, <option>warning</option>, <option>notice</option>, <option>info</option>,
|
||
<option>debug</option>. See <citerefentry
|
||
project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
|
||
details. This option is only useful when <varname>StandardOutput=</varname> or
|
||
<varname>StandardError=</varname> are set to <option>journal</option>, <option>syslog</option> or
|
||
<option>kmsg</option> (or to the same settings in combination with <option>+console</option>), and only applies
|
||
to log messages written to stdout or stderr. Note that individual lines output by executed processes may be
|
||
prefixed with a different log level which can be used to override the default log level specified here. The
|
||
interpretation of these prefixes may be disabled with <varname>SyslogLevelPrefix=</varname>, see below. For
|
||
details, see <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
|
||
Defaults to <option>info</option>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>SyslogLevelPrefix=</varname></term>
|
||
|
||
<listitem><para>Takes a boolean argument. If true and <varname>StandardOutput=</varname> or
|
||
<varname>StandardError=</varname> are set to <option>journal</option>, <option>syslog</option> or
|
||
<option>kmsg</option> (or to the same settings in combination with <option>+console</option>), log lines
|
||
written by the executed process that are prefixed with a log level will be processed with this log level set
|
||
but the prefix removed. If set to false, the interpretation of these prefixes is disabled and the logged lines
|
||
are passed on as-is. This only applies to log messages written to stdout or stderr. For details about this
|
||
prefixing see <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
|
||
Defaults to true.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>TTYPath=</varname></term>
|
||
|
||
<listitem><para>Sets the terminal device node to use if standard input, output, or error are connected to a TTY
|
||
(see above). Defaults to <filename>/dev/console</filename>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>TTYReset=</varname></term>
|
||
|
||
<listitem><para>Reset the terminal device specified with <varname>TTYPath=</varname> before and after
|
||
execution. Defaults to <literal>no</literal>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>TTYVHangup=</varname></term>
|
||
|
||
<listitem><para>Disconnect all clients which have opened the terminal device specified with
|
||
<varname>TTYPath=</varname> before and after execution. Defaults to <literal>no</literal>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>TTYVTDisallocate=</varname></term>
|
||
|
||
<listitem><para>If the terminal device specified with <varname>TTYPath=</varname> is a virtual console
|
||
terminal, try to deallocate the TTY before and after execution. This ensures that the screen and scrollback
|
||
buffer is cleared. Defaults to <literal>no</literal>.</para></listitem>
|
||
</varlistentry>
|
||
</variablelist>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>System V Compatibility</title>
|
||
<variablelist>
|
||
|
||
<varlistentry>
|
||
<term><varname>UtmpIdentifier=</varname></term>
|
||
|
||
<listitem><para>Takes a four character identifier string for an <citerefentry
|
||
project='man-pages'><refentrytitle>utmp</refentrytitle><manvolnum>5</manvolnum></citerefentry> and wtmp entry
|
||
for this service. This should only be set for services such as <command>getty</command> implementations (such
|
||
as <citerefentry
|
||
project='die-net'><refentrytitle>agetty</refentrytitle><manvolnum>8</manvolnum></citerefentry>) where utmp/wtmp
|
||
entries must be created and cleared before and after execution, or for services that shall be executed as if
|
||
they were run by a <command>getty</command> process (see below). If the configured string is longer than four
|
||
characters, it is truncated and the terminal four characters are used. This setting interprets %I style string
|
||
replacements. This setting is unset by default, i.e. no utmp/wtmp entries are created or cleaned up for this
|
||
service.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>UtmpMode=</varname></term>
|
||
|
||
<listitem><para>Takes one of <literal>init</literal>, <literal>login</literal> or <literal>user</literal>. If
|
||
<varname>UtmpIdentifier=</varname> is set, controls which type of <citerefentry
|
||
project='man-pages'><refentrytitle>utmp</refentrytitle><manvolnum>5</manvolnum></citerefentry>/wtmp entries
|
||
for this service are generated. This setting has no effect unless <varname>UtmpIdentifier=</varname> is set
|
||
too. If <literal>init</literal> is set, only an <constant>INIT_PROCESS</constant> entry is generated and the
|
||
invoked process must implement a <command>getty</command>-compatible utmp/wtmp logic. If
|
||
<literal>login</literal> is set, first an <constant>INIT_PROCESS</constant> entry, followed by a
|
||
<constant>LOGIN_PROCESS</constant> entry is generated. In this case, the invoked process must implement a
|
||
<citerefentry
|
||
project='die-net'><refentrytitle>login</refentrytitle><manvolnum>1</manvolnum></citerefentry>-compatible
|
||
utmp/wtmp logic. If <literal>user</literal> is set, first an <constant>INIT_PROCESS</constant> entry, then a
|
||
<constant>LOGIN_PROCESS</constant> entry and finally a <constant>USER_PROCESS</constant> entry is
|
||
generated. In this case, the invoked process may be any process that is suitable to be run as session
|
||
leader. Defaults to <literal>init</literal>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
</variablelist>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>Environment variables in spawned processes</title>
|
||
|
||
<para>Processes started by the service manager are executed with an environment variable block assembled from
|
||
multiple sources. Processes started by the system service manager generally do not inherit environment variables
|
||
set for the service manager itself (but this may be altered via <varname>PassEnvironment=</varname>), but processes
|
||
started by the user service manager instances generally do inherit all environment variables set for the service
|
||
manager itself.</para>
|
||
|
||
<para>For each invoked process the list of environment variables set is compiled from the following sources:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem><para>Variables globally configured for the service manager, using the
|
||
<varname>DefaultEnvironment=</varname> setting in
|
||
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, the kernel command line option <varname>systemd.setenv=</varname> (see
|
||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>) or via
|
||
<command>systemctl set-environment</command> (see <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>).</para></listitem>
|
||
|
||
<listitem><para>Variables defined by the service manager itself (see the list below)</para></listitem>
|
||
|
||
<listitem><para>Variables set in the service manager's own environment variable block (subject to <varname>PassEnvironment=</varname> for the system service manager)</para></listitem>
|
||
|
||
<listitem><para>Variables set via <varname>Environment=</varname> in the unit file</para></listitem>
|
||
|
||
<listitem><para>Variables read from files specified via <varname>EnvironmentFile=</varname> in the unit file</para></listitem>
|
||
|
||
<listitem><para>Variables set by any PAM modules in case <varname>PAMName=</varname> is in effect,
|
||
cf. <citerefentry
|
||
project='man-pages'><refentrytitle>pam_env</refentrytitle><manvolnum>8</manvolnum></citerefentry></para></listitem>
|
||
</itemizedlist>
|
||
|
||
<para>If the same environment variables are set by multiple of these sources, the later source — according to the
|
||
order of the list above — wins. Note that as final step all variables listed in
|
||
<varname>UnsetEnvironment=</varname> are removed again from the compiled environment variable list, immediately
|
||
before it is passed to the executed process.</para>
|
||
|
||
<para>The following select environment variables are set or propagated by the service manager for each invoked
|
||
process:</para>
|
||
|
||
<variablelist class='environment-variables'>
|
||
<varlistentry>
|
||
<term><varname>$PATH</varname></term>
|
||
|
||
<listitem><para>Colon-separated list of directories to use
|
||
when launching executables. systemd uses a fixed value of
|
||
<filename>/usr/local/sbin</filename>:<filename>/usr/local/bin</filename>:<filename>/usr/sbin</filename>:<filename>/usr/bin</filename>:<filename>/sbin</filename>:<filename>/bin</filename>.
|
||
</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>$LANG</varname></term>
|
||
|
||
<listitem><para>Locale. Can be set in
|
||
<citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||
or on the kernel command line (see
|
||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||
and
|
||
<citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>).
|
||
</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>$USER</varname></term>
|
||
<term><varname>$LOGNAME</varname></term>
|
||
<term><varname>$HOME</varname></term>
|
||
<term><varname>$SHELL</varname></term>
|
||
|
||
<listitem><para>User name (twice), home directory, and the
|
||
login shell. The variables are set for the units that have
|
||
<varname>User=</varname> set, which includes user
|
||
<command>systemd</command> instances. See
|
||
<citerefentry project='die-net'><refentrytitle>passwd</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
||
</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>$INVOCATION_ID</varname></term>
|
||
|
||
<listitem><para>Contains a randomized, unique 128bit ID identifying each runtime cycle of the unit, formatted
|
||
as 32 character hexadecimal string. A new ID is assigned each time the unit changes from an inactive state into
|
||
an activating or active state, and may be used to identify this specific runtime cycle, in particular in data
|
||
stored offline, such as the journal. The same ID is passed to all processes run as part of the
|
||
unit.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>$XDG_RUNTIME_DIR</varname></term>
|
||
|
||
<listitem><para>The directory to use for runtime objects (such as IPC objects) and volatile state. Set for all
|
||
services run by the user <command>systemd</command> instance, as well as any system services that use
|
||
<varname>PAMName=</varname> with a PAM stack that includes <command>pam_systemd</command>. See below and
|
||
<citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> for more
|
||
information.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>$MAINPID</varname></term>
|
||
|
||
<listitem><para>The PID of the unit's main process if it is
|
||
known. This is only set for control processes as invoked by
|
||
<varname>ExecReload=</varname> and similar. </para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>$MANAGERPID</varname></term>
|
||
|
||
<listitem><para>The PID of the user <command>systemd</command>
|
||
instance, set for processes spawned by it. </para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>$LISTEN_FDS</varname></term>
|
||
<term><varname>$LISTEN_PID</varname></term>
|
||
<term><varname>$LISTEN_FDNAMES</varname></term>
|
||
|
||
<listitem><para>Information about file descriptors passed to a
|
||
service for socket activation. See
|
||
<citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
|
||
</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>$NOTIFY_SOCKET</varname></term>
|
||
|
||
<listitem><para>The socket
|
||
<function>sd_notify()</function> talks to. See
|
||
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
|
||
</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>$WATCHDOG_PID</varname></term>
|
||
<term><varname>$WATCHDOG_USEC</varname></term>
|
||
|
||
<listitem><para>Information about watchdog keep-alive notifications. See
|
||
<citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
|
||
</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>$TERM</varname></term>
|
||
|
||
<listitem><para>Terminal type, set only for units connected to
|
||
a terminal (<varname>StandardInput=tty</varname>,
|
||
<varname>StandardOutput=tty</varname>, or
|
||
<varname>StandardError=tty</varname>). See
|
||
<citerefentry project='man-pages'><refentrytitle>termcap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
||
</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>$JOURNAL_STREAM</varname></term>
|
||
|
||
<listitem><para>If the standard output or standard error output of the executed processes are connected to the
|
||
journal (for example, by setting <varname>StandardError=journal</varname>) <varname>$JOURNAL_STREAM</varname>
|
||
contains the device and inode numbers of the connection file descriptor, formatted in decimal, separated by a
|
||
colon (<literal>:</literal>). This permits invoked processes to safely detect whether their standard output or
|
||
standard error output are connected to the journal. The device and inode numbers of the file descriptors should
|
||
be compared with the values set in the environment variable to determine whether the process output is still
|
||
connected to the journal. Note that it is generally not sufficient to only check whether
|
||
<varname>$JOURNAL_STREAM</varname> is set at all as services might invoke external processes replacing their
|
||
standard output or standard error output, without unsetting the environment variable.</para>
|
||
|
||
<para>If both standard output and standard error of the executed processes are connected to the journal via a
|
||
stream socket, this environment variable will contain information about the standard error stream, as that's
|
||
usually the preferred destination for log data. (Note that typically the same stream is used for both standard
|
||
output and standard error, hence very likely the environment variable contains device and inode information
|
||
matching both stream file descriptors.)</para>
|
||
|
||
<para>This environment variable is primarily useful to allow services to optionally upgrade their used log
|
||
protocol to the native journal protocol (using
|
||
<citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry> and other
|
||
functions) if their standard output or standard error output is connected to the journal anyway, thus enabling
|
||
delivery of structured metadata along with logged messages.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>$SERVICE_RESULT</varname></term>
|
||
|
||
<listitem><para>Only defined for the service unit type, this environment variable is passed to all
|
||
<varname>ExecStop=</varname> and <varname>ExecStopPost=</varname> processes, and encodes the service
|
||
"result". Currently, the following values are defined:</para>
|
||
|
||
<table>
|
||
<title>Defined <varname>$SERVICE_RESULT</varname> values</title>
|
||
<tgroup cols='2'>
|
||
<colspec colname='result'/>
|
||
<colspec colname='meaning'/>
|
||
<thead>
|
||
<row>
|
||
<entry>Value</entry>
|
||
<entry>Meaning</entry>
|
||
</row>
|
||
</thead>
|
||
|
||
<tbody>
|
||
<row>
|
||
<entry><literal>success</literal></entry>
|
||
<entry>The service ran successfully and exited cleanly.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>protocol</literal></entry>
|
||
<entry>A protocol violation occurred: the service did not take the steps required by its unit configuration (specifically what is configured in its <varname>Type=</varname> setting).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>timeout</literal></entry>
|
||
<entry>One of the steps timed out.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>exit-code</literal></entry>
|
||
<entry>Service process exited with a non-zero exit code; see <varname>$EXIT_CODE</varname> below for the actual exit code returned.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>signal</literal></entry>
|
||
<entry>A service process was terminated abnormally by a signal, without dumping core. See <varname>$EXIT_CODE</varname> below for the actual signal causing the termination.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>core-dump</literal></entry>
|
||
<entry>A service process terminated abnormally with a signal and dumped core. See <varname>$EXIT_CODE</varname> below for the signal causing the termination.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>watchdog</literal></entry>
|
||
<entry>Watchdog keep-alive ping was enabled for the service, but the deadline was missed.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>start-limit-hit</literal></entry>
|
||
<entry>A start limit was defined for the unit and it was hit, causing the unit to fail to start. See <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s <varname>StartLimitIntervalSec=</varname> and <varname>StartLimitBurst=</varname> for details.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>resources</literal></entry>
|
||
<entry>A catch-all condition in case a system operation failed.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
|
||
<para>This environment variable is useful to monitor failure or successful termination of a service. Even
|
||
though this variable is available in both <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname>, it
|
||
is usually a better choice to place monitoring tools in the latter, as the former is only invoked for services
|
||
that managed to start up correctly, and the latter covers both services that failed during their start-up and
|
||
those which failed during their runtime.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><varname>$EXIT_CODE</varname></term>
|
||
<term><varname>$EXIT_STATUS</varname></term>
|
||
|
||
<listitem><para>Only defined for the service unit type, these environment variables are passed to all
|
||
<varname>ExecStop=</varname>, <varname>ExecStopPost=</varname> processes and contain exit status/code
|
||
information of the main process of the service. For the precise definition of the exit code and status, see
|
||
<citerefentry><refentrytitle>wait</refentrytitle><manvolnum>2</manvolnum></citerefentry>. <varname>$EXIT_CODE</varname>
|
||
is one of <literal>exited</literal>, <literal>killed</literal>,
|
||
<literal>dumped</literal>. <varname>$EXIT_STATUS</varname> contains the numeric exit code formatted as string
|
||
if <varname>$EXIT_CODE</varname> is <literal>exited</literal>, and the signal name in all other cases. Note
|
||
that these environment variables are only set if the service manager succeeded to start and identify the main
|
||
process of the service.</para>
|
||
|
||
<table>
|
||
<title>Summary of possible service result variable values</title>
|
||
<tgroup cols='3'>
|
||
<colspec colname='result' />
|
||
<colspec colname='code' />
|
||
<colspec colname='status' />
|
||
<thead>
|
||
<row>
|
||
<entry><varname>$SERVICE_RESULT</varname></entry>
|
||
<entry><varname>$EXIT_CODE</varname></entry>
|
||
<entry><varname>$EXIT_STATUS</varname></entry>
|
||
</row>
|
||
</thead>
|
||
|
||
<tbody>
|
||
<row>
|
||
<entry valign="top"><literal>success</literal></entry>
|
||
<entry valign="top"><literal>exited</literal></entry>
|
||
<entry><literal>0</literal></entry>
|
||
</row>
|
||
<row>
|
||
<entry morerows="1" valign="top"><literal>protocol</literal></entry>
|
||
<entry valign="top">not set</entry>
|
||
<entry>not set</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>exited</literal></entry>
|
||
<entry><literal>0</literal></entry>
|
||
</row>
|
||
<row>
|
||
<entry morerows="1" valign="top"><literal>timeout</literal></entry>
|
||
<entry valign="top"><literal>killed</literal></entry>
|
||
<entry><literal>TERM</literal>, <literal>KILL</literal></entry>
|
||
</row>
|
||
<row>
|
||
<entry valign="top"><literal>exited</literal></entry>
|
||
<entry><literal>0</literal>, <literal>1</literal>, <literal>2</literal>, <literal
|
||
>3</literal>, …, <literal>255</literal></entry>
|
||
</row>
|
||
<row>
|
||
<entry valign="top"><literal>exit-code</literal></entry>
|
||
<entry valign="top"><literal>exited</literal></entry>
|
||
<entry><literal>1</literal>, <literal>2</literal>, <literal
|
||
>3</literal>, …, <literal>255</literal></entry>
|
||
</row>
|
||
<row>
|
||
<entry valign="top"><literal>signal</literal></entry>
|
||
<entry valign="top"><literal>killed</literal></entry>
|
||
<entry><literal>HUP</literal>, <literal>INT</literal>, <literal>KILL</literal>, …</entry>
|
||
</row>
|
||
<row>
|
||
<entry valign="top"><literal>core-dump</literal></entry>
|
||
<entry valign="top"><literal>dumped</literal></entry>
|
||
<entry><literal>ABRT</literal>, <literal>SEGV</literal>, <literal>QUIT</literal>, …</entry>
|
||
</row>
|
||
<row>
|
||
<entry morerows="2" valign="top"><literal>watchdog</literal></entry>
|
||
<entry><literal>dumped</literal></entry>
|
||
<entry><literal>ABRT</literal></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>killed</literal></entry>
|
||
<entry><literal>TERM</literal>, <literal>KILL</literal></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>exited</literal></entry>
|
||
<entry><literal>0</literal>, <literal>1</literal>, <literal>2</literal>, <literal
|
||
>3</literal>, …, <literal>255</literal></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>start-limit-hit</literal></entry>
|
||
<entry>not set</entry>
|
||
<entry>not set</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>resources</literal></entry>
|
||
<entry>any of the above</entry>
|
||
<entry>any of the above</entry>
|
||
</row>
|
||
<row>
|
||
<entry namest="results" nameend="status">Note: the process may be also terminated by a signal not sent by systemd. In particular the process may send an arbitrary signal to itself in a handler for any of the non-maskable signals. Nevertheless, in the <literal>timeout</literal> and <literal>watchdog</literal> rows above only the signals that systemd sends have been included. Moreover, using <varname>SuccessExitStatus=</varname> additional exit statuses may be declared to indicate clean termination, which is not reflected by this table.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
|
||
</listitem>
|
||
</varlistentry>
|
||
</variablelist>
|
||
|
||
<para>For system services, when <varname>PAMName=</varname> is enabled and <command>pam_systemd</command> is part
|
||
of the selected PAM stack, additional environment variables defined by systemd may be set for
|
||
services. Specifically, these are <varname>$XDG_SEAT</varname>, <varname>$XDG_VTNR</varname>, see
|
||
<citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> for details.</para>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>Process exit codes</title>
|
||
|
||
<para>When invoking a unit process the service manager possibly fails to apply the execution parameters configured
|
||
with the settings above. In that case the already created service process will exit with a non-zero exit code
|
||
before the configured command line is executed. (Or in other words, the child process possibly exits with these
|
||
error codes, after having been created by the <citerefentry
|
||
project='man-pages'><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call, but
|
||
before the matching <citerefentry
|
||
project='man-pages'><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call is
|
||
called.) Specifically, exit codes defined by the C library, by the LSB specification and by the systemd service
|
||
manager itself are used.</para>
|
||
|
||
<para>The following basic service exit codes are defined by the C library.</para>
|
||
|
||
<table>
|
||
<title>Basic C library exit codes</title>
|
||
<tgroup cols='3'>
|
||
<thead>
|
||
<row>
|
||
<entry>Exit Code</entry>
|
||
<entry>Symbolic Name</entry>
|
||
<entry>Description</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry>0</entry>
|
||
<entry><constant>EXIT_SUCCESS</constant></entry>
|
||
<entry>Generic success code.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>1</entry>
|
||
<entry><constant>EXIT_FAILURE</constant></entry>
|
||
<entry>Generic failure or unspecified error.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
|
||
<para>The following service exit codes are defined by the <ulink
|
||
url="https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB specification
|
||
</ulink>.
|
||
</para>
|
||
|
||
<table>
|
||
<title>LSB service exit codes</title>
|
||
<tgroup cols='3'>
|
||
<thead>
|
||
<row>
|
||
<entry>Exit Code</entry>
|
||
<entry>Symbolic Name</entry>
|
||
<entry>Description</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry>2</entry>
|
||
<entry><constant>EXIT_INVALIDARGUMENT</constant></entry>
|
||
<entry>Invalid or excess arguments.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>3</entry>
|
||
<entry><constant>EXIT_NOTIMPLEMENTED</constant></entry>
|
||
<entry>Unimplemented feature.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>4</entry>
|
||
<entry><constant>EXIT_NOPERMISSION</constant></entry>
|
||
<entry>The user has insufficient privileges.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>5</entry>
|
||
<entry><constant>EXIT_NOTINSTALLED</constant></entry>
|
||
<entry>The program is not installed.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>6</entry>
|
||
<entry><constant>EXIT_NOTCONFIGURED</constant></entry>
|
||
<entry>The program is not configured.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>7</entry>
|
||
<entry><constant>EXIT_NOTRUNNING</constant></entry>
|
||
<entry>The program is not running.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
|
||
<para>
|
||
The LSB specification suggests that error codes 200 and above are reserved for implementations. Some of them are
|
||
used by the service manager to indicate problems during process invocation:
|
||
</para>
|
||
<table>
|
||
<title>systemd-specific exit codes</title>
|
||
<tgroup cols='3'>
|
||
<thead>
|
||
<row>
|
||
<entry>Exit Code</entry>
|
||
<entry>Symbolic Name</entry>
|
||
<entry>Description</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry>200</entry>
|
||
<entry><constant>EXIT_CHDIR</constant></entry>
|
||
<entry>Changing to the requested working directory failed. See <varname>WorkingDirectory=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>201</entry>
|
||
<entry><constant>EXIT_NICE</constant></entry>
|
||
<entry>Failed to set up process scheduling priority (nice level). See <varname>Nice=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>202</entry>
|
||
<entry><constant>EXIT_FDS</constant></entry>
|
||
<entry>Failed to close unwanted file descriptors, or to adjust passed file descriptors.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>203</entry>
|
||
<entry><constant>EXIT_EXEC</constant></entry>
|
||
<entry>The actual process execution failed (specifically, the <citerefentry project='man-pages'><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call). Most likely this is caused by a missing or non-accessible executable file.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>204</entry>
|
||
<entry><constant>EXIT_MEMORY</constant></entry>
|
||
<entry>Failed to perform an action due to memory shortage.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>205</entry>
|
||
<entry><constant>EXIT_LIMITS</constant></entry>
|
||
<entry>Failed to adjust resource limits. See <varname>LimitCPU=</varname> and related settings above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>206</entry>
|
||
<entry><constant>EXIT_OOM_ADJUST</constant></entry>
|
||
<entry>Failed to adjust the OOM setting. See <varname>OOMScoreAdjust=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>207</entry>
|
||
<entry><constant>EXIT_SIGNAL_MASK</constant></entry>
|
||
<entry>Failed to set process signal mask.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>208</entry>
|
||
<entry><constant>EXIT_STDIN</constant></entry>
|
||
<entry>Failed to set up standard input. See <varname>StandardInput=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>209</entry>
|
||
<entry><constant>EXIT_STDOUT</constant></entry>
|
||
<entry>Failed to set up standard output. See <varname>StandardOutput=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>210</entry>
|
||
<entry><constant>EXIT_CHROOT</constant></entry>
|
||
<entry>Failed to change root directory (<citerefentry project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>). See <varname>RootDirectory=</varname>/<varname>RootImage=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>211</entry>
|
||
<entry><constant>EXIT_IOPRIO</constant></entry>
|
||
<entry>Failed to set up IO scheduling priority. See <varname>IOSchedulingClass=</varname>/<varname>IOSchedulingPriority=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>212</entry>
|
||
<entry><constant>EXIT_TIMERSLACK</constant></entry>
|
||
<entry>Failed to set up timer slack. See <varname>TimerSlackNSec=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>213</entry>
|
||
<entry><constant>EXIT_SECUREBITS</constant></entry>
|
||
<entry>Failed to set process secure bits. See <varname>SecureBits=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>214</entry>
|
||
<entry><constant>EXIT_SETSCHEDULER</constant></entry>
|
||
<entry>Failed to set up CPU scheduling. See <varname>CPUSchedulingPolicy=</varname>/<varname>CPUSchedulingPriority=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>215</entry>
|
||
<entry><constant>EXIT_CPUAFFINITY</constant></entry>
|
||
<entry>Failed to set up CPU affinity. See <varname>CPUAffinity=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>216</entry>
|
||
<entry><constant>EXIT_GROUP</constant></entry>
|
||
<entry>Failed to determine or change group credentials. See <varname>Group=</varname>/<varname>SupplementaryGroups=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>217</entry>
|
||
<entry><constant>EXIT_USER</constant></entry>
|
||
<entry>Failed to determine or change user credentials, or to set up user namespacing. See <varname>User=</varname>/<varname>PrivateUsers=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>218</entry>
|
||
<entry><constant>EXIT_CAPABILITIES</constant></entry>
|
||
<entry>Failed to drop capabilities, or apply ambient capabilities. See <varname>CapabilityBoundingSet=</varname>/<varname>AmbientCapabilities=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>219</entry>
|
||
<entry><constant>EXIT_CGROUP</constant></entry>
|
||
<entry>Setting up the service control group failed.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>220</entry>
|
||
<entry><constant>EXIT_SETSID</constant></entry>
|
||
<entry>Failed to create new process session.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>221</entry>
|
||
<entry><constant>EXIT_CONFIRM</constant></entry>
|
||
<entry>Execution has been cancelled by the user. See the <varname>systemd.confirm_spawn=</varname> kernel command line setting on <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>222</entry>
|
||
<entry><constant>EXIT_STDERR</constant></entry>
|
||
<entry>Failed to set up standard error output. See <varname>StandardError=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>224</entry>
|
||
<entry><constant>EXIT_PAM</constant></entry>
|
||
<entry>Failed to set up PAM session. See <varname>PAMName=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>225</entry>
|
||
<entry><constant>EXIT_NETWORK</constant></entry>
|
||
<entry>Failed to set up network namespacing. See <varname>PrivateNetwork=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>226</entry>
|
||
<entry><constant>EXIT_NAMESPACE</constant></entry>
|
||
<entry>Failed to set up mount namespacing. See <varname>ReadOnlyPaths=</varname> and related settings above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>227</entry>
|
||
<entry><constant>EXIT_NO_NEW_PRIVILEGES</constant></entry>
|
||
<entry>Failed to disable new privileges. See <varname>NoNewPrivileges=yes</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>228</entry>
|
||
<entry><constant>EXIT_SECCOMP</constant></entry>
|
||
<entry>Failed to apply system call filters. See <varname>SystemCallFilter=</varname> and related settings above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>229</entry>
|
||
<entry><constant>EXIT_SELINUX_CONTEXT</constant></entry>
|
||
<entry>Determining or changing SELinux context failed. See <varname>SELinuxContext=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>230</entry>
|
||
<entry><constant>EXIT_PERSONALITY</constant></entry>
|
||
<entry>Failed to set up an execution domain (personality). See <varname>Personality=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>231</entry>
|
||
<entry><constant>EXIT_APPARMOR_PROFILE</constant></entry>
|
||
<entry>Failed to prepare changing AppArmor profile. See <varname>AppArmorProfile=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>232</entry>
|
||
<entry><constant>EXIT_ADDRESS_FAMILIES</constant></entry>
|
||
<entry>Failed to restrict address families. See <varname>RestrictAddressFamilies=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>233</entry>
|
||
<entry><constant>EXIT_RUNTIME_DIRECTORY</constant></entry>
|
||
<entry>Setting up runtime directory failed. See <varname>RuntimeDirectory=</varname> and related settings above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>235</entry>
|
||
<entry><constant>EXIT_CHOWN</constant></entry>
|
||
<entry>Failed to adjust socket ownership. Used for socket units only.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>236</entry>
|
||
<entry><constant>EXIT_SMACK_PROCESS_LABEL</constant></entry>
|
||
<entry>Failed to set SMACK label. See <varname>SmackProcessLabel=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>237</entry>
|
||
<entry><constant>EXIT_KEYRING</constant></entry>
|
||
<entry>Failed to set up kernel keyring.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>238</entry>
|
||
<entry><constant>EXIT_STATE_DIRECTORY</constant></entry>
|
||
<entry>Failed to set up unit's state directory. See <varname>StateDirectory=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>239</entry>
|
||
<entry><constant>EXIT_CACHE_DIRECTORY</constant></entry>
|
||
<entry>Failed to set up unit's cache directory. See <varname>CacheDirectory=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>240</entry>
|
||
<entry><constant>EXIT_LOGS_DIRECTORY</constant></entry>
|
||
<entry>Failed to set up unit's logging directory. See <varname>LogsDirectory=</varname> above.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>241</entry>
|
||
<entry><constant>EXIT_CONFIGURATION_DIRECTORY</constant></entry>
|
||
<entry>Failed to set up unit's configuration directory. See <varname>ConfigurationDirectory=</varname> above.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
|
||
<para>Finally, the BSD operating systems define a set of exit codes, typically defined on Linux systems too:</para>
|
||
|
||
<table>
|
||
<title>BSD exit codes</title>
|
||
<tgroup cols='3'>
|
||
<thead>
|
||
<row>
|
||
<entry>Exit Code</entry>
|
||
<entry>Symbolic Name</entry>
|
||
<entry>Description</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry>64</entry>
|
||
<entry><constant>EX_USAGE</constant></entry>
|
||
<entry>Command line usage error</entry>
|
||
</row>
|
||
<row>
|
||
<entry>65</entry>
|
||
<entry><constant>EX_DATAERR</constant></entry>
|
||
<entry>Data format error</entry>
|
||
</row>
|
||
<row>
|
||
<entry>66</entry>
|
||
<entry><constant>EX_NOINPUT</constant></entry>
|
||
<entry>Cannot open input</entry>
|
||
</row>
|
||
<row>
|
||
<entry>67</entry>
|
||
<entry><constant>EX_NOUSER</constant></entry>
|
||
<entry>Addressee unknown</entry>
|
||
</row>
|
||
<row>
|
||
<entry>68</entry>
|
||
<entry><constant>EX_NOHOST</constant></entry>
|
||
<entry>Host name unknown</entry>
|
||
</row>
|
||
<row>
|
||
<entry>69</entry>
|
||
<entry><constant>EX_UNAVAILABLE</constant></entry>
|
||
<entry>Service unavailable</entry>
|
||
</row>
|
||
<row>
|
||
<entry>70</entry>
|
||
<entry><constant>EX_SOFTWARE</constant></entry>
|
||
<entry>internal software error</entry>
|
||
</row>
|
||
<row>
|
||
<entry>71</entry>
|
||
<entry><constant>EX_OSERR</constant></entry>
|
||
<entry>System error (e.g., can't fork)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>72</entry>
|
||
<entry><constant>EX_OSFILE</constant></entry>
|
||
<entry>Critical OS file missing</entry>
|
||
</row>
|
||
<row>
|
||
<entry>73</entry>
|
||
<entry><constant>EX_CANTCREAT</constant></entry>
|
||
<entry>Can't create (user) output file</entry>
|
||
</row>
|
||
<row>
|
||
<entry>74</entry>
|
||
<entry><constant>EX_IOERR</constant></entry>
|
||
<entry>Input/output error</entry>
|
||
</row>
|
||
<row>
|
||
<entry>75</entry>
|
||
<entry><constant>EX_TEMPFAIL</constant></entry>
|
||
<entry>Temporary failure; user is invited to retry</entry>
|
||
</row>
|
||
<row>
|
||
<entry>76</entry>
|
||
<entry><constant>EX_PROTOCOL</constant></entry>
|
||
<entry>Remote error in protocol</entry>
|
||
</row>
|
||
<row>
|
||
<entry>77</entry>
|
||
<entry><constant>EX_NOPERM</constant></entry>
|
||
<entry>Permission denied</entry>
|
||
</row>
|
||
<row>
|
||
<entry>78</entry>
|
||
<entry><constant>EX_CONFIG</constant></entry>
|
||
<entry>Configuration error</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<title>See Also</title>
|
||
<para>
|
||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
|
||
<citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
||
<citerefentry project='man-pages'><refentrytitle>exec</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||
</para>
|
||
</refsect1>
|
||
|
||
</refentry>
|