On Wed, 26.05.10 22:06, Björn Persson (bj...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
