On Fri, Sep 24, 2010 at 6:30 PM, William A. Rowe Jr. <[email protected]>wrote:
> On 9/24/2010 12:09 PM, Jeff Trawick wrote: > > On Fri, Sep 24, 2010 at 12:50 PM, William A. Rowe Jr. < > [email protected] > > <mailto:[email protected]>> wrote: > > > > On 9/24/2010 11:12 AM, Rainer Jung wrote: > > > > > > I guess I'm also missing the bigger picture, but: > > > > > > - at first sight it sounds very reasonable to provide the > LD_LIBRARY_PATH as well > > > > > > - it might result in problems, if the binary to start uses system > libs, which exist in > > > LD_LIBRARY_PATH and in system default locations in incompatible > versions. IMHO this is > > > more a theoretical problem. E.g. the apr libs are versioned via the > soname such that the > > > runtime linker won't link against a wrong version. > > > > But these same problems would be true at the shell, prior to invoking > httpd, no? > > > > > > httpd could pick up library paths from the shell, but it could also pick > up paths from > > bin/envvars; the latter is specifically tailored for dependencies > bundled+built with httpd > > (and same ABI/debug-ability/etc.); for the slim cases where those defs > are not irrelevant > > for the normal CGI/FastCGI, I dunno whether it would be good or bad more > often > > AIUI - apachectl triggers bin/envvars, which injects the appropriate > LD_LIBRARY_PATH, > yet this would still not be passed to child processes without my suggested > commit, right? > bin/envvars puts it in the shell used to start httpd, so it works just like PassEnv > > > This could be discussed purely in terms of features we already have: > > > > Do admins find 'SetEnv LD_LIBRARY_PATH foo' or 'PassEnv LD_LIBRARY_PATH' > to solve their > > problem most often? > > How often is it problematic to use 'PassEnv LD_LIBRARY_PATH'? > > Frequently enough to be a FAQ/documented? (And sometimes not well.) > > http://httpd.apache.org/docs/2.2/mod/mod_env.html#passenv > I saw that too, but disrespected it as a real world example. (There's also the example "UnsetEnv LD_LIBRARY_PATH", which may become more useful now ;) ) > The original mod_fcgid config docs (cannot find them anymore via google, > even) > > http://httpd.apache.org/docs/2.2/mod/mod_cgi.html (whoops!) > http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html (whoops!) > I guess "whoops" means we don't document it > http://bugs.php.net/bug.php?id=49173&edit=1 > looks like poor advice to me > > or as encountered 300k+ times in google; > http://s.apache.org/cOb > > This one yields 181,000 results: >httpd ld_library_path setenv< This one yields 3,850: >httpd ld_library_path passenv< So many of these are unhelpful though. E.g., some of those references to PassEnv say to first modify the script used to start Apache to include LD_LIBRARY_PATH then code PassEnv in httpd.conf, which seems clumsy. httpd.conf is the place to consolidate both. --/-- I guess I'm at the YMMV stage; I think the PassEnv semantics for LD_LIBRARY_PATH still means that the user ends up configuring the paths in the shell script used to start httpd or bin/envvars, which seems worse than just putting SetEnv in httpd.conf. And automatically passing through the value required for httpd to run could have occasional negative consequences. (But it is unclear to me that it either helps or hurts with any interesting frequency.) At any rate, I suggest that you edit the CHANGES to remove the reference to piped loggers and fix the suggestion that PassEnv is still applicable. One possibility: core: For script invocation, pass the system library path (LD_LIBRARY_PATH or other platform-specific variable) by default; PassEnv is no longer necessary for that. As before, use SetEnv to configure a specific value different from that required by httpd.
