httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r1000593 - in /httpd/httpd/trunk: CHANGES server/util_script.c
Date Thu, 23 Sep 2010 23:58:58 GMT
On Thu, Sep 23, 2010 at 6:39 PM, William A. Rowe Jr. <wrowe@rowe-clan.net>wrote:

> On 9/23/2010 3:59 PM, Jeff Trawick wrote:
> > On Thu, Sep 23, 2010 at 4:02 PM, William A. Rowe Jr. <
> wrowe@rowe-clan.net
> > <mailto:wrowe@rowe-clan.net>> wrote:
> >
> >     On 9/23/2010 2:50 PM, wrowe@apache.org <mailto:wrowe@apache.org>
> wrote:
> >     > Author: wrowe
> >     > Date: Thu Sep 23 19:50:14 2010
> >     > New Revision: 1000593
> >     >
> >     > URL: http://svn.apache.org/viewvc?rev=1000593&view=rev
> >     <http://svn.apache.org/viewvc?rev=1000593&view=rev>
> >     > Log:
> >     > Because PATH and the library path are closely interrelated, and the
> cause
> >     > of most confusion over cgi or fcgid failures, or even starting
> rotatelogs,
> >     > etc, when the server binaries have been relocated, pass the library
> path
> >     > as paired with the system PATH.
> >
> >
> > this doesn't change anything for rotatelogs; it isn't affected by
> subprocess_env, and
> > should just need the same settings that allowed httpd to start
> successfully
>
> Ahhh, yes.  There was a reason I never committed this in the first place.
> I let Ruediger's comments propel me to finishing it, but with the caveat
> that I had forgotten the missing bit.
>
> I definitely encountered piped log failures due to the environment table.
> The non-static relocated rotatelogs binary would not start.  But I need
> to investigate the why's again.  My thought, where I abandoned this patch,
> is that this logic might be generic to invoking all ap_ processes, not just
> cgi/request level processes.
>
> So perhaps the next step is factoring this into per-request v.s. generic
> process invocation.  I need to review my notes on this next week and offer
> the second half of the solution.
>
> > we don't ship CGI or FastCGI binaries, so relocating httpd and adjusting
> our
> > LD_LIBRARY_PATH in bin/envvars won't be the adjustment needed for a CGI
> or FastCGI, so
> > passing on our setting won't help, will it?
>
> That is exactly the point.  The mod_fcgid configuration on windows used to
> be
> horrid, due to missing env vars.  The double-whammy is how stderr is
> mistreated
> by mod_fcgid, and error information will not hit the log.  Until you try to
> run in a console, and let win32 vomit popup exception windows, you won't
> have
> a clue why things don't work.  Today, this is already improved, but the
> patch
> I committed attempts to be neutral and generic across platforms.
>
> > I guess the case it helps is where the CGI or FastCGI relies on a library
> in the same odd
> > place as httpd?
>
> No, it has more to do with PATH'ed applications relying on
> LD_LIBRARY_PATH'ed
> dependencies.
>
> > or people want to rely on an envvar in the the shell used to start httpd
> to get their
> > CGIs/FastCGIs working, which may result in failures when httpd is started
> slightly differently
> >
> > I guess I'm missing the big picture :)
>
> My essential argument:  Pass LD_LIBRARY_PATH + PATH, or let's drop both.
> From an environmental/operational perspective they are two peas in a pod.
>
>
These two are somewhat different in practice.

When the path to the binary is omitted on the invocation/load, the
shell/loader/whatever finds

* executables only because of the PATH envvar
* shared libraries usually via the system search path or in the
executable/other-library's rpath

PATH always, LD_LIBRARY_PATH in exceptional situations

Mime
View raw message