Jeff Ambrosino wrote:
Stas, just a quick closure... the patch has survived several ScanAlert
scans without any aborted httpd children. This was the original way I
discovered the problem (www.scanalert.com - they periodically throw
all sorts of weird hack/exploit traffic at our server as an
Jeff Ambrosino wrote:
Stas, just a quick closure... the patch has survived several ScanAlert
scans without any aborted httpd children. This was the original way I
discovered the problem (www.scanalert.com - they periodically throw
all sorts of weird hack/exploit traffic at our server as an
Jeff? Could you please try that patch that I've sent earlier? I think it's
right, but I was still not very successful at reproducing your problem on
the HTTP level. Thanks.
Stas Bekman wrote:
Stas Bekman wrote:
Jeff Ambrosino wrote:
Ok, this is going to be tough for me to test because I'm
Ok, this is going to be tough for me to test because I'm still on RC4,
so it's not yet converted to the new Apache2 naming. I'll still try
to make/test the svn snapshot, though (which also gives me a good
reason to get more familiar with subversion.) I'll email what I find
out.
thanks Stas!
Jeff Ambrosino wrote:
Ok, this is going to be tough for me to test because I'm still on RC4,
so it's not yet converted to the new Apache2 naming. I'll still try
to make/test the svn snapshot, though (which also gives me a good
reason to get more familiar with subversion.) I'll email what I find
Stas Bekman wrote:
Jeff Ambrosino wrote:
Ok, this is going to be tough for me to test because I'm still on RC4,
so it's not yet converted to the new Apache2 naming. I'll still try
to make/test the svn snapshot, though (which also gives me a good
reason to get more familiar with subversion.) I'll
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
Jeff Ambrosino 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
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:
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]
I've got an HTTP output filter running on mp2-RC4 + httpd2.0.54 +
libapreq2-2.04_03-dev, and occasionally I see these messages in my
error_log:
[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/MyOutputFilter.pm line
Actually, it looks like using APR::Error [1] and wrapping $f-print in
an eval would do the trick...?
Jeff
[1] http://perl.apache.org/docs/2.0/api/APR/Error.html
On 5/1/05, Jeff Ambrosino [EMAIL PROTECTED] wrote:
[Sun May 01 05:12:21 2005] [error] [client X.X.X.X]
Apache::Filter::print:
12 matches
Mail list logo
