upstart socket activation

[Lennart Poettering]

On Wed, 16.03.11 16:18, Scott James Remnant (scott at netsplit.com) wrote:

> >> D-Bus FD passing.
> >
> > Care to elaborate? Can I have a look at the API somewhere? Is there
> > example code for the daemon side available?
> >
> Oh, sorry, I misinterpreted. My answer was about the bridge<->init
> part, not init<->job.
> 
> The bridge<->init API is simply an extension to the existing
> com.ubuntu.Upstart.EmitEvent method - a new EmitEventWithFile method
> that has an FD parameter along with the pre-existing environment
> parameters. Upstart ensures this fd is present in the job (it's only
> not-cloexec for a job blocking the event) just like the environment
> also passed is present.
> 
> These fds can be whatever you like - one suggested use for example is
> to pass the tty where initctl is invoked to tasks so their output
> appears on the console and so they can receive input from it.

Uh. That's a bad idea, sounds very SysV-ish to me: you definitely want
to decouple the triggering process from the execution environment of a
daemon. Passing a handle to the tty to the daemon completely reverses
that. But it's your choice, of course.

> > Can you explain why the $LISTEN_FDS logic systemd uses is not
> > acceptable to Upstart?
> >
> It's perfectly acceptable, just Upstart doesn't define it because the
> fds passing is more generic than just "listening sockets" like in
> systemd. Likewise since Upstart actually supports daemon processes,
> rather than telling them not to do that, LISTEN_PID isn't appropriate
> either.
> 
> But because it's a superset, jobs that call binaries which are
> compatible with systemd instead of Upstart can just do:
> 
>   exec env LISTEN_FDS=$UPSTART_FDS LISTEN_PID=$$ ...

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? 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...

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.

(But it's nice to see how that my dbus fd passing patch finds so many uses!)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.