On Thu, Sep 23, 2010 at 6:39 PM, William A. Rowe Jr. <[email protected]>wrote:
> 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. > > 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
