systemd .service file conversion

[Lennart Poettering]

On Fri, 31.05.13 23:31, Helmut Grohne (helmut at subdivi.de) wrote:

> debian-devel at l.d.o has been talking about socket activation interfaces.
> The technical differences are nicely summarized:
> 
> On Fri, May 31, 2013 at 08:53:52PM +0200, Zbigniew J??drzejewski-Szmek wrote:
> > But chronology is less important then the technical differences between
> > the two interfaces.
> > 
> > In systemd a socket activated process gets the variable $LISTEN_FDS
> > and sockets as file descriptors 3, 4, ..., $LISTEN_FDS-1 [1].
> > The interface is very generic.
> > 
> > In upstart the process gets one socket, with the number given in
> > the variable $UPSTART_FDS [2]. The naming (a) doesn't make sense since
> > there's only one socket, (b) is tied to upstart, and (c) there's only
> > one socket.
> > 
> > The limitation to one socket is quite constraining, e.g. we like
> > apache to listen on both 80 and 443, and the requirement for apache to
> > open the second port itselfs makes it impossible to start apache
> > unpriviledged.
> > 
> > Zbyszek
> > 
> > [1] http://www.freedesktop.org/software/systemd/man/sd_listen_fds.html#Description
> > [2] http://manpages.ubuntu.com/manpages/precise/man7/socket-event.7.html
> 
> Is there any chance for upstart to adopt the socket activation interface
> from systemd? As has been pointed out above, the interface is more
> generic. Having upstart and systemd differentiate on interfaces does not
> serve any good. Instead upstart could benefit from daemons already
> supporting systemd style socket activation. Having one interface to
> socket activation would greatly reduce the amount of integration work to
> be done by distributions such as Debian. I am aware that this is kind of
> a bike shedding discussion. The value to be gained is the uniformity
> though.
> 
> If this is not possible, please briefly lay out the reason (or point to
> previous discussion of this matter).

To provide a bit of context: we deliberately designed our socket passing
logic to be generic enough to be implementable elsewhere than systemd
(i.e. we kept it as minimalistic as possible and kept any reference to the
systemd name out of it). I remember even emailing the Upstart guys about
that, but I never got any reply. This was a long long time before Upstart
added socket activation.

Note that what Upstart eventually implemented regarding socket
activation kinda misses the major point of it. 

Socket activation in the launchd/systemd sense is a tool that (among
other things) allows you to get rid of ordering dependencies between clients
and servers, and systematically parallelize their startup. 

Here's an example: if you have a syslog daemon and a service that logs
to syslog, then the former is the server, the latter is the client. Now,
let's say you want to start both at boot. In classic init systems you
would have to make sure that you first start the syslog daemon, and only
after that finished initialization -- and hence established the syslog
socket in the file system -- you can go on and start the client. Hence
you need to express this dependency, and if you don't do that you will
lose messages. Now, if you employ socket activation for this, then you'd
first establish the syslog socket from your init system, and then start
the syslog daemon and its client *at the same time*. Since the socket is
known to be established before your two services initialize logging will
always just work -- and you do not have to express any dependency
explicitly anymore! On top of that, parallelization is maximized since
client and server start at the same time, and do not have to wait for
each other (at least until the socket buffer runs full and the client
starts to block, but that hopefully happens relatively late). Things
hence get simpler, and faster at the same time!

Now, if you understood the scheme above then you will have noticed that
socket activation is *not* about lazy activation here. You start both
services early on, and at the same time. You do not wait for an incoming
connection. And that's something Upstart cannot do with its scheme. In
Upstart, since the sockets are part of the socket connection event, you
always need the connection to take place first.

Hence: on systemd (and launchd where idea comes from) socket activation
is primarily about getting rid of dependencies and increased
parallelization. And secondarily about lazy activation. On Upstart
however socket activation is about lazy activtion and nothing else.

In my eyes this makes socket activation in Upstart pretty much 
uninteresting and misses the major point of it. (Well, at least to the
level I understood Upstart. Maybe I totally missed how it works, but
from the docs, it appears it cannot create the listening socket, and
then activate its service from any other event than the actual incoming
connection event of it, but still have the listening socket passed to
the service.)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.