Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Sender: trawick@bellsouth.net
To: new-httpd@apache.org
Subject: Re: cvs commit: httpd-2.0/server config.c
References: <Pine.LNX.4.21.0101021219440.7621-100000@koj>
From: Jeff Trawick <trawickj@bellsouth.net>
Date: 02 Jan 2001 17:53:29 -0500
In-Reply-To: rbb@covalent.net's message of "Tue,
 2 Jan 2001 12:28:30 -0800 (PST)"
Message-ID: <m3vgrx8t1y.fsf@adsl-77-241-65.rdu.bellsouth.net>
Lines: 53
User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

rbb@covalent.net writes:

> The core does make an explicit call to setup the stderr log file.  The
> problem is finding the error log when we don't have a server_rec.  

simple: global variable in log.c to hold the handle to the stderr log file

>                                                                      We
> can't just use stderr, because on Windows, we don't have stderr.  There
> are definite problems with this direction, but since we can't use NULL
> pools we need to get a pool from someplace.  I had hoped that we would
> have access to some global pool, which could be used for this, but
> unfortunately, all of the global pools were removed.

This assumes that we have to create the stderr log file on the fly,
which isn't the case.

> 
> Then I had hoped that we could use something from the process_rec, but
> that too isn't global.  While I agree that globals are in general a bad
> idea, in some cases, they are incredibly useful.  :-(
> 
> > Also (maybe you can confirm for me), I'm not 100% sure this need is
> > limited to Apache core code.  I fear that third-party modules must
> > also know when to call ap_log_perror().
> 
> This should just be core code, and those modules that implement pre_config
> functions.  

translation: not just core code

>              Once we get to the post_config phase, we have a
> server_rec.  As for the config directives, those should be returning the
> log messages to the caller, so those shouldn't be an issue.  Of course,
> there has already been one problem reported to me, and I am looking into
> how to fix it, although I don't see a good solution.
> 
> Basically, when we determine that we can't setgid to (unsigned int)-1, we
> seg fault.  We don't have a pool in this code, so we can't just convert to
> ap_log_perror.  I am really close to a loss as far as how to solve
> this.

Very early in init, main() can call a function which sets up the
stderr log file and saves a handle to it in a global variable
accessible by log.c functions.

I hope we don't change any more ap_log_error() calls to the version
which takes a pool parameter.

-- 
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...