Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <3E88346E.1040404@attglobal.net>
Date: Mon, 31 Mar 2003 07:28:30 -0500
From: Jeff Trawick <trawick@attglobal.net>
Reply-To: trawick@attglobal.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Apache 2.0.45 -alpha tarball candidates for testing
References: <5.2.0.9.2.20030331015134.02ac7e18@pop3.rowe-clan.net>
In-Reply-To: <5.2.0.9.2.20030331015134.02ac7e18@pop3.rowe-clan.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

William A. Rowe, Jr. wrote:
> The release tarball (and win32 .zip file) are now available for testing from;
> 
>   http://httpd.apache.org/dev/dist/

Note that child error functions other than in mod_cgid *are* horked due 
to log files being closed, but playing with mod_ext_filter and mod_cgi I 
don't see anything catastrophic, and I don't see a regression from the 
previous release.  The attempt to write to the log file gets EBADF in 
the newly-created-but-doomed child process, and life goes on.

As for the child error function support for failure to start piped 
loggers, that path is extremely hard to hit with the default code 
because the extra possible checking for errors is enabled 
(apr_procattr_error_check_set()).  After commenting out the calls to 
apr_procattr_error_check_set() in log.c, I don't see any regression.

uninteresting details of playing with piped loggers:

I. httpd 2.0.45-alpha, no apr_procattr_error_check_set, prefork:

A. bad piped access log:

log message to stderr regarding the problem
[error] (2)No such file or directory: exec of '/usr/bin/doesnotexist' failed

log message to error log stating the problem

regular attempts to restart it (that logic was broken in previous releases)

it looks like there is always a zombie process, but it is a different 
zombie since there is some lag between a failed attempt to exec the 
piped log and when the MPM wakes up to reap status

httpd is operational

B. bad piped error log:

log message to stderr regarding the problem

httpd is operational

II. httpd 2.0.44, unpatched, prefork:

bad piped access log:

no message to stderr

httpd is operational

bad piped error log:

no message to stderr

httpd is operational