+ <varlistentry>
+ <term><varname>ExecReload=</varname></term>
+ <listitem><para>Commands to execute to
+ trigger a configuration reload in the
+ service. This argument takes multiple
+ command lines, following the same
+ 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>.</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>
+ <term><varname>ExecStop=</varname></term>
+ <listitem><para>Commands to execute to
+ stop the service started via
+ <varname>ExecStart=</varname>. This
+ argument takes multiple command lines,
+ following the same scheme as described
+ for <varname>ExecStart=</varname>
+ above. Use of this setting is
+ 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 immediately when
+ service stop is requested. Specifier
+ and environment variable substitution
+ is supported (including
+ <varname>$MAINPID</varname>, see
+ above).</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>ExecStopPost=</varname></term>
+ <listitem><para>Additional commands
+ that are executed after the service
+ 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 described
+ for <varname>ExecStart</varname>. Use
+ of these settings is
+ optional. Specifier and environment
+ variable substitution is
+ supported.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>RestartSec=</varname></term>
+ <listitem><para>Configures the time to
+ sleep before restarting a service (as
+ configured with
+ <varname>Restart=</varname>). Takes a
+ unit-less value in seconds, or a time
+ span value such as "5min
+ 20s". Defaults to
+ 100ms.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>TimeoutStartSec=</varname></term>
+ <listitem><para>Configures the time to
+ 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 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
+ time span value such as "5min
+ 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. 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 <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 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
+ will be automatically restarted. The
+ time configured here will be passed to
+ the executed service process in the
+ <varname>WATCHDOG_USEC=</varname>
+ environment variable. This allows
+ daemons to automatically enable the
+ keep-alive pinging logic if watchdog
+ support is enabled for the service. If
+ 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>. Defaults to 0,
+ which disables this
+ feature.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>Restart=</varname></term>
+ <listitem><para>Configures whether the
+ 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-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
+ <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
+ configured with
+ <varname>User=</varname> and similar
+ options (see
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ 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>, and
+ <varname>ExecStopPost=</varname>
+ commands. If false, the setting is
+ applied to all configured commands the
+ same way. Defaults to
+ false.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>RootDirectoryStartOnly=</varname></term>
+ <listitem><para>Takes a boolean
+ 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
+ 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>, and
+ <varname>ExecStopPost=</varname>
+ commands. If false, the setting is
+ applied to all configured commands the
+ same way. Defaults to
+ false.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>NonBlocking=</varname></term>
+ <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, 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
+ <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Defaults
+ to false.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>NotifyAccess=</varname></term>
+ <listitem><para>Controls access to the
+ service status notification socket, as
+ accessible via the
+ <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+ call. Takes one of
+ <option>none</option> (the default),
+ <option>main</option> or
+ <option>all</option>. If
+ <option>none</option>, no daemon status
+ updates are accepted from the service
+ processes, all status update messages
+ are ignored. If <option>main</option>,
+ only service updates sent from the
+ main process of the service are
+ 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>WatchdogSec=</varname> (see
+ above). If those options are used but
+ <varname>NotifyAccess=</varname> is not
+ configured, it will be implicitly set
+ to
+ <option>main</option>.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>Sockets=</varname></term>
+ <listitem><para>Specifies the name of
+ the socket units this service shall
+ 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
+ (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
+ 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>StartLimitInterval=</varname></term>
+ <term><varname>StartLimitBurst=</varname></term>
+
+ <listitem><para>Configure service
+ 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 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
+ <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
+ <varname>DefaultStartLimitBurst=</varname> in
+ manager configuration file). These
+ configuration options are particularly
+ useful in conjunction with
+ <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
+ activated. Note that
+ <command>systemctl
+ reset-failed</command> will cause the
+ restart rate counter for a service to
+ be flushed, which is useful if the
+ administrator wants to manually start
+ a service and the start limit
+ interferes with
+ that.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>StartLimitAction=</varname></term>
+
+ <listitem><para>Configure the action
+ to take if the rate limit configured
+ with
+ <varname>StartLimitInterval=</varname>
+ and
+ <varname>StartLimitBurst=</varname> is
+ hit. Takes one of
+ <option>none</option>,
+ <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
+ (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. 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>
+