httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: 2.0.40 (UNIX), mysterious SSL connections to self
Date Fri, 30 Aug 2002 02:31:05 GMT
On Thu, Aug 29, 2002 at 09:21:27PM -0400, Jeff Trawick wrote:
> "" <> 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.


View raw message