Lennart Poettering wrote:
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).
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