Lots of "Software caused connection abort" messages appearing in apache log #119

drtjmb · 2013-08-12T15:28:23Z

We are correctly trapping the client abort in an eval {} but I think the error message from apache has changed in recent versions / is different is some versions?

eg - Apache 2.2.22-1ubuntu1.4 message is:

:Apache2 IO write: (103) Software caused connection abort at [...]

which won't match the regexp in Apache::Storage::handler():

                # eval threw an error
                # If the software (web client) stopped listening
                # before we stopped sending then that's not a fail.
                # even if $rv was not set
                if( $@ !~ m/^Software caused connection abort/ )
                {
                        EPrints::abort( "Error in file retrieval: $@" );
                }

MrkGrgsn · 2013-08-13T00:01:01Z

Our error log (3.2.7) is also full of these errors. Apache is 2.2.7 on RHEL5 64bit.

drtjmb · 2013-08-13T08:52:42Z

Can you try changing the regexp (remove the '^').

I think EPrints should suppress these messages from the log but the
regexp is failing to match.

On 13/08/13 01:01, Mark Gregson wrote:

Our error log (3.2.7) is also full of these errors. Apache is 2.2.7 on
RHEL5 64bit.

—
Reply to this email directly or view it on GitHub
#119 (comment) Bug
from
https://github.com/notifications/beacon/L17L0tPPBiaot5bV7knnxvPLGwaGUFk9KyzrwFTrEm2CJAmYU7e-C5SihRj5RGcP.gif

Timothy Miles-Board
EPrints Services
School of Electronics and Computer Science
University of Southampton, UK
+44 (0)23 8059 3980 tmb@ecs.soton.ac.uk
http://www.eprints.org/services/
Consultancy - Training - Hosting

jesusbagpuss · 2013-08-13T09:10:03Z

Is masking these the right option under all circumstances?

I’ve noticed them in our logs too, but never got to the bottom of whether I should be concerned about them…

From: Tim Miles-Board [mailto:notifications@github.com]
Sent: 13 August 2013 09:53
To: eprints/eprints
Subject: Re: [eprints] Lots of "Software caused connection abort" messages appearing in apache log (#119)

Can you try changing the regexp (remove the '^').

I think EPrints should suppress these messages from the log but the
regexp is failing to match.

On 13/08/13 01:01, Mark Gregson wrote:

Our error log (3.2.7) is also full of these errors. Apache is 2.2.7 on
RHEL5 64bit.

—
Reply to this email directly or view it on GitHub
#119 (comment) Bug
from
https://github.com/notifications/beacon/L17L0tPPBiaot5bV7knnxvPLGwaGUFk9KyzrwFTrEm2CJAmYU7e-C5SihRj5RGcP.gif

Timothy Miles-Board
EPrints Services
School of Electronics and Computer Science
University of Southampton, UK
+44 (0)23 8059 3980 tmb@ecs.soton.ac.ukmailto:tmb@ecs.soton.ac.uk
http://www.eprints.org/services/
Consultancy - Training - Hosting

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/119#issuecomment-22551208.

drtjmb · 2013-08-13T09:25:29Z

Same problem appears in perl_lib/EPrints/Page/Text.pm in 3.2:

 60         eval { print $self->{page_text}; };
 61         if( $@ && $@ !~ m/^Software caused connection abort/ )
 62         {
 63                 EPrints::abort( "Error in send_page: $@" );
 64         }

sebastfr · 2013-08-13T10:45:16Z

Page.pm also throws that error on 3.3

               if( $@ !~ m/^Software caused connection abort/ )
                {
                        EPrints::abort( "Error in send_page: $@" );
                }
                else
                {
                        die $@;
                }

But anyway, which behaviour would you like to see here? This error is caused by the client closing the socket so it doesn't seem to be a major problem.

jesusbagpuss · 2013-08-13T10:50:07Z

As I said, I never understood whether I should be worried about these or not. If it’s always caused by a client closing the socket, yes, throw it away.
If there are other things that could cause it (someone like me doing some bad perl ;o), it might be useful?

If it’s always a useless error, why is it generated?

Cheers,
John

From: Sebastien Francois [mailto:notifications@github.com]
Sent: 13 August 2013 11:45
To: eprints/eprints
Cc: John Salter
Subject: Re: [eprints] Lots of "Software caused connection abort" messages appearing in apache log (#119)

Page.pm also throws that error on 3.3

           if( $@ !~ m/^Software caused connection abort/ )

            {

                    EPrints::abort( "Error in send_page: $@" );

            }

            else

            {

                    die $@;

            }

But anyway, which behaviour would you like to see here? This error is caused by the client closing the socket so it doesn't seem to be a major problem.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/119#issuecomment-22556477.

drtjmb · 2013-08-13T11:01:15Z

It's generated when apache tries to write to a connection that's already
been closed by a client.

EPrints does the right thing - if when writing to a connection the
client closes the connection it just catches that exception and ends
silently.

The bug is that it is not in fact silent because the regexp does not
match - either we never got it right in the first place or it used to
work but now the message has changed in apache (instead of starting with
"Software caused connection abort" that error is prefixed with some
additional info - see the entries from the log that I pasted).

So fix as far as I can see is just to remove the '^' from the regexp in
both Storage.pm and Page.pm.

On 13/08/13 11:50, jesusbagpuss wrote:

As I said, I never understood whether I should be worried about these or
not. If it’s always caused by a client closing the socket, yes, throw
it away.
If there are other things that could cause it (someone like me doing
some bad perl ;o), it might be useful?

If it’s always a useless error, why is it generated?

Cheers,
John

From: Sebastien Francois [mailto:notifications@github.com]
Sent: 13 August 2013 11:45
To: eprints/eprints
Cc: John Salter
Subject: Re: [eprints] Lots of "Software caused connection abort"
messages appearing in apache log (#119)

Page.pm also throws that error on 3.3

if( $@ !~ m/^Software caused connection abort/ )

{

EPrints::abort( "Error in send_page: $@" );

}

else

{

die $@;

}

But anyway, which behaviour would you like to see here? This error is
caused by the client closing the socket so it doesn't seem to be a major
problem.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/119#issuecomment-22556477.

—
Reply to this email directly or view it on GitHub
#119 (comment) Bug
from
https://github.com/notifications/beacon/L17L0tPPBiaot5bV7knnxvPLGwaGUFk9KyzrwFTrEm2CJAmYU7e-C5SihRj5RGcP.gif

Timothy Miles-Board
EPrints Services
School of Electronics and Computer Science
University of Southampton, UK
+44 (0)23 8059 3980 tmb@ecs.soton.ac.uk
http://www.eprints.org/services/
Consultancy - Training - Hosting

sebastfr · 2013-08-13T11:17:09Z

Note that in 3.3, Page.pm will throw that error, always: either via EPrints::abort() or via die(). My understanding is that code execution must stop if the page isn't successfully sent to the client for whatever reason.

UmbrellaDish · 2013-11-19T14:59:47Z

Hi, I suspect that correcting or rather suppressing this error at logging level is not quite sufficient on a larger scale. The callback routine in said Storage.pm module is just sub { print $[0] }, but what can $[0] be? Can it be a whole PDF stream of, say, some hundreds of megabytes? If that is the case, syswrite() instead of print() approach seems preferable to me since it would write $buffersize bytes at once only, thus it would be less data the system tries to write to a socket suddenly closed, enabling apache to destroy the invalidated response sooner and to be, in the end, more responsive when exposed to parallelized downloading, badly designed crawlers and alike.

sebastfr · 2013-11-19T15:29:08Z

By default it would be Plugin::Storage::Local::retrieve running the following:

        my $buffer;
        my $bsize = $n > 65536 ? 65536 : $n;
        while(sysread($fh,$buffer,$bsize))
        {
                $rc &&= &$f($buffer);
                last unless $rc;

$f = sub { print $[0] } so $[0] is $buffer above, enclosed in a sysread with default read size of 64kb. So the behaviour seems correct i.e. it won't try to write to a closed socket.

UmbrellaDish · 2013-11-19T15:58:07Z

Hi, thank you for replaying so soon, but then is STDOUT binmode and/or autoflushing ($|=1)? As far as i know, print is buffering internally as well to flush not until newline, so simply subsequent print() would be of no avail. But in modperl environment, autoflush might well be on by default, dunno.

sebastfr · 2013-11-19T16:24:12Z

Wouldn't print's buffer flush when the sub {} it's enclosed in returns?

Cos the code isn't:

while() {
print $CHUNK;
}

but

while() {
&sub{ print $CHUNK; }
}

UmbrellaDish · 2013-11-20T08:02:39Z

No, that doesn't matter.

% perl -e '@a = qw(please imagine a very long bytestream here with no newline); $func = sub { print $_[0] }; while ( my $snippet = shift @a ) { warn "dummy output to stderr"; $func->($snippet); }'
dummy output to stderr at -e line 1.
dummy output to stderr at -e line 1.
dummy output to stderr at -e line 1.
dummy output to stderr at -e line 1.
dummy output to stderr at -e line 1.
dummy output to stderr at -e line 1.
dummy output to stderr at -e line 1.
dummy output to stderr at -e line 1.
dummy output to stderr at -e line 1.
dummy output to stderr at -e line 1.
pleaseimagineaverylongbytestreamherewithnonewline

Related to eprints#119

phluid61 added a commit to QUTlib/eprints that referenced this issue Jul 28, 2014

log interrupted downloads as 499

cc46ff6

Related to eprints#119

phluid61 mentioned this issue Jul 28, 2014

log interrupted downloads as 499 #253

Merged

jb4 added the area: low level label Dec 1, 2017

eprints / eprints Public

Lots of "Software caused connection abort" messages appearing in apache log #119

Lots of "Software caused connection abort" messages appearing in apache log #119

drtjmb commented Aug 12, 2013

MrkGrgsn commented Aug 13, 2013

drtjmb commented Aug 13, 2013

jesusbagpuss commented Aug 13, 2013

drtjmb commented Aug 13, 2013

sebastfr commented Aug 13, 2013

jesusbagpuss commented Aug 13, 2013

drtjmb commented Aug 13, 2013

sebastfr commented Aug 13, 2013

UmbrellaDish commented Nov 19, 2013

sebastfr commented Nov 19, 2013

UmbrellaDish commented Nov 19, 2013

sebastfr commented Nov 19, 2013

UmbrellaDish commented Nov 20, 2013

eprints / eprints Public

Lots of "Software caused connection abort" messages appearing in apache log #119

Lots of "Software caused connection abort" messages appearing in apache log #119

Comments

drtjmb commented Aug 12, 2013

MrkGrgsn commented Aug 13, 2013

drtjmb commented Aug 13, 2013

jesusbagpuss commented Aug 13, 2013

drtjmb commented Aug 13, 2013

sebastfr commented Aug 13, 2013

jesusbagpuss commented Aug 13, 2013

drtjmb commented Aug 13, 2013

sebastfr commented Aug 13, 2013

UmbrellaDish commented Nov 19, 2013

sebastfr commented Nov 19, 2013

UmbrellaDish commented Nov 19, 2013

sebastfr commented Nov 19, 2013

UmbrellaDish commented Nov 20, 2013