chiark / gitweb /
networkd: support vxlan parameters
[elogind.git] / man / systemd.service.xml
index f43201d..da9079c 100644 (file)
@@ -48,7 +48,7 @@
         </refnamediv>
 
         <refsynopsisdiv>
-                <para><filename>systemd.service</filename></para>
+                <para><filename><replaceable>service</replaceable>.service</filename></para>
         </refsynopsisdiv>
 
         <refsect1>
                 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
                 which define the execution environment the commands
                 are executed in, and in
-                <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+                <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
                 which define the way the processes of the service are
-                terminated.</para>
+                terminated, and in
+                <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+                which configure resource control settings for the
+                processes of the service.</para>
 
                 <para>Unless <varname>DefaultDependencies=</varname>
                 is set to <option>false</option>, service units will
                 script. This is useful for compatibility with
                 SysV. Note that this compatibility is quite
                 comprehensive but not 100%. For details about the
-                incomptibilities see the <ulink
+                incompatibilities, see the <ulink
                 url="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
                 with SysV</ulink> document.
                 </para>
                 options specific to the <literal>[Service]</literal>
                 section of service units are the following:</para>
 
-                <variablelist>
+                <variablelist class='unit-directives'>
                         <varlistentry>
                                 <term><varname>Type=</varname></term>
 
 
                                 <para>If set to
                                 <option>simple</option> (the default
-                                value if <varname>BusName=</varname>
-                                is not specified) it is expected that
-                                the process configured with
+                                if neither
+                                <varname>Type=</varname> nor
+                                <varname>BusName=</varname>, but
+                                <varname>ExecStart=</varname> are
+                                specified), it is expected that the
+                                process configured with
                                 <varname>ExecStart=</varname> is the
                                 main process of the service. In this
                                 mode, if the process offers
                                 functionality to other processes on
-                                the system its communication channels
+                                the system, its communication channels
                                 should be installed before the daemon
                                 is started up (e.g. sockets set up by
                                 systemd, via socket activation), as
                                 starting follow-up units.</para>
 
                                 <para>If set to
-                                <option>forking</option> it is
+                                <option>forking</option>, it is
                                 expected that the process configured
                                 with <varname>ExecStart=</varname>
                                 will call <function>fork()</function>
                                 as part of its start-up. The parent process is
                                 expected to exit when start-up is
                                 complete and all communication
-                                channels set up. The child continues
+                                channels are set up. The child continues
                                 to run as the main daemon
-                                process. This is the behaviour of
+                                process. This is the behavior of
                                 traditional UNIX daemons. If this
                                 setting is used, it is recommended to
                                 also use the
                                 <varname>PIDFile=</varname> option, so
                                 that systemd can identify the main
                                 process of the daemon. systemd will
-                                proceed starting follow-up units as
-                                soon as the parent process
+                                proceed with starting follow-up units
+                                as soon as the parent process
                                 exits.</para>
 
-                                <para>Behaviour of
-                                <option>oneshot</option> is similar
-                                to <option>simple</option>, however
-                                it is expected that the process has to
+                                <para>Behavior of
+                                <option>oneshot</option> is similar to
+                                <option>simple</option>; however, it
+                                is expected that the process has to
                                 exit before systemd starts follow-up
                                 units. <varname>RemainAfterExit=</varname>
                                 is particularly useful for this type
-                                of service.</para>
+                                of service. This is the implied
+                                default if neither
+                                <varname>Type=</varname> or
+                                <varname>ExecStart=</varname> are
+                                specified.</para>
 
-                                <para>Behaviour of
+                                <para>Behavior of
                                 <option>dbus</option> is similar to
-                                <option>simple</option>, however it is
+                                <option>simple</option>; however, it is
                                 expected that the daemon acquires a
                                 name on the D-Bus bus, as configured
                                 by
                                 <varname>BusName=</varname>. systemd
-                                will proceed starting follow-up units
-                                after the D-Bus bus name has been
+                                will proceed with starting follow-up
+                                units after the D-Bus bus name has been
                                 acquired. Service units with this
                                 option configured implicitly gain
                                 dependencies on the
                                 <varname>BusName=</varname> is
                                 specified.</para>
 
-                                <para>Behaviour of
+                                <para>Behavior of
                                 <option>notify</option> is similar to
-                                <option>simple</option>, however it is
+                                <option>simple</option>; however, it is
                                 expected that the daemon sends a
                                 notification message via
                                 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
-                                or an equivalent call when it finished
-                                starting up. systemd will proceed
+                                or an equivalent call when it has finished
+                                starting up. systemd will proceed with
                                 starting follow-up units after this
                                 notification message has been sent. If
-                                this option is used
+                                this option is used,
                                 <varname>NotifyAccess=</varname> (see
                                 below) should be set to open access to
                                 the notification socket provided by
                                 systemd. If
                                 <varname>NotifyAccess=</varname> is
                                 not set, it will be implicitly set to
-                                <option>main</option>.</para>
+                                <option>main</option>. Note that
+                                currently
+                                <varname>Type=</varname><option>notify</option>
+                                will not work if used in combination with
+                                <varname>PrivateNetwork=</varname><option>yes</option>.</para>
 
-                                <para>Behaviour of
+                                <para>Behavior of
                                 <option>idle</option> is very similar
-                                to <option>simple</option>, however
-                                actual execution of the service
+                                to <option>simple</option>; however,
+                                actual execution of the service
                                 binary is delayed until all jobs are
                                 dispatched. This may be used to avoid
                                 interleaving of output of shell
                                 <listitem><para>Takes a boolean value
                                 that specifies whether systemd should
                                 try to guess the main PID of a service
-                                should if it cannot be determined
+                                if it cannot be determined
                                 reliably. This option is ignored
                                 unless <option>Type=forking</option>
                                 is set and <option>PIDFile=</option>
                                 is unset because for the other types
                                 or with an explicitly configured PID
-                                file the main PID is always known. The
+                                file, the main PID is always known. The
                                 guessing algorithm might come to
                                 incorrect conclusions if a daemon
                                 consists of more than one process. If
-                                the main PID cannot be determined
+                                the main PID cannot be determined,
                                 failure detection and automatic
                                 restarting of a service will not work
                                 reliably. Defaults to
                                 <term><varname>BusName=</varname></term>
 
                                 <listitem><para>Takes a D-Bus bus
-                                name, where this service is reachable
+                                name that this service is reachable
                                 as. This option is mandatory for
                                 services where
                                 <varname>Type=</varname> is set to
-                                <option>dbus</option>, but its use
-                                is otherwise recommended as well if
-                                the process takes a name on the D-Bus
-                                bus.</para>
+                                <option>dbus</option>.</para>
+                                </listitem>
+                        </varlistentry>
+
+                        <varlistentry>
+                                <term><varname>BusPolicy=</varname></term>
+
+                                <listitem><para>If specified, a custom
+                                <ulink url="https://code.google.com/p/d-bus/">kdbus</ulink>
+                                endpoint will be created and installed as the
+                                default bus node for the service. Such a custom
+                                endpoint can hold an own set of policy rules
+                                that are enforced on top of the bus-wide ones.
+                                The custom endpoint is named after the service
+                                it was created for, and its node will be
+                                bind-mounted over the default bus node
+                                location, so the service can only access the
+                                bus through its own endpoint. Note that custom
+                                bus endpoints default to a 'deny all' policy.
+                                Hence, if at least one
+                                <varname>BusPolicy=</varname> directive is
+                                given, you have to make sure to add explicit
+                                rules for everything the service should be able
+                                to do.</para>
+                                <para>The value of this directive is comprised
+                                of two parts; the bus name, and a verb to
+                                specify to granted access, which is one of
+                                <option>see</option>,
+                                <option>talk</option>, or
+                                <option>own</option>.
+                                <option>talk</option> implies
+                                <option>see</option>, and <option>own</option>
+                                implies both <option>talk</option> and
+                                <option>see</option>.
+                                If multiple access levels are specified for the
+                                same bus name, the most powerful one takes
+                                effect.
+                                </para>
+                                <para>Examples:</para>
+                                <programlisting>BusPolicy=org.freedesktop.systemd1 talk</programlisting>
+                                <programlisting>BusPolicy=org.foo.bar see</programlisting>
+                                <para>This option is only available on kdbus enabled systems.</para>
                                 </listitem>
                         </varlistentry>
 
                         <varlistentry>
                                 <term><varname>ExecStart=</varname></term>
-                                <listitem><para>Takes a command line
-                                that is executed when this service
-                                shall be started up. The first token
-                                of the command line must be an
-                                absolute file name, then followed by
-                                arguments for the process. It is
-                                mandatory to set this option for all
-                                services. This option may not be
-                                specified more than once, except when
+                                <listitem><para>Commands with their
+                                arguments that are executed when this
+                                service is started. The value is split
+                                into zero or more command lines is
+                                according to the rules described below
+                                (see section "Command Lines" below).
+                                </para>
+
+                                <para>When <varname>Type</varname> is
+                                not <option>oneshot</option>, only one
+                                command may and must be given. When
                                 <varname>Type=oneshot</varname> is
-                                used in which case more than one
-                                <varname>ExecStart=</varname> line is
-                                accepted which are then invoked one by
-                                one, sequentially in the order they
-                                appear in the unit file.</para>
-
-                                <para>Optionally, if the absolute file
-                                name is prefixed with
+                                used, zero or more commands may be
+                                specified. This can be specified by
+                                providing multiple command lines in
+                                the same directive, or alternatively,
+                                this directive may be specified more
+                                than once with the same effect. If the
+                                empty string is assigned to this
+                                option, the list of commands to start
+                                is reset, prior assignments of this
+                                option will have no effect. If no
+                                <varname>ExecStart=</varname> is
+                                specified, then the service must have
+                                <varname>RemainAfterExit=yes</varname>
+                                set.</para>
+
+                                <para>For each of the specified
+                                commands, the first argument must be
+                                an absolute and literal path to an
+                                executable. Optionally, if the
+                                absolute file name is prefixed with
                                 <literal>@</literal>, the second token
                                 will be passed as
                                 <literal>argv[0]</literal> to the
                                 executed process, followed by the
                                 further arguments specified. If the
-                                first token is prefixed with
-                                <literal>-</literal> an exit code of
+                                absolute filename is prefixed with
+                                <literal>-</literal>, an exit code of
                                 the command normally considered a
                                 failure (i.e. non-zero exit status or
-                                abnormal exit due to signal) is ignored
-                                and considered success. If both
-                                <literal>-</literal> and
-                                <literal>@</literal> are used for the
-                                same command the former must precede
-                                the latter. Unless
+                                abnormal exit due to signal) is
+                                ignored and considered success. If
+                                both <literal>-</literal> and
+                                <literal>@</literal> are used, they
+                                can appear in either order.</para>
+
+                                <para>If more than one command is
+                                specified, the commands are invoked
+                                sequentially in the order they appear
+                                in the unit file. If one of the
+                                commands fails (and is not prefixed
+                                with <literal>-</literal>), other
+                                lines are not executed, and the unit
+                                is considered failed.</para>
+
+                                <para>Unless
                                 <varname>Type=forking</varname> is
                                 set, the process started via this
                                 command line will be considered the
-                                main process of the daemon. The
-                                command line accepts % specifiers as
-                                described in
-                                <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+                                main process of the daemon.</para>
 
-                                <para>On top of that basic environment
-                                variable substitution is
-                                supported. Use
-                                <literal>${FOO}</literal> as part of a
-                                word, or as word of its own on the
-                                command line, in which case it will be
-                                replaced by the value of the
-                                environment variable including all
-                                whitespace it contains, resulting in a
-                                single argument.  Use
-                                <literal>$FOO</literal> as a separate
-                                word on the command line, in which
-                                case it will be replaced by the value
-                                of the environment variable split up
-                                at whitespace, resulting in no or more
-                                arguments. Note that the first
-                                argument (i.e. the program to execute)
-                                may not be a variable, and must be a
-                                literal and absolute path
-                                name.</para></listitem>
+                              </listitem>
                         </varlistentry>
 
                         <varlistentry>
                                 <term><varname>ExecStartPre=</varname></term>
                                 <term><varname>ExecStartPost=</varname></term>
                                 <listitem><para>Additional commands
-                                that are executed before (resp. after)
+                                that are executed before or after
                                 the command in
-                                <varname>ExecStart=</varname>. Multiple
-                                command lines may be concatenated in a
-                                single directive, by separating them
-                                by semicolons (these semicolons must
-                                be passed as separate words). In that
-                                case, the commands are executed one
-                                after the other,
-                                serially. Alternatively, these
-                                directives may be specified more than
-                                once with the same effect. However,
-                                the latter syntax is not recommended
-                                for compatibility with parsers
-                                suitable for XDG
-                                <filename>.desktop</filename> files.
-                                Use of these settings is
-                                optional. Specifier and environment
-                                variable substitution is
-                                supported.</para></listitem>
+                                <varname>ExecStart=</varname>, respectively.
+                                Syntax is the same as for
+                                <varname>ExecStart=</varname>, except
+                                that multiple command lines are allowed
+                                and the commands are executed one
+                                after the other, serially.</para>
+
+                                <para>If any of those commands (not
+                                prefixed with <literal>-</literal>)
+                                fail, the rest are not executed and
+                                the unit is considered failed.</para>
+                                </listitem>
                         </varlistentry>
 
                         <varlistentry>
                                 trigger a configuration reload in the
                                 service. This argument takes multiple
                                 command lines, following the same
-                                scheme as pointed out for
-                                <varname>ExecStartPre=</varname>
+                                scheme as described for
+                                <varname>ExecStart=</varname>
                                 above. Use of this setting is
                                 optional. Specifier and environment
                                 variable substitution is supported
                                 here following the same scheme as for
-                                <varname>ExecStart=</varname>. One
-                                special environment variable is set:
-                                if known <literal>$MAINPID</literal> is
-                                set to the main process of the
-                                daemon, and may be used for command
-                                lines like the following:
-                                <command>/bin/kill -HUP
-                                $MAINPID</command>.</para></listitem>
+                                <varname>ExecStart=</varname>.</para>
+
+                                <para>One additional, special
+                                environment variable is set: if known,
+                                <varname>$MAINPID</varname> is set to
+                                the main process of the daemon, and
+                                may be used for command lines like the
+                                following:</para>
+
+                                <programlisting>/bin/kill -HUP $MAINPID</programlisting>
+
+                                <para>Note however that reloading a
+                                daemon by sending a signal (as with
+                                the example line above) is usually not
+                                a good choice, because this is an
+                                asynchronous operation and hence not
+                                suitable to order reloads of multiple
+                                services against each other. It is
+                                strongly recommended to set
+                                <varname>ExecReload=</varname> to a
+                                command that not only triggers a
+                                configuration reload of the daemon,
+                                but also synchronously waits for it to
+                                complete.</para>
+                                </listitem>
                         </varlistentry>
 
                         <varlistentry>
                                 stop the service started via
                                 <varname>ExecStart=</varname>. This
                                 argument takes multiple command lines,
-                                following the same scheme as pointed
-                                out for
-                                <varname>ExecStartPre=</varname>
+                                following the same scheme as described
+                                for <varname>ExecStart=</varname>
                                 above. Use of this setting is
-                                optional. All processes remaining for
-                                a service after the commands
-                                configured in this option are run are
+                                optional. After the commands configured
+                                in this option are run, all processes
+                                remaining for a service are
                                 terminated according to the
                                 <varname>KillMode=</varname> setting
                                 (see
                                 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). If
-                                this option is not specified the
-                                process is terminated right-away when
+                                this option is not specified, the
+                                process is terminated immediately when
                                 service stop is requested. Specifier
                                 and environment variable substitution
                                 is supported (including
-                                <literal>$MAINPID</literal>, see
+                                <varname>$MAINPID</varname>, see
                                 above).</para></listitem>
                         </varlistentry>
 
                                 <term><varname>ExecStopPost=</varname></term>
                                 <listitem><para>Additional commands
                                 that are executed after the service
-                                was stopped using the commands
-                                configured in
-                                <varname>ExecStop=</varname>. This
+                                was stopped. This includes cases where
+                                the commands configured in
+                                <varname>ExecStop=</varname> were used,
+                                where the service does not have any
+                                <varname>ExecStop=</varname> defined, or
+                                where the service exited unexpectedly. This
                                 argument takes multiple command lines,
-                                following the same scheme as pointed
-                                out for
-                                <varname>ExecStartPre</varname>. Use
+                                following the same scheme as described
+                                for <varname>ExecStart</varname>. Use
                                 of these settings is
                                 optional. Specifier and environment
                                 variable substitution is
                         </varlistentry>
 
                         <varlistentry>
-                                <term><varname>TimeoutSec=</varname></term>
+                                <term><varname>TimeoutStartSec=</varname></term>
                                 <listitem><para>Configures the time to
-                                wait for start-up and stop. If a
+                                wait for start-up. If a
                                 daemon service does not signal
                                 start-up completion within the
-                                configured time the service will be
-                                considered failed and be shut down
-                                again. If a service is asked to stop
-                                but does not terminate in the
-                                specified time it will be terminated
-                                forcibly via SIGTERM, and after
-                                another delay of this time with
-                                SIGKILL. (See
+                                configured time, the service will be
+                                considered failed and will be shut
+                                down again.
+                                Takes a unit-less value in seconds, or a
+                                time span value such as "5min
+                                20s". Pass <literal>0</literal> to
+                                disable the timeout logic. Defaults to
+                                <varname>DefaultTimeoutStartSec=</varname> from
+                                the manager configuration file, except
+                                when <varname>Type=oneshot</varname> is
+                                used, in which case the timeout
+                                is disabled by default
+                                (see <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+                                </para></listitem>
+                        </varlistentry>
+
+                        <varlistentry>
+                                <term><varname>TimeoutStopSec=</varname></term>
+                                <listitem><para>Configures the time to
+                                wait for stop. If a service is asked
+                                to stop, but does not terminate in the
+                                specified time, it will be terminated
+                                forcibly via <constant>SIGTERM</constant>,
+                                and after another timeout of equal duration
+                                with <constant>SIGKILL</constant> (see
                                 <varname>KillMode=</varname>
-                                in <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>) Takes a unit-less value in seconds, or a
+                                in <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+                                Takes a unit-less value in seconds, or a
                                 time span value such as "5min
-                                20s". Pass 0 to disable the timeout
-                                logic. Defaults to
-                                90s, except when <varname>Type=oneshot</varname> is
-                                used in which case the timeout
-                                is disabled by default.</para></listitem>
+                                20s". Pass <literal>0</literal> to disable
+                                the timeout logic. Defaults to
+                                <varname>DefaultTimeoutStopSec=</varname> from the
+                                manager configuration file
+                                (see <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+                                </para></listitem>
+                        </varlistentry>
+
+                        <varlistentry>
+                                <term><varname>TimeoutSec=</varname></term>
+                                <listitem><para>A shorthand for configuring
+                                both <varname>TimeoutStartSec=</varname>
+                                and <varname>TimeoutStopSec=</varname>
+                                to the specified value.
+                                </para></listitem>
                         </varlistentry>
 
                         <varlistentry>
                                 <term><varname>WatchdogSec=</varname></term>
                                 <listitem><para>Configures the
-                                watchdog timeout for a service. This
-                                is activated when the start-up is
+                                watchdog timeout for a service. The
+                                watchdog is activated when the start-up is
                                 completed. The service must call
                                 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
-                                regularly with "WATCHDOG=1" (i.e. the
-                                "keep-alive ping"). If the time
+                                regularly with <literal>WATCHDOG=1</literal>
+                                (i.e. the "keep-alive ping"). If the time
                                 between two such calls is larger than
-                                the configured time then the service
-                                is placed in a failure state. By
-                                setting <varname>Restart=</varname> to
+                                the configured time, then the service
+                                is placed in a failed state and it will
+                                be terminated with <varname>SIGABRT</varname>.
+                                By setting <varname>Restart=</varname> to
                                 <option>on-failure</option> or
-                                <option>always</option> the service
+                                <option>always</option>, the service
                                 will be automatically restarted. The
                                 time configured here will be passed to
                                 the executed service process in the
                                 daemons to automatically enable the
                                 keep-alive pinging logic if watchdog
                                 support is enabled for the service. If
-                                this option is used
+                                this option is used,
                                 <varname>NotifyAccess=</varname> (see
                                 below) should be set to open access to
                                 the notification socket provided by
                         <varlistentry>
                                 <term><varname>Restart=</varname></term>
                                 <listitem><para>Configures whether the
-                                main service process shall be
-                                restarted when it exits. Takes one of
+                                service shall be restarted when the
+                                service process exits, is killed,
+                                or a timeout is reached. The service
+                                process may be the main service
+                                process, but it may also be one of the
+                                processes specified with
+                                <varname>ExecStartPre=</varname>,
+                                <varname>ExecStartPost=</varname>,
+                                <varname>ExecStop=</varname>,
+                                <varname>ExecStopPost=</varname>, or
+                                <varname>ExecReload=</varname>.
+                                When the death of the process is a
+                                result of systemd operation (e.g. service
+                                stop or restart), the service will not be
+                                restarted. Timeouts include missing
+                                the watchdog "keep-alive ping"
+                                deadline and a service start, reload,
+                                and stop operation timeouts.</para>
+
+                                <para>Takes one of
                                 <option>no</option>,
                                 <option>on-success</option>,
                                 <option>on-failure</option>,
-                                <option>on-abort</option> or
+                                <option>on-abnormal</option>,
+                                <option>on-watchdog</option>,
+                                <option>on-abort</option>, or
                                 <option>always</option>. If set to
-                                <option>no</option> (the default) the
-                                service will not be restarted when it
-                                exits. If set to
-                                <option>on-success</option> it will be
-                                restarted only when it exited cleanly,
-                                i.e. terminated with an exit code of
-                                0. If set to
-                                <option>on-failure</option> it will be
-                                restarted only when it exited with an
-                                exit code not equalling 0, when
-                                terminated by a signal (including on
-                                core dump), when an operation (such as
-                                service reload) times out or when the
-                                configured watchdog timeout is
-                                triggered. If set to
-                                <option>on-abort</option> it will be
-                                restarted only if it exits due to
-                                reception of an uncaught signal
-                                (including on core dump). If set to
-                                <option>always</option> the service
-                                will be restarted regardless whether
-                                it exited cleanly or not, got
-                                terminated abnormally by a signal or
-                                hit a timeout.</para></listitem>
+                                <option>no</option> (the default), the
+                                service will not be restarted. If set
+                                to <option>on-success</option>, it
+                                will be restarted only when the
+                                service process exits cleanly.  In
+                                this context, a clean exit means an
+                                exit code of 0, or one of the signals
+                                <constant>SIGHUP</constant>,
+                                <constant>SIGINT</constant>,
+                                <constant>SIGTERM</constant> or
+                                <constant>SIGPIPE</constant>, and
+                                additionally, exit statuses and
+                                signals specified in
+                                <varname>SuccessExitStatus=</varname>.
+                                If set to <option>on-failure</option>,
+                                the service will be restarted when the
+                                process exits with a non-zero exit
+                                code, is terminated by a signal
+                                (including on core dump, but excluding
+                                the aforementiond four signals), when
+                                an operation (such as service reload)
+                                times out, and when the configured
+                                watchdog timeout is triggered.  If set
+                                to <option>on-abnormal</option>, the
+                                service will be restarted when the
+                                process is terminated by a signal
+                                (including on core dump, excluding the
+                                aforementioned four signals), when an
+                                operation times out, or when the
+                                watchdog timeout is triggered. If set
+                                to <option>on-abort</option>, the
+                                service will be restarted only if the
+                                service process exits due to an
+                                uncaught signal not specified as a
+                                clean exit status.  If set to
+                                <option>on-watchdog</option>, the
+                                service will be restarted only if the
+                                watchdog timeout for the service
+                                expires.  If set to
+                                <option>always</option>, the service
+                                will be restarted regardless of
+                                whether it exited cleanly or not, got
+                                terminated abnormally by a signal, or
+                                hit a timeout.</para>
+
+                                <table>
+                                        <title>Exit causes and the effect of the <varname>Restart=</varname> settings on them</title>
+
+                                        <tgroup cols='2'>
+                                                <colspec colname='path' />
+                                                <colspec colname='expl' />
+                                                <thead>
+                                                        <row>
+                                                                <entry>Restart settings/Exit causes</entry>
+                                                                <entry><option>no</option></entry>
+                                                                <entry><option>always</option></entry>
+                                                                <entry><option>on-success</option></entry>
+                                                                <entry><option>on-failure</option></entry>
+                                                                <entry><option>on-abnormal</option></entry>
+                                                                <entry><option>on-abort</option></entry>
+                                                                <entry><option>on-watchdog</option></entry>
+                                                        </row>
+                                                </thead>
+                                                <tbody>
+                                                        <row>
+                                                                <entry>Clean exit code or signal</entry>
+                                                                <entry/>
+                                                                <entry>X</entry>
+                                                                <entry>X</entry>
+                                                                <entry/>
+                                                                <entry/>
+                                                                <entry/>
+                                                                <entry/>
+                                                        </row>
+                                                        <row>
+                                                                <entry>Unclean exit code</entry>
+                                                                <entry/>
+                                                                <entry>X</entry>
+                                                                <entry/>
+                                                                <entry>X</entry>
+                                                                <entry/>
+                                                                <entry/>
+                                                                <entry/>
+                                                        </row>
+                                                        <row>
+                                                                <entry>Unclean signal</entry>
+                                                                <entry/>
+                                                                <entry>X</entry>
+                                                                <entry/>
+                                                                <entry>X</entry>
+                                                                <entry>X</entry>
+                                                                <entry>X</entry>
+                                                                <entry/>
+                                                        </row>
+                                                        <row>
+                                                                <entry>Timeout</entry>
+                                                                <entry/>
+                                                                <entry>X</entry>
+                                                                <entry/>
+                                                                <entry>X</entry>
+                                                                <entry>X</entry>
+                                                                <entry/>
+                                                                <entry/>
+                                                        </row>
+                                                        <row>
+                                                                <entry>Watchdog</entry>
+                                                                <entry/>
+                                                                <entry>X</entry>
+                                                                <entry/>
+                                                                <entry>X</entry>
+                                                                <entry>X</entry>
+                                                                <entry/>
+                                                                <entry>X</entry>
+                                                        </row>
+                                                </tbody>
+                                        </tgroup>
+                                </table>
+
+                                <para>As exceptions to the setting
+                                above the service will not be
+                                restarted if the exit code or signal
+                                is specified in
+                                <varname>RestartPreventExitStatus=</varname>
+                                (see below). Also, the services will
+                                always be restarted if the exit code
+                                or signal is specified in
+                                <varname>RestartForceExitStatus=</varname>
+                                (see below).</para>
+
+                                <para>Setting this to
+                                <option>on-failure</option> is the
+                                recommended choice for long-running
+                                services, in order to increase
+                                reliability by attempting automatic
+                                recovery from errors. For services
+                                that shall be able to terminate on
+                                their own choice (and avoid
+                                immediate restarting),
+                                <option>on-abnormal</option> is an
+                                alternative choice.</para>
+                                </listitem>
+                        </varlistentry>
+
+                        <varlistentry>
+                                <term><varname>SuccessExitStatus=</varname></term>
+                                <listitem><para>Takes a list of exit
+                                status definitions that when returned
+                                by the main service process will be
+                                considered successful termination, in
+                                addition to the normal successful exit
+                                code 0 and the signals <constant>SIGHUP</constant>, <constant>SIGINT</constant>,
+                                <constant>SIGTERM</constant>, and <constant>SIGPIPE</constant>. Exit status
+                                definitions can either be numeric exit
+                                codes or termination signal names,
+                                separated by spaces. For example:
+                                <programlisting>SuccessExitStatus=1 2 8 SIGKILL</programlisting>
+                                ensures that exit codes 1, 2, 8 and
+                                the termination signal
+                                <constant>SIGKILL</constant> are
+                                considered clean service terminations.
+                                </para>
+
+                                <para>Note that if a process has a
+                                signal handler installed and exits by
+                                calling
+                                <citerefentry><refentrytitle>_exit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+                                in response to a signal, the
+                                information about the signal is lost.
+                                Programs should instead perform cleanup and kill themselves with the same signal instead. See
+                                <ulink url="http://www.cons.org/cracauer/sigint.html">Proper handling of SIGINT/SIGQUIT — How to be a proper program</ulink>.</para>
+
+                                <para>This option may appear more than once,
+                                in which case the list of successful
+                                exit statuses is merged. If the empty
+                                string is assigned to this option, the
+                                list is reset, all prior assignments
+                                of this option will have no
+                                effect.</para></listitem>
+                        </varlistentry>
+
+                        <varlistentry>
+                                <term><varname>RestartPreventExitStatus=</varname></term>
+                                <listitem><para>Takes a list of exit
+                                status definitions that when returned
+                                by the main service process will
+                                prevent automatic service restarts,
+                                regardless of the restart setting
+                                configured with
+                                <varname>Restart=</varname>. Exit
+                                status definitions can either be
+                                numeric exit codes or termination
+                                signal names, and are separated by
+                                spaces. Defaults to the empty list, so
+                                that, by default, no exit status is
+                                excluded from the configured restart
+                                logic. For example:
+                                <programlisting>RestartPreventExitStatus=1 6 SIGABRT</programlisting> ensures that exit
+                                codes 1 and 6 and the termination
+                                signal <constant>SIGABRT</constant> will
+                                not result in automatic service
+                                restarting. This
+                                option may appear more than once, in
+                                which case the list of restart-preventing
+                                statuses is merged. If the empty
+                                string is assigned to this option, the
+                                list is reset and all prior assignments
+                                of this option will have no
+                                effect.</para></listitem>
+                        </varlistentry>
+
+                        <varlistentry>
+                                <term><varname>RestartForceExitStatus=</varname></term>
+                                <listitem><para>Takes a list of exit
+                                status definitions that when returned
+                                by the main service process will force
+                                automatic service restarts, regardless
+                                of the restart setting configured with
+                                <varname>Restart=</varname>. The
+                                argument format is similar to
+                                <varname>RestartPreventExitStatus=</varname>.</para></listitem>
                         </varlistentry>
 
                         <varlistentry>
                                 <term><varname>PermissionsStartOnly=</varname></term>
                                 <listitem><para>Takes a boolean
-                                argument. If true, the permission
-                                related execution options as
+                                argument. If true, the permission-related
+                                execution options, as
                                 configured with
                                 <varname>User=</varname> and similar
                                 options (see
                                 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
-                                for more information) are only applied
+                                for more information), are only applied
                                 to the process started with
                                 <varname>ExecStart=</varname>, and not
                                 to the various other
                                 <varname>ExecStartPre=</varname>,
                                 <varname>ExecStartPost=</varname>,
                                 <varname>ExecReload=</varname>,
-                                <varname>ExecStop=</varname>,
+                                <varname>ExecStop=</varname>, and
                                 <varname>ExecStopPost=</varname>
                                 commands. If false, the setting is
                                 applied to all configured commands the
                         <varlistentry>
                                 <term><varname>RootDirectoryStartOnly=</varname></term>
                                 <listitem><para>Takes a boolean
-                                argument. If true, the root directory
+                                argument. If true, the root directory,
                                 as configured with the
                                 <varname>RootDirectory=</varname>
                                 option (see
                                 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
-                                for more information) is only applied
+                                for more information), is only applied
                                 to the process started with
                                 <varname>ExecStart=</varname>, and not
                                 to the various other
                                 <varname>ExecStartPre=</varname>,
                                 <varname>ExecStartPost=</varname>,
                                 <varname>ExecReload=</varname>,
-                                <varname>ExecStop=</varname>,
+                                <varname>ExecStop=</varname>, and
                                 <varname>ExecStopPost=</varname>
                                 commands. If false, the setting is
                                 applied to all configured commands the
 
                         <varlistentry>
                                 <term><varname>NonBlocking=</varname></term>
-                                <listitem><para>Set O_NONBLOCK flag
+                                <listitem><para>Set the
+                                <constant>O_NONBLOCK</constant> flag
                                 for all file descriptors passed via
                                 socket-based activation. If true, all
                                 file descriptors >= 3 (i.e. all except
-                                STDIN/STDOUT/STDERR) will have
-                                the O_NONBLOCK flag set and hence are in
+                                stdin, stdout, and stderr) will have
+                                the <constant>O_NONBLOCK</constant> flag
+                                set and hence are in
                                 non-blocking mode. This option is only
                                 useful in conjunction with a socket
                                 unit, as described in
                                 <option>none</option> (the default),
                                 <option>main</option> or
                                 <option>all</option>. If
-                                <option>none</option> no daemon status
+                                <option>none</option>, no daemon status
                                 updates are accepted from the service
                                 processes, all status update messages
-                                are ignored. If <option>main</option>
+                                are ignored. If <option>main</option>,
                                 only service updates sent from the
                                 main process of the service are
-                                accepted. If <option>all</option> all
+                                accepted. If <option>all</option>, all
                                 services updates from all members of
                                 the service's control group are
                                 accepted. This option should be set to
                                 open access to the notification socket
                                 when using
                                 <varname>Type=notify</varname> or
-                                <varname>WatchdogUsec=</varname> (see
+                                <varname>WatchdogSec=</varname> (see
                                 above). If those options are used but
-                                <varname>NotifyAccess=</varname> not
-                                configured it will be implicitly set
+                                <varname>NotifyAccess=</varname> is not
+                                configured, it will be implicitly set
                                 to
                                 <option>main</option>.</para></listitem>
                         </varlistentry>
                                 <term><varname>Sockets=</varname></term>
                                 <listitem><para>Specifies the name of
                                 the socket units this service shall
-                                inherit the sockets from when the
-                                service is started. Normally it
-                                should not be necessary to use this
-                                setting as all sockets whose unit
+                                inherit socket file descriptors
+                                from when the service is
+                                started. Normally it should not be
+                                necessary to use this setting as all
+                                socket file descriptors whose unit
                                 shares the same name as the service
-                                (ignoring the different suffix of course)
-                                are passed to the spawned
-                                process.</para>
-
-                                <para>Note that the same socket may be
-                                passed to multiple processes at the
-                                same time. Also note that a different
-                                service may be activated on incoming
-                                traffic than inherits the sockets. Or
-                                in other words: The
+                                (subject to the different unit name
+                                suffix of course) are passed to the
+                                spawned process.</para>
+
+                                <para>Note that the same socket file
+                                descriptors may be passed to multiple
+                                processes simultaneously. Also note
+                                that a different service may be
+                                activated on incoming socket traffic
+                                than the one which is ultimately
+                                configured to inherit the socket file
+                                descriptors. Or in other words: the
                                 <varname>Service=</varname> setting of
                                 <filename>.socket</filename> units
-                                doesn't have to match the inverse of the
-                                <varname>Sockets=</varname> setting of
-                                the <filename>.service</filename> it
-                                refers to.</para></listitem>
+                                does not have to match the inverse of
+                                the <varname>Sockets=</varname>
+                                setting of the
+                                <filename>.service</filename> it
+                                refers to.</para>
+
+                                <para>This option may appear more than
+                                once, in which case the list of socket
+                                units is merged. If the empty string
+                                is assigned to this option, the list of
+                                sockets is reset, and all prior uses of
+                                this setting will have no
+                                effect.</para></listitem>
                         </varlistentry>
 
                         <varlistentry>
                                 <term><varname>StartLimitBurst=</varname></term>
 
                                 <listitem><para>Configure service
-                                start rate limiting. By default
-                                services which are started more often
-                                than 5 times within 10s are not
+                                start rate limiting. By default,
+                                services which are started more
+                                than 5 times within 10 seconds are not
                                 permitted to start any more times
-                                until the 10s interval ends. With
-                                these two options this rate limiting
+                                until the 10 second interval ends. With
+                                these two options, this rate limiting
                                 may be modified. Use
                                 <varname>StartLimitInterval=</varname>
-                                to configure the checking interval
-                                (defaults to 10s, set to 0 to disable
+                                to configure the checking interval (defaults to
+                                <varname>DefaultStartLimitInterval=</varname> in
+                                manager configuration file, set to 0 to disable
                                 any kind of rate limiting). Use
                                 <varname>StartLimitBurst=</varname> to
                                 configure how many starts per interval
-                                are allowed (defaults to 5). These
+                                are allowed (defaults to
+                                <varname>DefaultStartLimitBurst=</varname> in
+                                manager configuration file). These
                                 configuration options are particularly
                                 useful in conjunction with
-                                <varname>Restart=</varname>, however
-                                apply to all kinds of starts
+                                <varname>Restart=</varname>; however,
+                                they apply to all kinds of starts
                                 (including manual), not just those
                                 triggered by the
                                 <varname>Restart=</varname> logic.
                                 Note that units which are configured
                                 for <varname>Restart=</varname> and
                                 which reach the start limit are not
-                                attempted to be restarted anymore,
-                                however they may still be restarted
-                                manually at a later point from which
-                                point on the restart logic is again
+                                attempted to be restarted anymore;
+                                however, they may still be restarted
+                                manually at a later point, from which
+                                point on, the restart logic is again
                                 activated. Note that
                                 <command>systemctl
                                 reset-failed</command> will cause the
                                 hit. Takes one of
                                 <option>none</option>,
                                 <option>reboot</option>,
-                                <option>reboot-force</option> or
-                                <option>reboot-immediate</option>. If
-                                <option>none</option> is set,
-                                hitting the rate limit will trigger no
-                                action besides that the start will not
-                                be
+                                <option>reboot-force</option>,
+                                <option>reboot-immediate</option>,
+                                <option>poweroff</option>,
+                                <option>poweroff-force</option> or
+                                <option>poweroff-immediate</option>. If
+                                <option>none</option> is set, hitting
+                                the rate limit will trigger no action
+                                besides that the start will not be
                                 permitted. <option>reboot</option>
                                 causes a reboot following the normal
                                 shutdown procedure (i.e. equivalent to
-                                <command>systemctl reboot</command>),
-                                <option>reboot-force</option> causes
-                                an forced reboot which will terminate
-                                all processes forcibly but should
-                                cause no dirty file systems on reboot
+                                <command>systemctl reboot</command>).
+                                <option>reboot-force</option> causes a
+                                forced reboot which will terminate all
+                                processes forcibly but should cause no
+                                dirty file systems on reboot
                                 (i.e. equivalent to <command>systemctl
                                 reboot -f</command>) and
                                 <option>reboot-immediate</option>
                                 causes immediate execution of the
                                 <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
                                 system call, which might result in
-                                data loss.  Defaults to
+                                data loss. Similar,
+                                <option>poweroff</option>,
+                                <option>poweroff-force</option>,
+                                <option>poweroff-immediate</option>
+                                have the effect of powering down the
+                                system with similar
+                                semantics. Defaults to
                                 <option>none</option>.</para></listitem>
                         </varlistentry>
 
+                        <varlistentry>
+                                <term><varname>FailureAction=</varname></term>
+                                <listitem><para>Configure the action
+                                to take when the service enters a failed
+                                state. Takes the same values as
+                                <varname>StartLimitAction=</varname>
+                                and executes the same actions.
+                                Defaults to <option>none</option>.
+                                </para></listitem>
+                        </varlistentry>
+
+                        <varlistentry>
+                                <term><varname>RebootArgument=</varname></term>
+                                <listitem><para>Configure the optional
+                                argument for the
+                                <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+                                system call if
+                                <varname>StartLimitAction=</varname>
+                                or <varname>FailureAction=</varname>
+                                is a reboot action. This works just
+                                like the optional argument to
+                                <command>systemctl reboot</command>
+                                command.</para></listitem>
+                        </varlistentry>
+
                 </variablelist>
 
                 <para>Check
         </refsect1>
 
         <refsect1>
-                <title>Compatibility Options</title>
+                <title>Command lines</title>
+
+                <para>This section describes command line parsing and
+                variable and specifier substitions for
+                <varname>ExecStart=</varname>,
+                <varname>ExecStartPre=</varname>,
+                <varname>ExecStartPost=</varname>,
+                <varname>ExecReload=</varname>,
+                <varname>ExecStop=</varname>, and
+                <varname>ExecStopPost=</varname> options.</para>
+
+                <para>Multiple command lines may be concatenated in a
+                single directive by separating them with semicolons
+                (these semicolons must be passed as separate words).
+                Lone semicolons may be escaped as
+                <literal>\;</literal>.</para>
+
+                <para>Each command line is split on whitespace, with
+                the first item being the command to execute, and the
+                subsequent items being the arguments.  Double quotes
+                ("...") and single quotes ('...') may be used, in
+                which case everything until the next matching quote
+                becomes part of the same argument. Quotes themselves
+                are removed after parsing. In addition, a trailing
+                backslash (<literal>\</literal>) may be used to merge
+                lines. </para>
+
+                <para>This syntax is intended to be very similar to
+                shell syntax, but only the meta-characters and
+                expansions described in the following paragraphs are
+                understood.  Specifically, redirection using
+                <literal>&lt;</literal>, <literal>&lt;&lt;</literal>,
+                <literal>&gt;</literal>, and
+                <literal>&gt;&gt;</literal>, pipes using
+                <literal>|</literal>, running programs in the
+                background using <literal>&amp;</literal>, and
+                <emphasis>other elements of shell syntax are not
+                supported</emphasis>.</para>
+
+                <para>The command line accepts <literal>%</literal>
+                specifiers as described in
+                <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+                Note that the first argument of the command line
+                (i.e. the program to execute) may not include
+                specifiers.</para>
+
+                <para>Basic environment variable substitution is
+                supported. Use <literal>${FOO}</literal> as part of a
+                word, or as a word of its own, on the command line, in
+                which case it will be replaced by the value of the
+                environment variable including all whitespace it
+                contains, resulting in a single argument. Use
+                <literal>$FOO</literal> as a separate word on the
+                command line, in which case it will be replaced by the
+                value of the environment variable split at whitespace
+                resulting in zero or more arguments. For this type of
+                expansion, quotes and respected when splitting into
+                words, and afterwards removed.</para>
+
+                <para>Example:</para>
+
+                <programlisting>Environment="ONE=one" 'TWO=two two'
+ExecStart=/bin/echo $ONE $TWO ${TWO}</programlisting>
+
+                <para>This will execute <command>/bin/echo</command>
+                with four arguments: <literal>one</literal>,
+                <literal>two</literal>, <literal>two</literal>, and
+                <literal>two two</literal>.</para>
+
+                <para>Example:</para>
+                <programlisting>Environment=ONE='one' "TWO='two two' too" THREE=
+ExecStart=/bin/echo ${ONE} ${TWO} ${THREE}
+ExecStart=/bin/echo $ONE $TWO $THREE</programlisting>
+                <para>This results in <filename>echo</filename> being
+                called twice, the first time with arguments
+                <literal>'one'</literal>,
+                <literal>'two two' too</literal>, <literal></literal>,
+                and the second time with arguments
+                <literal>one</literal>, <literal>two two</literal>,
+                <literal>too</literal>.
+                </para>
 
-                <para>The following options are also available in the
-                <literal>[Service]</literal> section, but exist purely
-                for compatibility reasons and should not be used in
-                newly written service files.</para>
+                <para>To pass a literal dollar sign, use
+                <literal>$$</literal>. Variables whose value is not
+                known at expansion time are treated as empty
+                strings. Note that the first argument (i.e. the
+                program to execute) may not be a variable.</para>
+
+                <para>Variables to be used in this fashion may be
+                defined through <varname>Environment=</varname> and
+                <varname>EnvironmentFile=</varname>.  In addition,
+                variables listed in the section "Environment variables
+                in spawned processes" in
+                <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+                which are considered "static configuration", may be
+                used (this includes e.g. <varname>$USER</varname>, but
+                not <varname>$TERM</varname>).</para>
 
-                <variablelist>
-                        <varlistentry>
-                                <term><varname>SysVStartPriority=</varname></term>
-                                <listitem><para>Set the SysV start
-                                priority to use to order this service
-                                in relation to SysV services lacking
-                                LSB headers. This option is only
-                                necessary to fix ordering in relation
-                                to legacy SysV services, that have no
-                                ordering information encoded in the
-                                script headers. As such it should only
-                                be used as temporary compatibility
-                                option, and not be used in new unit
-                                files. Almost always it is a better
-                                choice to add explicit ordering
-                                directives via
-                                <varname>After=</varname> or
-                                <varname>Before=</varname>,
-                                instead. For more details see
-                                <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
-                                used, pass an integer value in the
-                                range 0-99.</para></listitem>
-                        </varlistentry>
+                <para>Note that shell command lines are not directly
+                supported. If shell command lines are to be used, they
+                need to be passed explicitly to a shell implementation
+                of some kind. Example:</para>
+                <programlisting>ExecStart=/bin/sh -c 'dmesg | tac'</programlisting>
 
-                        <varlistentry>
-                                <term><varname>FsckPassNo=</varname></term>
-                                <listitem><para>Set the fsck passno
-                                priority to use to order this service
-                                in relation to other file system
-                                checking services. This option is only
-                                necessary to fix ordering in relation
-                                to fsck jobs automatically created for
-                                all <filename>/etc/fstab</filename>
-                                entries with a value in the fs_passno
-                                column > 0. As such it should only be
-                                used as option for fsck
-                                services. Almost always it is a better
-                                choice to add explicit ordering
-                                directives via
-                                <varname>After=</varname> or
-                                <varname>Before=</varname>,
-                                instead. For more details see
-                                <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
-                                used, pass an integer value in the
-                                same range as
-                                <filename>/etc/fstab</filename>'s
-                                fs_passno column. See
-                                <citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
-                                for details.</para></listitem>
-                        </varlistentry>
+                <para>Example:</para>
 
-                </variablelist>
+                <programlisting>ExecStart=/bin/echo one ; /bin/echo "two two"</programlisting>
+
+                <para>This will execute <command>/bin/echo</command>
+                two times, each time with one argument:
+                <literal>one</literal> and <literal>two two</literal>,
+                respectively. Because two commands are specified,
+                <varname>Type=oneshot</varname> must be used.</para>
+
+                <para>Example:</para>
+
+                <programlisting>ExecStart=/bin/echo / &gt;/dev/null &amp; \; \
+/bin/ls</programlisting>
+
+                <para>This will execute <command>/bin/echo</command>
+                with five arguments: <literal>/</literal>,
+                <literal>&gt;/dev/null</literal>,
+                <literal>&amp;</literal>, <literal>;</literal>, and
+                <literal>/bin/ls</literal>.</para>
         </refsect1>
 
         <refsect1>
                   <title>See Also</title>
                   <para>
                           <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
-                          <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+                          <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
                           <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
                           <citerefentry><refentrytitle>systemd.exec</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.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+                          <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
                   </para>
         </refsect1>