picnoir/Systemd
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

man: document that sd_notify() is racy in some cases

Browse source
This commit is contained in:
Lennart Poettering 2017-02-06 13:49:44 +01:00
parent 3576dddf27
commit b3bb64767a
3 changed files with 39 additions and 23 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
man/sd_notify.xml
View file

@ -268,6 +268,15 @@
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details.</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 <varname>NotifyAccess=</varname><option>main</option> or
<varname>NotifyAccess=</varname><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>
<para><function>sd_notifyf()</function> is similar to
<function>sd_notify()</function> but takes a
<function>printf()</function>-like format string plus

13
man/systemd-notify.xml
View file

@ -72,10 +72,17 @@
<para>The command line may carry a list of environment variables
to send as part of the status update.</para>
<para>Note that systemd will refuse reception of status updates
from this command unless <varname>NotifyAccess=all</varname> is
set for the service unit this command is called from.</para>
<para>Note that systemd will refuse reception of status updates from this command unless
<varname>NotifyAccess=</varname> is set for the service unit this command is called from.</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 <varname>NotifyAccess=</varname><option>main</option> or
<varname>NotifyAccess=</varname><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>
</refsect1>
<refsect1>

40
man/systemd.service.xml
View file

@ -792,26 +792,26 @@
<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>