morgan/systemd
1
0
Fork 0
mirror of https://github.com/morgan9e/systemd synced 2026-04-14 00:14:32 +09:00
Code Issues Packages Projects Releases Wiki Activity

man: reword recommendations around Accept=

Browse Source 
Accept=yes has very valid usecases (i.e. for sporadically invoked
services) and strong benefits (i.e. better security because connections
can be sandboxed nicely, isolating them). Let's hence reword things and
stop claiming that Accept=yes was a legacy thing, because it really
isn't.

Some other man fixes, too
This commit is contained in:
Lennart Poettering
2025-05-15 18:46:03 +02:00
committed by Yu Watanabe
parent 59276b86dc
commit fbf43297dd
1 changed files with 18 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
man/systemd.socket.xml
View File

@@ -405,17 +405,26 @@
connection and only the connection socket is passed to it. If no, all listening sockets themselves
are passed to the started service unit, 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 handles all incoming traffic. Defaults to <option>no</option>. For performance
reasons, it is recommended to write new daemons only in a way that is suitable for
<option>Accept=no</option>. A daemon listening on an <constant>AF_UNIX</constant> socket may, but
does not need to, call
unconditionally handles all incoming traffic. Defaults to <option>no</option>.</para>
<para>Typically, for performance sensitive services, a choice of <option>Accept=no</option> is
preferable, since that way only the first connection will have to pay the activation resource
cost. On the other hand, for sporadically used services <option>Accept=yes</option> can be preferable
as it simplifies the implementation (as the service program code only has to process a single
connection instead of handling multiple) and enables stronger security (since the various sandboxing
options can be used to isolate parallel connections from each other, as each is serviced by a
separate service instance and process).</para>
<para>A service listening on an <constant>AF_UNIX</constant> 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 file system. It should
not invoke
<citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>2</manvolnum></citerefentry> on
sockets it got with <varname>Accept=no</varname>, but it may do so for sockets it got with
<varname>Accept=yes</varname> set. Setting <varname>Accept=yes</varname> is mostly useful to allow
daemons designed for usage with <citerefentry
<varname>Accept=yes</varname> set.</para>
<para>Setting <varname>Accept=yes</varname> is in particular useful for allowing daemons designed for
usage with <citerefentry
project='freebsd'><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry> to work
unmodified with systemd socket activation.</para>
@@ -435,8 +444,9 @@
(<literal>@</literal>). If the socket is unnamed, <varname>$REMOTE_ADDR</varname> will not be
set.</para>
<para>The <varname>$SO_COOKIE</varname> environment variable is set to the Linux socket cookie,
formatted as decimal integer. The socket cookie can otherwise be acquired via <citerefentry
<para>If <varname>Accept=yes</varname> is used, the activated service process will have set the
<varname>$SO_COOKIE</varname> environment variable to the Linux socket cookie, formatted as decimal
integer. The socket cookie can otherwise be acquired via <citerefentry
project='man-pages'><refentrytitle>getsockopt</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
<para>It is recommended to set <varname>CollectMode=inactive-or-failed</varname> for service