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
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
