Re: systemd .service file conversion

[Russ Allbery <rra@debian.org>]

Thomas Goirand <zigo@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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>