Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 84513 invoked from network); 23 Sep 2010 23:59:42 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 23 Sep 2010 23:59:42 -0000 Received: (qmail 24541 invoked by uid 500); 23 Sep 2010 23:59:41 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 24458 invoked by uid 500); 23 Sep 2010 23:59:40 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 24450 invoked by uid 99); 23 Sep 2010 23:59:40 -0000 Received: from Unknown (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Sep 2010 23:59:40 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates 209.85.215.173 as permitted sender) Received: from [209.85.215.173] (HELO mail-ey0-f173.google.com) (209.85.215.173) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Sep 2010 23:59:18 +0000 Received: by eyf18 with SMTP id 18so1058189eyf.18 for ; Thu, 23 Sep 2010 16:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=xehUyLGRi10hL3mEkJ5/z+ADXpVnVE5WMGjzbKdLIug=; b=FlV3MjVDHuVGXm41dzmpS0y5l3QKQV2GpoZvkMq3q8d4Y2cI1fYS+HnSn+Z40roUfZ tHglBtdYzzG7GsOi/qHqu9cUjmwUDUaneaUXneacd5VPPPCizAdLIDLa9LzDEi6uYpOG 6M7JAbauwSiNjqJgDx5HXLquUeGtUD4RhhbUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=IFIfgxHp8bLPMjUBcf59bUj2NzbxaZljMUaNVseuqPU3o3mMy7pJzh3bBaMMYCpM/+ 4LFUb7VC1N6+lkeMBQEP8UC0iZINmgRIyjn8MT4iyedUKTv9oNqT6stMOz8iWWJbityG 1KhDec8axsidvrtlDunPXXXFqcRnzOlOSGV+s= MIME-Version: 1.0 Received: by 10.213.42.7 with SMTP id q7mr2472489ebe.4.1285286338240; Thu, 23 Sep 2010 16:58:58 -0700 (PDT) Received: by 10.213.17.140 with HTTP; Thu, 23 Sep 2010 16:58:58 -0700 (PDT) In-Reply-To: <4C9BD70E.8070309@rowe-clan.net> References: <20100923195015.5555A23888FD@eris.apache.org> <4C9BB23B.6080302@rowe-clan.net> <4C9BD70E.8070309@rowe-clan.net> Date: Thu, 23 Sep 2010 19:58:58 -0400 Message-ID: Subject: Re: svn commit: r1000593 - in /httpd/httpd/trunk: CHANGES server/util_script.c From: Jeff Trawick To: dev@httpd.apache.org Content-Type: multipart/alternative; boundary=001636026f67a02a280490f60b8e X-Virus-Checked: Checked by ClamAV on apache.org --001636026f67a02a280490f60b8e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 23, 2010 at 6:39 PM, William A. Rowe Jr. 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 > > > wrote: > > > > On 9/23/2010 2:50 PM, 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 > > > > > 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 --001636026f67a02a280490f60b8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 23, 2010 at 6:39 PM, William A. Rowe= Jr. <wrowe@row= e-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-cla= n.net>> wrote:
>
> =A0 =A0 On 9/23/2010 2:50 PM, wrow= e@apache.org <mailto:wrowe@apach= e.org> wrote:
> =A0 =A0 > Author: wrowe
> =A0 =A0 > Date: Thu Sep 23 19:50:14 2010
> =A0 =A0 > New Revision: 1000593
> =A0 =A0 >
> =A0 =A0 > URL: http://svn.apache.org/viewvc?rev=3D1000= 593&view=3Drev
> =A0 =A0 <http://svn.apache.org/viewvc?rev=3D1000593&am= p;view=3Drev>
> =A0 =A0 > Log:
> =A0 =A0 > Because PATH and the library path are closely interrelate= d, and the cause
> =A0 =A0 > of most confusion over cgi or fcgid failures, or even sta= rting rotatelogs,
> =A0 =A0 > etc, when the server binaries have been relocated, pass t= he library path
> =A0 =A0 > 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 success= fully

Ahhh, yes. =A0There was a reason I never committed this in the first = place.
I let Ruediger's comments propel me to finishing it, but with the cavea= t
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. =A0But I need to investigate the why's again. =A0My thought, where I abandoned this p= atch,
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. =A0I need to review my notes on this next week and offe= r
the second half of the solution.

> we don't ship CGI or FastCGI binaries, so relocating httpd and adj= usting 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. =A0The mod_fcgid configuration on windows = used to be
horrid, due to missing env vars. =A0The double-whammy is how stderr is mist= reated
by mod_fcgid, and error information will not hit the log. =A0Until 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. =A0Today, this is already improved, but t= he 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 libr= ary in the same odd
> place as httpd?

No, it has more to do with PATH'ed applications relying on LD_LIB= RARY_PATH'ed
dependencies.

> or people want to rely on an envvar in the the shell used to start htt= pd to get their
> CGIs/FastCGIs working, which may result in failures when httpd is star= ted slightly differently
>
> I guess I'm missing the big picture :)

My essential argument: =A0Pass LD_LIBRARY_PATH + PATH, or let's d= rop 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/l= oader/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 exceptiona= l situations

--001636026f67a02a280490f60b8e--