systemd (Was Re: tmpfs for strategic directories)

[Lennart Poettering]

On Wed, 26.05.10 22:06, Björn Persson (bjorn at rombobjörn.se) wrote:

> This suggests to me that environment variables isn't the right way to do this. 
> Environment variables are good for parameters that should be available to many 
> processes. Command line parameters are better when the parameter is only meant 
> for one specific process. I can see how looking up two environment variables 
> may be a smaller patch than adding a parameter to the program's command line 
> parser, but I still think it should be done with command line
> parameters.

This is a valid point and we have pondered this for a while and in the
end decided to use environ[] instead of argv[], simply because this
allows us to use the same code for handling it in all daemons, while
handling --listen-fds=xxx in argv would work for some daemons, but not
for others. (i.e. some don't do long getopt, others do it with one dash
only). Also, quite a few projects (rsyslog for example) implement socket
handling in loadable modules, where we have no access to argv[] but do
have access to environ[].

> LISTEN_PID isn't bullet-proof by the way, because PIDs are reused. If the 
> original daemon is restarted but its children live on, then later some 
> descendant process may get the same PID as the original daemon, and may try to 
> handle LISTEN_FDS. The risk may be low, but I always prefer a solution that is 
> guaranteed to work over one that mostly works.

Well, this is purely theoretical, since LISTEN_FDS should normally only
be set for daemons that can actually handle this and hence as long as
these are running none of their children can get the same PID.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4