upstart socket activation

[Scott James Remnant]

Note that you're talking about an unmerged, experimental branch at the
moment - any assertions such as "does not support" or "I can't see
how" are meaningless since it's not finished ;-) The current bridges
code is just what the commit message says - a proof of concept. Ubuntu
carries it so people can play.

Should anyone want it for anything serious, it'll be tidied up.

On Wed, Mar 16, 2011 at 4:43 PM, Lennart Poettering
<mzhcfgneg at 0pointer.de> wrote:
> 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.
>