httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH] log execve() failures
Date Tue, 11 Jul 2000 15:04:34 GMT
On Tue, 11 Jul 2000, Greg Ames wrote:

> wrote:
> > We can't write to stderr inside of APR.  We don't know that stderr
> > exists, or where it points.  This works for Apache, but not for anything
> > else. 
> IMO it seems unlikely that stderr won't exist.  But suppose it doesn't -
> does it make the situation any worse to attempt to write to it?  

It can't be used at all on Windows, which is why we removed all instances
of stderr from both Apache and APR.  More importantly, imagine a program
that uses APR, but doesn't re-direct stderr to some other file.  This
program logs everything through some other file descriptor.  Now, APR is
writing to stderr, which ends up on the users console.  This is a no-no
for libraries.

> >    The best thing I can suggest, is to have ap_create_process wait on
> > the child process before it returns.  
> Seems kinda complex for a condition that doesn't exist today.  

Okay, so modify mod_cgi[d].  If the child process dies, do a wait in
there.  This will get us the same error code.

We cannot write to stderr from within a library.  There are very few
places where we currently write to stderr in APR:

apr_getpass.c:  The definition of this function writes to stderr.
apr_pools.c:    This is just for backwards compatability with Apache
		1.3.  We only do this when the user tells us to or when 
		we are in debugging mode.
apr_tables.c:   Unfortunately, nobody has ever fixed this file.  I keep
		hoping we are going to re-write these functions, but it
		hasn't happened yet.
getopt.c:       This is code directly from FreeBSD's C Run-time, and we
		only report that the program was run with an invalid option.
mm/*.c:         This is debugging code.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message