This is useful for compatibility with SysV. Note that this
compatibility is quite comprehensive but not 100%. For details
about the incompatibilities, see the <ulink
- url="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
+ url="https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
with SysV</ulink> document.</para>
</refsect1>
process it supervises. A number of options that may be used in
this section are shared with other unit types. These options are
documented in
- <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
and
- <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
The options specific to the <literal>[Service]</literal> section
of service units are the following:</para>
process has to exit before systemd starts follow-up units.
<varname>RemainAfterExit=</varname> is particularly useful for
this type of service. This is the implied default if neither
- <varname>Type=</varname> or <varname>ExecStart=</varname> are
+ <varname>Type=</varname> nor <varname>ExecStart=</varname> are
specified.</para>
<para>Behavior of <option>dbus</option> is similar to
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
+ run, it is implied that the service is stopped, and any processes
+ remaining for it 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 by
<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>RestartPreventExitStatus=</varname> (see below) or
+ the service is stopped with <command>systemctl stop</command>
+ or an equivalent operation. Also, the services will always be
+ restarted if the exit code or signal is specified in
<varname>RestartForceExitStatus=</varname> (see below).</para>
<para>Note that service restart is subject to unit start rate
<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>, <option>exec</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>exec</option>, only service updates sent
- from any of the control processes originating from one of the
- <varname>Exec*=</varname> commands 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>
+ <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>, <option>exec</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>exec</option>, only service updates sent from any of the
+ main or control processes originating from one of the <varname>Exec*=</varname> commands 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>
+
+ <para>Note that <function>sd_notify()</function> notifications may be attributed to units correctly only if
+ either the sending process is still around at the time PID 1 processes the message, or if the sending process
+ is explicitly runtime-tracked by the service manager. The latter is the case if the service manager originally
+ forked off the process, i.e. on all processes that match <option>main</option> or
+ <option>exec</option>. Conversely, if an auxiliary process of the unit sends an
+ <function>sd_notify()</function> message and immediately exits, the service manager might not be able to
+ properly attribute the message to the unit, and thus will ignore it, even if
+ <varname>NotifyAccess=</varname><option>all</option> is set for it.</para></listitem>
</varlistentry>
<varlistentry>
projects / thirdparty / systemd.git / blobdiff