httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r1000593 - in /httpd/httpd/trunk: CHANGES server/util_script.c
Date Thu, 23 Sep 2010 22:39:10 GMT
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.


Mime
View raw message