On Tue, 2010-06-01 at 02:52 +0200, Lennart Poettering wrote: > On Wed, 26.05.10 14:47, Simo Sorce (ssorce@xxxxxxxxxx) wrote: > > > > 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. > > > > If you are mandating behavior in daemons, wouldn't it be simpler to > > mandate the daemon unsets LISTEN_FDS ? > > Yes, our reference implementation actually does that. But we didn't want > to rely on that, simply because handling the environ[] array is so messy, > since memory allocation is not clear and the whole thing is not > thread-safe. In many case environ[] should probably be considered a > read-only data structure during runtime. I beg to differ, at least if we're talking about languages where you are able to just let a single thread run (not sure about Java): Simply document that the daemon should read and unset LISTEN_FDS (using unsetenv() instead of messing with environ manually) while there is only a single thread. That is, if you really must use environment variables for passing that information... Others have mentioned it already: The environment is for information that is meant to be long-lived and shared between processes, it should be feasible to pass this information via a command line option instead. Even more so if handling of the environment is so messy. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils@xxxxxxxxxx nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
