man: sd_notify() race is gone with sd_notify_barrier()

Add note for change of behaviour in systemd-notify, where parent pid trick
is only used when --no-block is passed, and with enough privileges ofcourse.

Also, fix a small error in systemd(1).

1 files changed, 24 insertions, 9 deletions

diff --git a/man/systemd-notify.xml b/man/systemd-notify.xml
index 4560074505..6d583003ba 100644
--- a/man/systemd-notify.xml
+++ b/man/systemd-notify.xml
@@ -54,15 +54,19 @@
     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><command>systemd-notify</command> will first attempt to invoke <function>sd_notify()</function> pretending to
-    have the PID of the invoking process. This will only succeed when invoked with sufficient privileges. On failure,
-    it will then fall back to invoking it under its own PID. This behaviour is useful in order that when the tool is
-    invoked from a shell script the shell process — and not the <command>systemd-notify</command> process — appears as
-    sender of the message, which in turn is helpful if the shell process is the main process of a service, due to the
-    limitations of <varname>NotifyAccess=</varname><option>all</option> described above.</para>
+    attribute the message to the unit, and thus will ignore it, even if <varname>NotifyAccess=</varname><option>all
+    </option> is set for it. When <option>--no-block</option> is used, all synchronization for reception of notifications
+    is disabled, and hence the aforementioned race may occur if the invoking process is not the service manager or spawned
+    by the service manager.</para>
+
+    <para>Hence, <command>systemd-notify</command> will first attempt to invoke <function>sd_notify()</function>
+    pretending to have the PID of the invoking process. This will only succeed when invoked with sufficient privileges.
+    On failure, it will then fall back to invoking it under its own PID. This behaviour is useful in order that when
+    the tool is invoked from a shell script the shell process — and not the <command>systemd-notify</command> process
+    — appears as sender of the message, which in turn is helpful if the shell process is the main process of a service,
+    due to the limitations of <varname>NotifyAccess=</varname><option>all</option>. Use the <option>--pid=</option>
+    switch to tweak this behaviour.</para>
+
   </refsect1>
 
   <refsect1>
@@ -129,6 +133,17 @@
         with systemd.  </para></listitem>
       </varlistentry>
 
+      <varlistentry>
+        <term><option>--no-block</option></term>
+
+        <listitem><para>Do not synchronously wait for the requested operation to finish.
+        Use of this option is only recommended when <command>systemd-notify</command>
+        is spawned by the service manager, or when the invoking process is directly spawned
+        by the service manager and has enough privileges to allow <command>systemd-notify
+        </command> to send the notification on its behalf. Sending notifications with
+        this option set is prone to race conditions in all other cases.</para></listitem>
+      </varlistentry>
+
       <xi:include href="standard-options.xml" xpointer="help" />
       <xi:include href="standard-options.xml" xpointer="version" />
     </variablelist>