X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=man%2Fsystemd.socket.xml;h=040305c632c55a12d6d3e0207704e33d20421d47;hp=e594422889177e542ae2643dbdcdd19fe580fa77;hb=3c86d34cf1e381ade10dcc41c655c98b2d489c8d;hpb=e670b166a08b7c1031a9e7d7675fa9a29c3e19c9

diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index e59442288..040305c63 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -374,17 +374,30 @@
                                 and only one service unit is spawned
                                 for all connections (also see
                                 above). This value is ignored for
-                                datagram sockets and FIFOs where
-                                a single service unit unconditionally
+                                datagram sockets and FIFOs where a
+                                single service unit unconditionally
                                 handles all incoming traffic. Defaults
                                 to <option>false</option>. For
                                 performance reasons, it is recommended
                                 to write new daemons only in a way
                                 that is suitable for
-                                <option>Accept=false</option>. This
-                                option is mostly useful to allow
-                                daemons designed for usage with
-                                <citerefentry><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+                                <option>Accept=false</option>. A
+                                daemon listening on an AF_UNIX socket
+                                may, but does not need to, call
+                                <citerefentry><refentrytitle>close</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+                                on the received socket before
+                                exiting. However, it must not unlink
+                                the socket from a filesystem. It
+                                should note invoke
+                                <citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+                                on sockets it got with
+                                <varname>Accept=false</varname>, but
+                                it may do so for sockets it got with
+                                <varname>Accept=true</varname> set.
+                                Setting <varname>Accept=true</varname>
+                                is mostly useful to allow daemons
+                                designed for usage with
+                                <citerefentry><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
                                 to work unmodified with systemd socket
                                 activation.</para></listitem>
                         </varlistentry>
@@ -686,6 +699,14 @@
                           <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
                           <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
                   </para>
+
+                  <para>
+                          For more extensive descriptions see the "Systemd for Developers" series:
+                          <ulink url="http://0pointer.de/blog/projects/socket-activation.html">Socket Activation</ulink>,
+                          <ulink url="http://0pointer.de/blog/projects/socket-activation2.html">Socket Activation, part II</ulink>,
+                          <ulink url="http://0pointer.de/blog/projects/inetd.html">Converting inetd Services</ulink>,
+                          <ulink url="http://0pointer.de/blog/projects/socket-activated-containers.html">Socket Activated Internet Services and OS Containers</ulink>.
+                  </para>
         </refsect1>
 
 </refentry>