Hi Stas & MP list,
I tried causing this error by opening sockets to the web server, then
killing (-9) the client, but that didn't work. However, every morning
like clockwork the scanning service (ScanAlert) hits our site and
causes this problem... so, while I cannot intentionally cause the
error by myself, I know when our scanning service will do so, and I
could put some additional code in place to watch for it. If there are
additional debug/traps that you could suggest, I'd like to try. Any
ideas?
thanks
Jeff
On 5/2/05, Stas Bekman <[EMAIL PROTECTED]> wrote:
> Jeff Ambrosino wrote:
> > 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.
>
> I think the first step is be able to reliably reproduce that. Let me see
> if I can figure out how to do that.
>
> --
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
