man: add a note that FDSTORE=1 requires epoll-compatible fds

Let's say that this was not obvious from our man page.

diff --git a/man/sd_notify.xml b/man/sd_notify.xml
index 025fbec..94542b8 100644 (file)
--- a/man/sd_notify.xml
+++ b/man/sd_notify.xml
@@ -205,28 +205,25 @@
       <varlistentry>
         <term>FDSTORE=1</term>
 
-        <listitem><para>Stores additional file descriptors in the
-        service manager. File descriptors sent this way will be
-        maintained per-service by the service manager and be passed
-        again using the usual file descriptor passing logic on the
-        next invocation of the service (see
-        <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
-        This is useful for implementing service restart schemes where
-        services serialize their state to <filename>/run</filename>,
-        push their file descriptors to the system manager, and are
-        then restarted, retrieving their state again via socket
-        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>
-        for details. Multiple arrays of file descriptors may be sent
-        in separate messages, in which case the arrays are combined.
-        Note that the service manager removes duplicate file
-        descriptors before passing them to the service. Use
-        <function>sd_pid_notify_with_fds()</function> to send messages
-        with <literal>FDSTORE=1</literal>, see
-        below.</para></listitem>
+        <listitem><para>Stores additional file descriptors in the service manager. File
+        descriptors sent this way will be maintained per-service by the service manager
+        and will be passed again using the usual file descriptor passing logic on the next
+        invocation of the service, see
+        <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        This is useful for implementing service restart schemes where services serialize
+        their state to <filename>/run</filename>, push their file descriptors to the
+        system manager, and are then restarted, retrieving their state again via socket
+        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>).
+        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
+        case the arrays are combined.  Note that the service manager removes duplicate
+        file descriptors before passing them to the service. Use
+        <function>sd_pid_notify_with_fds()</function> to send messages with
+        <literal>FDSTORE=1</literal>, see below.</para></listitem>
       </varlistentry>
 
       <varlistentry>

diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 90b1312..5c65957 100644 (file)
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -852,13 +852,13 @@
         serialized to <filename>/run</filename> and the file
         descriptors passed to the service manager, to allow restarts
         without losing state. Defaults to 0, i.e. no file descriptors
-        may be stored in the service manager by default. All file
+        may be stored in the service manager. All file
         descriptors passed to the service manager from a specific
         service are passed back to the service's main process on the
         next service restart. Any file descriptors passed to the
         service manager are automatically closed when POLLHUP or
         POLLERR is seen on them, or when the service is fully stopped
-        and no job queued or being executed for it.</para></listitem>
+        and no job is queued or being executed for it.</para></listitem>
       </varlistentry>
 
       <varlistentry>