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>
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
<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:
+ separated by spaces. For example:
<programlisting>SuccessExitStatus=1 2 8 <constant>SIGKILL</constant></programlisting>
ensures that exit codes 1, 2, 8 and
the termination signal
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
+ <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
<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>
+ is a reboot action. This works just
+ like the optional argument to
+ <command>systemctl reboot</command>
+ command.</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>
+
</variablelist>
<para>Check