Hello,
with Squid 2.1P1 (didn't check with other versions) a host is not
marked as BAD when it's just turned off aka unreachable.
Real life example, one FQDN points to 3 different IP adresses, distributed
among 3 actual systems. Squid is configured in combined cache/accel mode
to act as a poor mans load distributor for the FQDN in question.
One of the systems is up, but doesn't run a HTTP server, so connects
are refused at it's marked BAD in the ipcache, just as one would expect.
So we have 2 OK ones which are happily used in a round-robin fashion
as suggested by the Squid docs and my mediocre understanding of the
sources. If you shut down one of the remaining hosts it is _not_ marked
as BAD and users will get 504 connect timeouts (set to 20 seconds) for
the time being (stopped testing after 8 minutes). When looking at the
relevant sections of comm.c I don't see how it could timeout and _not_
being marked bad, but that is what's obviously happening. Could somebody
more familiar with the Squid source please enlighten me what's happening
here? And since it doesn't mark it BAD the other still working address
wasn't tried either to avoid the error (for the end user).
In a similar case one of the HTTP servers went into a "zombie" mode where
it still accepted connects on port 80 but never reacted to any input,
thus timing out eventually with the request_timeout value. Here as well
the origin server wasn't marked BAD, which would be the logical thing to
do (or at least a nice config option).
Last but not least I learned that unless all addresses of a FQDN turn
BAD or they expire from the ipcache a long recovered host will remain
in the BAD state. Not quite ideal in my book either.
All of this tested under Solaris 2.6, in case it makes a difference.
Dewa,
<CB>
-- // <CB> aka Christian Balzer, Tannenstr. 23c, D-64342 Seeheim, Germany \X/ CB@aichan.swb.de | Voice: +49 6257 83036, Fax/Data: +49 6257 83037 SWB - The Software Brewery - | http://www.swb.de/ | Anime no OtakuReceived on Wed Dec 02 1998 - 15:40:14 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:43:32 MST