On Wed, 26.05.10 15:52, Scott James Remnant (scott@xxxxxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
