Ok, I tried this approach, and it only partially worked; unfortunately
my httpd procs are still dying, and APR::Error doesn't seem to pass
anything. Here's the error I got _before_ wrapping $f->print in the
eval:
[Sun May 01 05:12:21 2005] [error] [client X.X.X.X]
Apache::Filter::print: (104)Connection reset by peer at
/var/httpd/lib/perl/MyFilter.pm line
453n\tMyFilter::handler('Apache::Filter=SCALAR0x87106a8)',
'APR::Brigade=SCALAR(0x86eac6c)') called at -e line 0\n\teval {...}
called at -e line 0\n
Apache::Filter: (103) Software caused connection abort at -e line 0
And here's how it looks in the error+log _after_ putting in the eval wrapper:
Apache::Filter: (103) Software caused connection abort at -e line 0
Notice there's no timestamp next to the Apache::Filter error, so it
appears that something is writing that message directly to STDERR.
The main problem is that with or without the eval, the httpd process
is getting killed, and it seems to be taking a while for the httpd
parent to realize this and start new procs (I'm using MPM prefork.)
Here's the code I'm using to trap the $f->print failure:
if ( defined($f->ctx) ) {
eval { $f->print ($f->ctx) };
if ($@ && ref $@) {
$r->log_error("WARNING " . "\$f->print
exception: $@");
}
}
Any suggestions?
And FWIW, I haven't been able to reproduce these conditions
artificially, I just have to wait until it occurs in the wild. A
"wild" event that occurs regularly, however, is a daily vulnerability
scan by ScanAlert (a service that we pay for.) They throw all sorts
of potential http exploits at our server and notify us of any problems
- I'm guessing some of their tests do some funky socket operations
that cause Apache::FIlter to choke.
thanks
Jeff
On 5/2/05, Stas Bekman <[EMAIL PROTECTED]> wrote:
> > Actually, it looks like using APR::Error [1] and wrapping $f->print in
> > an eval would do the trick...?
>
> That's correct, Jeff. eval and check for APR::Const::ECONNRESET as
> explained in [1]
>
> > [1] http://perl.apache.org/docs/2.0/api/APR/Error.html
>
> Please report whether this did the trick. We ought to document this one,
> since many will encounter this issue.
