<para>If set to
<option>simple</option> (the default
- value if neither
+ if neither
<varname>Type=</varname> nor
- <varname>BusName=</varname> are
+ <varname>BusName=</varname>, but
+ <varname>ExecStart=</varname> are
specified), it is expected that the
process configured with
<varname>ExecStart=</varname> is the
exits.</para>
<para>Behavior of
- <option>oneshot</option> is similar
- to <option>simple</option>; however,
- it is expected that the process has to
+ <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>Behavior of
<option>dbus</option> is similar to
</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>Commands with their
<para>When <varname>Type</varname> is
not <option>oneshot</option>, only one
- command may be given. When
+ command may and must be given. When
<varname>Type=oneshot</varname> is
- used, more than one command may be
- specified. Multiple command lines may
- be concatenated in a single directive
- by separating them with semicolons
- (these semicolons must be passed as
- separate words). Alternatively, this
- directive may be specified more than
- once with the same effect.
- Lone semicolons may be escaped as
+ used, none or more than one command
+ may be specified. Multiple command
+ lines may be concatenated in a single
+ directive by separating them with
+ semicolons (these semicolons must be
+ passed as separate
+ words). Alternatively, this directive
+ may be specified more than once with
+ the same effect. Lone semicolons may
+ be escaped as
<literal>\;</literal>. 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.</para>
+ have no effect. If no
+ <varname>ExecStart=</varname> is
+ specified, then the service must have
+ <varname>RemainAfterExit=yes</varname>
+ set.</para>
<para>Each command line is split on
whitespace, with the first item being
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>
time span value such as "5min
20s". Pass <literal>0</literal> to
disable the timeout logic. Defaults to
- <varname>TimeoutStartSec=</varname> from
+ <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.
+ is disabled by default
+ (see <citerefentry><refentrytitle>systemd-systemd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
</para></listitem>
</varlistentry>
time span value such as "5min
20s". Pass <literal>0</literal> to disable
the timeout logic. Defaults to
- <varname>TimeoutStartSec=</varname> from the
- manager configuration file.
+ <varname>DefaultTimeoutStopSec=</varname> from the
+ manager configuration file
+ (see <citerefentry><refentrytitle>systemd-systemd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
</para></listitem>
</varlistentry>
processes specified with
<varname>ExecStartPre=</varname>,
<varname>ExecStartPost=</varname>,
- <varname>ExecStopPre=</varname>,
+ <varname>ExecStop=</varname>,
<varname>ExecStopPost=</varname>, or
<varname>ExecReload=</varname>.
When the death of the process is a
<option>no</option>,
<option>on-success</option>,
<option>on-failure</option>,
+ <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. 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
+ 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>.
+ <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), when an operation (such as
- service reload) times out, and when the
- configured 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
+ 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
+ will be restarted regardless of
+ whether it exited cleanly or not, got
terminated abnormally by a signal, or
hit a timeout.</para>
- <para>In addition to the above settings,
- the service will not be restarted if the
- exit code or signal is specified in
+ <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).</para></listitem>
+ (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>
<constant>SIGTERM</constant>, and <constant>SIGPIPE</constant>. Exit status
definitions can either be numeric exit
codes or termination signal names,
- separated by spaces. Signals will only
- be considered if the service does not implement
- a signal handler and exits as a direct result
- of receiving the signal. For example:
- <programlisting>SuccessExitStatus=1 2 8 <constant>SIGKILL</constant></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>
+ 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>
spaces. Defaults to the empty list, so
that, by default, no exit status is
excluded from the configured restart
- logic. Example:
- <literal>RestartPreventExitStatus=1 6
- SIGABRT</literal>, ensures that exit
+ 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
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
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 permitted. <option>reboot</option>
+ <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
- a forced reboot which will terminate
- all processes forcibly but should
- cause no dirty file systems on reboot
+ <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
<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.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
~ianmdlvl / elogind.git / blobdiff