On 9/23/2010 3:59 PM, Jeff Trawick wrote: > On Thu, Sep 23, 2010 at 4:02 PM, William A. Rowe Jr. <[email protected] > <mailto:[email protected]>> wrote: > > On 9/23/2010 2:50 PM, [email protected] <mailto:[email protected]> 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.
