]> git.ipfire.org Git - thirdparty/systemd.git/blobdiff - man/systemd.exec.xml
man: document that PAMName= and NotifyAccess=all don't mix well.
[thirdparty/systemd.git] / man / systemd.exec.xml
index c31ab980fc4733f56b5d99c41d36c3f6805e699a..06ae6b3252916c3f444272d32f92ccd06db46e03 100644 (file)
   </refsect1>
 
   <refsect1>
-    <title>Automatic Dependencies</title>
-
-    <para>A few execution parameters result in additional, automatic
-    dependencies to be added.</para>
-
-    <para>Units with <varname>WorkingDirectory=</varname>, <varname>RootDirectory=</varname> or
-    <varname>RootImage=</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>
-
-    <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>
-
-    <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>
+    <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>Options</title>
 
         <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 numeric ID as argument. For system services (services run by the system service manager,
+        user or group name, or 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></listitem>
+        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>
       <varlistentry>
         <term><varname>PassEnvironment=</varname></term>
 
-        <listitem><para>Pass environment variables from the systemd system
-        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 set. If the empty string is assigned to this
-        option, the list of environment variables is reset, all prior
-        assignments have no effect. Variables that are not set in the system
-        manager will not be passed and will be silently ignored.</para>
+        <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 passed from this setting are overridden by those passed
-        from <varname>Environment=</varname> or
-        <varname>EnvironmentFile=</varname>.</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>
         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>
+
       <varlistentry>
         <term><varname>StandardInput=</varname></term>
         <listitem><para>Controls where file descriptor 0 (STDIN) of
 
         <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 automatic dependencies section above).</para>
+        <filename>systemd-journald.socket</filename> (also see the "Implicit Dependencies" section above).</para>
 
         <para>This setting defaults to the value set with
         <option>DefaultStandardOutput=</option> in
         <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></listitem>
+        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>
 
       <varlistentry>
         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. 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
+        once, in which case the bounding sets are merged by <constant>AND</constant>, or by <constant>OR</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></listitem>
+        <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>
         <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.  If the list of capabilities is prefixed with
+        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
         <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></listitem>
+        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 /dev namespace for the executed processes and
-        only adds API pseudo devices such as <filename>/dev/null</filename>, <filename>/dev/zero</filename> or
+        <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
         <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 /dev namespace will be
-        mounted read-only and 'noexec'.  The latter may break old programs which try to set up executable memory by
+        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>. 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.
+        <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></listitem>
+        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>
         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
-        securely turn off network access by the executed process.
+        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
         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></listitem>
+        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>
         <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></listitem>
+        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>
                 <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>@credentials</entry>
+                <entry>System calls for querying process credentials (<citerefentry project='man-pages'><refentrytitle>getuid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>capget</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>
                 <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>
                 <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>@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>
         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>SystemCallFilter=native</varname> is a good choice for disabling non-native ABIs.</para>
+        <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
         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 tilda character (<literal>~</literal>) the
+        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. Internally, this setting limits access to the
         personality of the host system's kernel.</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>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 the system service manager and to <option>inherit</option> for the user service
+        manager.</para></listitem>
+      </varlistentry>
+
       <varlistentry>
         <term><varname>RuntimeDirectory=</varname></term>
 
-        <listitem><para>Takes a list of directory names. If set, one
-        or more directories by the specified names will be created
-        below <filename>/run</filename> (for system services) or below
-        <varname>$XDG_RUNTIME_DIR</varname> (for user services) when
-        the unit is started, and removed when the unit is stopped. The
-        directories will have the access mode specified in
-        <varname>RuntimeDirectoryMode=</varname>, and will be owned by
-        the user and group specified in <varname>User=</varname> and
-        <varname>Group=</varname>. Use this to manage one or more
-        runtime directories of the unit and bind their lifetime to the
-        daemon runtime. The specified directory names must be
-        relative, and may not include a <literal>/</literal>, i.e.
-        must refer to simple directories to create or remove. 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></listitem>
+        <listitem><para>Takes 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
+        including their parents by the specified names will be created below <filename>/run</filename> (for system
+        services) or below <varname>$XDG_RUNTIME_DIR</varname> (for user services) when the unit is started. The
+        lowest subdirectories are removed when the unit is stopped. It is possible to preserve the directories if
+        <varname>RuntimeDirectoryPreserve=</varname> is configured to <option>restart</option> or <option>yes</option>.
+        The lowest subdirectories will have the access mode specified in <varname>RuntimeDirectoryMode=</varname>,
+        and be owned by the user and group specified in <varname>User=</varname> and <varname>Group=</varname>.
+        This implies <varname>ReadWritePaths=</varname>, that is, the directories specified
+        in this option are accessible with the access mode specified in <varname>RuntimeDirectoryMode=</varname>
+        even if <varname>ProtectSystem=</varname> is set to <option>strict</option>.
+        Use this to manage one or more runtime directories of 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>StateDirectory=</varname></term>
+        <term><varname>CacheDirectory=</varname></term>
+        <term><varname>LogsDirectory=</varname></term>
+        <term><varname>ConfigurationDirectory=</varname></term>
+
+        <listitem><para>Takes a whitespace-separated list of directory names. If set, as similar to
+        <varname>RuntimeDirectory=</varname>, one or more directories including their parents by the specified names
+        will be created below <filename>/var/lib</filename>, <filename>/var/cache</filename>, <filename>/var/log</filename>,
+        or <filename>/etc</filename>, respectively, when the unit is started.
+        Unlike <varname>RuntimeDirectory=</varname>, the directories are not removed when the unit is stopped.
+        The lowest subdirectories will be owned by the user and group specified in <varname>User=</varname>
+        and <varname>Group=</varname>. The options imply <varname>ReadWritePaths=</varname>.
+        </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> 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.
+        <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>
 
         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>
+        (e.g. setting <varname>User=</varname>), <varname>NoNewPrivileges=yes</varname> is implied.</para></listitem>
       </varlistentry>
 
       <varlistentry>
   <refsect1>
     <title>Environment variables in spawned processes</title>
 
-    <para>Processes started by the system are executed in a clean
-    environment in which select variables listed below are set. System
-    processes started by systemd do not inherit variables from PID 1,
-    but processes started by user systemd instances inherit all
-    environment variables from the user systemd instance.
-    </para>
+    <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>EnvironmentFiles=</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 by the service manager itself for each invoked process:</para>
 
     <variablelist class='environment-variables'>
       <varlistentry>
         <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
 
         <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: <literal>protocol</literal> (in case of a protocol
-        violation; if a service did not take the steps required by its unit configuration), <literal>timeout</literal>
-        (in case of an operation timeout), <literal>exit-code</literal> (if a service process exited with a non-zero
-        exit code; see <varname>$EXIT_CODE</varname> below for the actual exit code returned), <literal>signal</literal>
-        (if a service process was terminated abnormally by a signal; see <varname>$EXIT_CODE</varname> below for the
-        actual signal used for the termination), <literal>core-dump</literal> (if a service process terminated
-        abnormally and dumped core), <literal>watchdog</literal> (if the watchdog keep-alive ping was enabled for the
-        service but it missed the deadline), or <literal>resources</literal> (a catch-all condition in case a system
-        operation failed).</para>
+        "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
             </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><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>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>0</literal>, <literal>1</literal>, <literal>2</literal>, <literal
+                <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>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="code">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.</entry>
+                <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>
         </listitem>
       </varlistentry>
     </variablelist>
+  </refsect1>
 
-    <para>Additional variables may be configured by the following
-    means: for processes spawned in specific units, use the
-    <varname>Environment=</varname>, <varname>EnvironmentFile=</varname>
-    and <varname>PassEnvironment=</varname> options above; to specify
-    variables globally, use <varname>DefaultEnvironment=</varname>
-    (see
-    <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
-    or the kernel option <varname>systemd.setenv=</varname> (see
-    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>).
-    Additional variables may also be set through PAM,
-    cf. <citerefentry project='man-pages'><refentrytitle>pam_env</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+  <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 resoure 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 priviliges. 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 a 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 a the 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 a the 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 a the 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 a the unit's configuration directory. See <varname>ConfigurationDirectory=</varname> above.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
   </refsect1>
 
   <refsect1>