<filename>.service</filename> suffix removed) and
dynamically creates a service unit from that
script. This is useful for compatibility with
- SysV.</para>
+ SysV. Note that this compatibility is quite
+ comprehensive but not 100%. For details about the
+ incomptibilities see the <ulink
+ url="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
+ with SysV</ulink> document.
+ </para>
</refsect1>
<refsect1>
time span value such as "5min
20s". Pass 0 to disable the timeout
logic. Defaults to
- 90s.</para></listitem>
+ 90s, except when <varname>Type=oneshot</varname> is
+ used in which case the timeout
+ is disabled by default.</para></listitem>
</varlistentry>
<varlistentry>
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". 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 <option>on-failure</option> or
+ regularly with "WATCHDOG=1" (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
+ <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. If
+ 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
+ <varname>NotifyAccess=</varname> is
+ not set, it will be implicitly set to
<option>main</option>. Defaults to 0,
which disables this
feature.</para></listitem>
<option>on-failure</option> it will be
restarted only when it exited with an
exit code not equalling 0, when
- terminated by a signal, when an
- operation times out or when the
+ 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. 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>
+ 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>
</varlistentry>
<varlistentry>
are allowed (defaults to 5). These
configuration options are particularly
useful in conjunction with
- <varname>Restart=</varname>.</para></listitem>
+ <varname>Restart=</varname>, however
+ 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>