systemd (Was Re: tmpfs for strategic directories)

Lennart Poettering mzerqung at 0pointer.de
Wed May 26 16:20:08 UTC 2010


On Wed, 26.05.10 15:52, Scott James Remnant (scott at 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


More information about the devel mailing list