upstart socket activation

[Clint Byrum]

On Thu, 2011-03-17 at 00:43 +0100, Lennart Poettering wrote:
> On Wed, 16.03.11 16:18, Scott James Remnant (scott at netsplit.com) wrote:
> 
> Uh, it's not a superset at all. In fact I don't see how this could be
> used to implement the basic idea of socket based actviation at
> all. Socket-based activation is not so much about lazily spawning
> daemons only when somebody connects, but about being able to start them
> in parallel at the same time as their local consumers. But I don't see
> how this should work at all in this approach: if you have a service that
> is actviated on boot and also triggered by socket activation how do you
> pass the socket activation fd to the daemon of it is spawned before the
> first client connects?

Wouldn't it just be passed in as empty strings, signalling to the
service that there's no activated socket yet, and it should wrestle
control of the socket away from upstart. Likewise upstart would stop
accepting connections until the daemon grabbed the listen socket, or
failed to start.

>  If the fds are only passed along the socket
> activation event object, then the fds might come too late. So no, this
> is not at all a superset of what systemd does, but just a classic inetd
> reimplementation...
> 

Indeed, there needs to be a standard way for daemons to communicate with
the system to make sure connections are always being acknowledged and
passed to the daemon. If systemd has already been successful in patching
daemons, upstart should probably emulate that same API.

> And yeah, Upstart doesn't even support INET6 sockets for socket
> activation, or anything like that, so it's not a superset, not even
> remotely.
> 
> But anyway, I think there's no reason to fight about systemd vs. Upstart
> here. So I'll just shut up again and quietly watch from the distance.
> 

I fail to see why this should be a fight, maybe thats just in your
head? 

I see this as a situation where we can share technology and establish a
standard that works well with both our solutions. The worst thing we can
do right now is disagree on how to ask daemon upstreams to patch their
daemons. If upstart does this one way that is entirely incompatible w/
systemd, and they both get real traction, then we will just create a
giant inefficiency and gridlock where we have daemons who have gone "the
upstart way" and others who have gone "the systemd way", and neither
trusting that the other is worth doing.