httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <redd...@attglobal.net>
Subject Re: logging APR errors
Date Fri, 14 Jul 2000 19:28:47 GMT

> On Fri, 14 Jul 2000, Greg Ames wrote:
>
> > I got the following while trying to get mod_file_cache working on Linux:
> >
> > [Tue Jul 04 17:13:59 2000] [error] [client 127.0.0.1] (22)Invalid
> > argument: mod_file_cache: iol_sendfile failed.
> >
> > Can you tell what failed without running a debugger?
> >
> > This doesn't even point me to the failing file.  But that part is easy -
> > you know it's Linux, so iol_sendfile always invokes ap_sendfile.  If you
> > go there, you will see 7 syscalls or APR calls for the current Linux
> > flavor.  So which one failed?
> >
> > Unfortunately, most of these 7 are network related which means they
> > could fail in production.  There's gotta be a better way.  I have some
> > thoughts but would like to hear other opinions first.
>
> The correct way to handle this was veto'ed at the very beginning of
> development for APR.  The correct method was to have the status be a
> complex bitmap which we could use to determine where we actually failed.
>
> Since we no longer have that option, we have to define different APR error
> codes for the different failure conditions inside of ap_sendfile.
>

There are other techniques available as well. Look back a couple of months in this list for
Jeff
Trawick's posts on this exact topic. One method mentioned at the time is to register an application
specifc (Apache in this case, or perhaps an individual MPM) error handling function with APR
at init
time. This function is called to log the specific failure (function call, failing system call,
line
of code, message string, etc.). If Apache is not interested in greater visability into APR
failures,
it simply does not register an error handler function (which implies the APR wrapper that
calls this
function must be able to handle a NULL function pointer). This is simple and very extensible.
Make
sense?

Bill (who is going to beach RSN :-)


Mime
View raw message