Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Merged
merged 3 commits into from Feb 6, 2017
Merged

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

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3576ddd
update TODO
poettering Feb 6, 2017
b3bb647
man: document that sd_notify() is racy in some cases
poettering Feb 6, 2017
aa20394
notify: document that we fake the PID when sending sd_notify()
poettering Feb 6, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
5 changes: 5 additions & 0 deletions TODO
View file
Open in desktop
Expand Up @@ -24,6 +24,11 @@ Janitorial Clean-ups:

Features:

* maybe add call sd_journal_set_block_timeout() or so to set SO_SNDTIMEO for
the sd-journal logging socket, and, if the timeout is set to 0, sets
O_NONBLOCK on it. That way people can control if and when to block for
logging.

* journald: when we recv a log datagram via the native or syslog transports,
search for the PID in the active stream connections, and let's make sure to
always process the datagrams before the streams. Then, cache client metadata
Expand Down
9 changes: 9 additions & 0 deletions man/sd_notify.xml
View file
Open in desktop
Expand Up @@ -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
Expand Down
15 changes: 11 additions & 4 deletions man/systemd-notify.xml
View file
Open in desktop
Expand Up @@ -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>
Expand Down
40 changes: 20 additions & 20 deletions man/systemd.service.xml
View file
Open in desktop
Expand Up @@ -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>
Copy link
Member

@evverx evverx Feb 6, 2017 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, it would be great to update sd_pid_notify_with_fds(3) and systemd-notify(1) too (mainly root/non_root-case). Related to #2737, #2739

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i force pushed a new version that adds this there, too

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I'm not sure the documentation makes it clear why does this service work

[Service]
NotifyAccess=main
ExecStart=/bin/sh -c 'sleep 5; systemd-notify --ready; sleep 1000'
Type=notify

And this service doesn't work

[Service]
NotifyAccess=main
ExecStart=/bin/sh -c 'sleep 5; systemd-notify --ready; sleep 1000'
Type=notify
User=some-non-root

Maybe, this doesn't really matter

</varlistentry>

<varlistentry>
Expand Down