Thomas Goirand <z...@debian.org> writes:
> On 05/28/2013 02:37 PM, Helmut Grohne wrote:
>> My major point here was precisely that you are *not* done with just
>> writing the service/job descriptions/scripts for all those init
>> systems. You'd likely have to patch every single daemon to enable the
>> socket activation method for those init systems, that the authors of
>> your daemon did not like to use.
>> If on the other hand you omit this patching, then that init system
>> partially loses one of its selling points. So instead of supporting one
>> init system properly, we support four init systems poorly.
> Just to make sure I understood.
> What selling point are you talking about? Why is it necessary to patch
> daemons to have socket activation?
Socket activation is a neat solution to several long-standing problems
with socket-based daemons (either local or network):
1. It's difficult to tell when the daemon is fully initialized and ready
to accept connections from the network, and therefore to determine
ordering constraints during startup. Daemons that fork and background
themselves are *supposed* to not do that until they're set up to accept
connections, but many do not follow this rule, and fixing them can be
non-trivial. Socket activation bypasses this whole problem by having
the init system listen on the sockets so that connections are held in
an accepted state until the daemon finishes spinning up, which mostly
eliminates the need to worry about ordering and timing constraints
between the daemons unless there's an actual deadlock.
2. Daemons that can use socket activation *exclusively* can offload a lot
of complexity around such things as managing both IPv4 and IPv6 socket
endpoints to well-tested code.
3. It's possible for daemons to crash and be restarted transparently to
the end user in some situations because the socket can be passed to a
newly-recovered daemon. (There are significant limitations here, of
course, but it does improve robustness for some services.)
4. One can hold off on spawning daemons until they're actually used, which
can save system resources.
For more details, see:
http://0pointer.de/blog/projects/socket-activation.html
It's basically an abstraction and generalization of the inetd concept,
making it work with a much wider array of socket-based services.
Note that upstreams are going to start supporting this regardless of what
Debian does, to work better on Red Hat systems. For example, I plan on
adding support for socket activation to the network services for which I'm
upstream. There's really no reason not to, and the code required is
fairly simple.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bo7rhypb....@windlord.stanford.edu
