Re: new daedalus build

[Jeff Trawick <tr...@attglobal.net>]

Greg Ames <gr...@remulak.net> writes:

> I put a new apache 2.0 build up on daedalus for a while this afternoon. 
> This was from a cvs up done early this afternoon.  It was serving
> requests like gangbusters for about a minute and a half.  But I had to
> take it back down because it was also spewing the following stuff to the
> error logs at a pretty high rate:
> 
> [Fri Jun 15 14:20:21 2001] [error] (32)Broken pipe: core_output_filter:
> writing data to the network
> [Fri Jun 15 14:20:24 2001] [error] (57)Socket is not connected:
> core_output_filter: writing data to the network
> [Fri Jun 15 14:20:24 2001] [error] (32)Broken pipe: core_output_filter:
> writing data to the network
> [Fri Jun 15 14:20:25 2001] [error] (57)Socket is not connected:
> core_output_filter: writing data to the network
> [Fri Jun 15 14:20:25 2001] [error] (32)Broken pipe: core_output_filter:
> writing data to the network
> [Fri Jun 15 14:20:27 2001] [error] (57)Socket is not connected:
> core_output_filter: writing data to the network
> [Fri Jun 15 14:20:27 2001] [error] (32)Broken pipe: core_output_filter:
> writing data to the network       
> 
> I *think* this is normal stuff for a production server, and that maybe
> the log level just needs tweaking.  I almost convinced Jeff of this too,
> but it sounds like he wants to make sure there's not some more serious
> breakage going on.

"(32)Broken pipe" is certainly business as usual.

I was curious about "(57)Socket is not connected".  After looking
through the kernel sources it seems that this is a similar error but
in a later TCP state.  This is returned when SS_ISCONNECTED is off and
we try to write.  SS_ISCONNECTED gets cleared (for TCP, at least) by
sodisconnect(), which gets called when we enter FIN_WAIT_2 or
TIME_WAIT state.  I'm no TCP expert, but I'm pretty confident that
this is a normal error.

It is easy to see why we're getting these log messages with the
current code but not with 2.0.16 which has been running on daedalus
for a while.  Right after 2.0.16 David Reid moved a ap_log_error()
call from send_the_file() to the core output filter.  We didn't see
errors in send_the_file() on daedalus before because FreeBSD will take
the apr_sendfile() path, bypassing the only 2.0.16 code which would
log this type of error.

The "fix" is to bump the severity down from APLOG_ERR to something
lower.  I'll look to 1.3 for guidance...  If no guidance found I'll
make it APLOG_NOTICE.

> Anyway, the 2.0 code base is in pretty good shape at the moment IMO. 
> I'd like to see it tagged once we do something about these log
> errors.

I think it likely that current CVS is the most stable yet.  Certainly
it fixes some issues that have caused some grief and beyond the noisy
log I don't know of anything which is regressed when compared with
2.0.16.

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Re: new daedalus build

[David Reid <dr...@jetnet.co.uk>]

> I was curious about "(57)Socket is not connected".  After looking
> through the kernel sources it seems that this is a similar error but
> in a later TCP state.  This is returned when SS_ISCONNECTED is off and
> we try to write.  SS_ISCONNECTED gets cleared (for TCP, at least) by
> sodisconnect(), which gets called when we enter FIN_WAIT_2 or
> TIME_WAIT state.  I'm no TCP expert, but I'm pretty confident that
> this is a normal error.
>
> It is easy to see why we're getting these log messages with the
> current code but not with 2.0.16 which has been running on daedalus
> for a while.  Right after 2.0.16 David Reid moved a ap_log_error()
> call from send_the_file() to the core output filter.  We didn't see
> errors in send_the_file() on daedalus before because FreeBSD will take
> the apr_sendfile() path, bypassing the only 2.0.16 code which would
> log this type of error.

Yeah, before then we were ignoring the error and it hid a nasty bug that
needed fixing.  ISTR you sat beside me at apachecon while I added that one
:)  Thanks for fixing the priortiy.

david