Lennart Poettering wrote: > On Wed, 26.05.10 22:06, Björn Persson (bjorn@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). To handle different command line syntaxes I would apply some simple macro substitution to the command line in the .service file, replacing for example the string "%listen_FDs%" (or some other syntax) with the number of sockets. One daemon could then have the parameter "--listen-fds=%listen_FDs%", another could have "-sockets=%listen_FDs%" and a third could have "-q %listen_FDs%". > 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[]. I'd be surprised if any of those programs are designed such that they have no way of passing parameters to their modules. > > 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. I'm afraid I don't understand what you mean with "handle this". I thought at first that you meant that LISTEN_FDS should only be used for daemons that are known to clear it, but if that were the case you wouldn't have invented LISTEN_PID. Do you perchance mean that LISTEN_FDS should only be used in cases where all child processes will be killed if the daemon dies? Björn Persson
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
