On Wed, 26.05.10 15:52, Scott James Remnant (scott(a)canonical.com) wrote:
On Wed, 2010-05-26 at 08:43 -0400, Matthias Clasen wrote:
> On Wed, 2010-05-26 at 12:35 +0100, Scott James Remnant wrote:
>
> > We did sit down and discuss things, and you convinced me that
> > launchd-style activation was a useful thing to have. Then you went off
> > and wrote systemd anyway.
> >
>
> If you want to add socket passing to upstart as well, we can turn this
> into a win-win situation instead of flaming each other.
>
> If both upstart systemd support this in the same way, it will will be
> much easier to get the patches for the various services upstream. That
> is great.
>
I don't see any reason not to at least pass the LISTEN_FDS environment
variable (though I can't figure out what LISTEN_PID is for?)
Ah nice, now we are talking, yesterday you were still refusing
cooperation on this, and claimed the systemd scheme was "too simple"...
Regarding the LISTEN_PID env var:
environment variables are normally inherited when forking/execing. We
want to make sure that only the process we actually start ourselves
parses and handles LISTEN_FDS. We want to avoid that if this daemon
might spawn some other process, it might get confused into handling
LISTEN_FDS, although that env var wasn't actually intended for it.
And hence we say that LISTEN_PID should be verified first, and only if
it matches LISTEN_FDS should be handled.
This is actually explained in my long blog story. Please read it. It's
number 8 in the feature list!
Upstart will support a different mechanism as well though, because
for
the services we want to activate this way in Ubuntu, there are benefits
to having the services "phone back" to Upstart to pick up the socket.
Right, would be good if you could elaborate about that. I alead asked
you a couple of times about this. Would love to hear about the
reasoning.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4