On Thu, Aug 29, 2002 at 09:21:27PM -0400, Jeff Trawick wrote: > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > > > Looking into the matter, I discovered that this error is logged whenever a > > connection from localhost to localhost:443 is made. The errors ALWAYS occur > > >after apachectl startssl; they never occur with apachectl start. > > I'd bet that this is idle server maintenance (taking down a child > process which isn't necessary). The non-SSL path doesn't log an error > for a dummy connect but evidently the SSL path does. > > The connect to itself isn't a bug, though it would be nice to avoid > the SSL complaints. Try swapping the order of your listen statements > to see if that gets rid of the complaints (i.e., if the dummy connect > to wake up a child is then done to the non-SSL socket).
My solution to the complaints was to use piped error logs and have a simple Perl script as the first script in a pipeline. The Perl script's only job was to remove those error messages and then pass the log line on to cronolog. The reason for taking such a measure was because the server farm was behind a pair of commercial load balancers which made TCP connections to port 80 and port 443 ** every second ** to health check that the servers were alive and accepting connections within a reasonable response time. Then, it shut down the connection, without attempting any SSL negotiation. So every second, every server was logging two SSL failure messages (from each of the redundant load balancers). Talk about noise in the logs! It would be Real Nice (tm) if these sort of SSL error messages weren't reported unless some sort of data was exchanged above the connection level. Only in those cases would the SSL error message be correct that SSL negotiation failed, as opposed to not even having started. -Glenn
