upstart socket activation

[Scott James Remnant]

On Wed, Mar 16, 2011 at 4:02 PM, Lennart Poettering
<mzhcfgneg at 0pointer.de> wrote:
> On Wed, 16.03.11 15:57, Scott James Remnant (scott at netsplit.com) wrote:
>
>>
>> On Wed, Mar 16, 2011 at 3:54 PM, Lennart Poettering
>> <mzhcfgneg at 0pointer.de> wrote:
>> > On Wed, 16.03.11 06:13, Clint Byrum (clint at ubuntu.com) wrote:
>> >
>> >>
>> >> On Wed, 2011-03-16 at 11:17 +0100, Steffen Barszus wrote:
>> >> > I have read about socket activation feature, and i'm quite
>> >> > confused now and would like to have a definitive answer.
>> >> >
>> >> > Is the socket activation:
>> >> > a) xinetd like: start the provider of the socket, once the socket is
>> >> > accessed ? Anything special done until the provider is available ?
>> >>
>> >> Yes its like xinetd, though instead of an accepted socket being
>> >> available, you're getting a listening socket with a connection ready to
>> >> accept, so most daemons (no daemons?) won't support this just yet.
>> >
>> > BTW, what's the API for this looking like? How are the fd's passed to
>> > the daemon?
>> >
>> >From the bridge process to the init daemon?
>>
>> 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.

> 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=$$ ...

Scott