Lennart Poettering wrote:
Regarding the LISTEN_PID env var:
environment variables are normally inherited when forking/execing. We
want to make sure that only the process we actually start ourselves
parses and handles LISTEN_FDS. We want to avoid that if this daemon
might spawn some other process, it might get confused into handling
LISTEN_FDS, although that env var wasn't actually intended for it.
And hence we say that LISTEN_PID should be verified first, and only if
it matches LISTEN_FDS should be handled.
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.
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.
Once a lot of programs start using this it will be difficult to change it, so it
would be good to get it right early on.
Björn Persson