Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3E7B635D.1050205@attglobal.net>
Date: Fri, 21 Mar 2003 14:09:17 -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
CC: dev@apr.apache.org
Subject: Re: cvs commit: httpd-2.0/server/mpm/worker pod.c
References: <20030321162355.GG30312@redhat.com>
 <0CD4F2EE-5B4C-11D7-829A-000393B3C494@clove.org>
 <3E7B3A8D.9060404@attglobal.net> <20030321162355.GG30312@redhat.com>
 <5.2.0.9.2.20030321113401.0235e9c0@pop3.rowe-clan.net>
In-Reply-To: <5.2.0.9.2.20030321113401.0235e9c0@pop3.rowe-clan.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

William A. Rowe, Jr. wrote:
> At 10:48 AM 3/21/2003, Jeff Trawick wrote:
> 
>>backtracking uses of fd 2 up through this time is somewhat funny
>>
>>it looks like
>>
>>a) we set the error log to file descriptor 2
>>
>>b) we close file descriptor 2 and set it to /dev/null via the freopen() in apr_proc_detach
>>
>>c) we close file descriptor 2 (because of cleanup registered around step a??)
> 
> 
> Bang.  We are dup2()ing that fd, and that fd didn't have a cleanup
> (in fact it was opened APR_FILE_NOCLOSE).
> 
> Attached is a patch that uses the logic
> 
>   apr_file_dup() always registers a cleanup, inherited for 0..2, 
>   otherwise not inherited by default.
> 
>   apr_file_dup2() registers the same cleanup the original open()
>   or the toggled apr_file_inherit_[un]set had indicated.  We still
>   don't trust the original cleanup, but register the 'proper' one
>   based on the desired behavior of that target apr_file_t.

I'm a bit nervous about the existing/new special handling for 
descriptors 0-2.

Why isn't the problem this:

Apache opened stderr from the wrong pool, or failed to open it again 
when the original pool for stderr was cleaned up; in other words, it was 
cleaned up because of a pool lifetime problem in the application, not 
because 0-2 inherently need to be handled in a different special way

(and maybe in addition: Apache should be able to tell apr_proc_detach() 
to leave stderr alone if it wants fd 2 to be unchanged across the detach)