chiark / gitweb /
Fix service file to match installed elogind binary location
[elogind.git] / man / sd_notify.xml
index ae6792dd708185650163e9c2239edac8e8173b73..a15426c1d10c4eba93d8fda1cbc8ffef28b61910 100644 (file)
         watchdog timestamp. This is the keep-alive ping that services
         need to issue in regular intervals if
         <varname>WatchdogSec=</varname> is enabled for it. See
-        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        <citerefentry><refentrytitle>elogind.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
         for information how to enable this functionality and
         <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
         for the details of how the service can check whether the
         passing and <filename>/run</filename>. Note that the service manager will accept
         messages for a service only if <varname>FileDescriptorStoreMax=</varname> is set
         to non-zero for it (defaults to zero, see
-        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        <citerefentry><refentrytitle>elogind.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
         File descriptors must be pollable, see
         <citerefentry><refentrytitle>epoll_ctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
         Multiple arrays of file descriptors may be sent in separate messages, in which
     <para>Note that elogind will accept status data sent from a
     service only if the <varname>NotifyAccess=</varname> option is
     correctly set in the service definition file. See
-    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    <citerefentry><refentrytitle>elogind.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
   <refsect1>
     <title>See Also</title>
     <para>
-      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>elogind</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
       <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
       <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
       <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
       <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
-      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      <citerefentry><refentrytitle>elogind.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
     </para>
   </refsect1>