On Wed, 26.05.10 22:06, Björn Persson (bjorn(a)xn--rombobjrn-67a.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