On 06/13/2013 08:22 AM, guest01 wrote:
> I found these messages:
> 2013/06/13 03:49:42| essential ICAP service is down after an options
> fetch failure: icap://10.122.125.48:1344/wwreqmod [down,!opt]
> 2013/06/13 11:09:33.530| essential ICAP service is suspended:
> icap://10.122.125.48:1344/wwreqmod [down,susp,fail11]
>
> What does down,!opt or down,susp,fail11 mean?
Both are lists of service states. Individual states are documented below:
* down: According to source code comments:
A service with a fresh cached OPTIONS response and without many failures
is an "up" service. All other services are "down". A service is "probed"
if we tried to get an OPTIONS response from it and succeeded or failed.
A probed down service is called "broken".
The number of failures required to bring an up service down is
determined by icap_service_failure_limit in squid.conf.
As a bootstrapping mechanism, ICAP transactions wait for an unprobed
service to get a fresh OPTIONS response.
We do not initiate ICAP transactions with a broken service, but will
eventually retry to fetch its options in hope to bring the service up.
A service that should no longer be used after Squid reconfiguration is
treated as if it does not have a fresh cached OPTIONS response. We do
not try to fetch fresh options for such a service. It should be
auto-destroyed by refcounting when no longer used.
* !opt: Squid does not have a usable OPTIONS response for this service.
* susp: A "suspended" service that is temporary not used by Squid. The
icap_service_revival_delay directive in squid.conf determines when the
service will be probed again. Currently, the only reasons for service
suspension are failures.
* fail11: This service has seen 11 failures. See
icap_service_failure_limit in squid.conf.documented.
Again, you need to figure out why Squid cannot get OPTIONS from the ICAP
service. Unfortunately, Squid is not very good at reporting transaction
failures. Elevated cache.log debugging and using icap_log are two
recommended methods for determining their causes.
HTH,
Alex.
Received on Thu Jun 13 2013 - 17:10:01 MDT
This archive was generated by hypermail 2.2.0 : Fri Jun 14 2013 - 12:00:29 MDT