httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: svn commit: r1000593 - in /httpd/httpd/trunk: CHANGES server/util_script.c
Date Sat, 25 Sep 2010 12:12:43 GMT
On Fri, Sep 24, 2010 at 6:30 PM, William A. Rowe Jr. <>wrote:

> On 9/24/2010 12:09 PM, Jeff Trawick wrote:
> > On Fri, Sep 24, 2010 at 12:50 PM, William A. Rowe Jr. <
> > <>> 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
> >     >
> >     > - 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
> 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

> > 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.)

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)
> (whoops!)
> (whoops!)

I guess "whoops" means we don't document it


looks like poor advice to me

> or as encountered 300k+ times in google;
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

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

View raw message