[squid-users] ICAP too many errors and suspensions

[Alex Rousskov]

On 2024-01-09 19:32, John Zhu wrote:

> We have the same “suspension” issue when “too many failure”.

To clarify, you have a "failure" issue. Suspension after 
icap_service_failure_limit is normal/expected.


> https://www.mail-archive.com/squid-users@lists.squid-cache.org/msg22187.html

FWIW, AFAICT, the original problem was attributed to ClamAV service 
timing out Squid ICAP connection attempts while reloading its virus 
definitions:

https://lists.squid-cache.org/pipermail/squid-users/2021-February/023293.html


> 14:24:24 kid1| suspending ICAP service for too many failures 
> 14:24:24 kid1| essential ICAP service is suspended:

> We tried enable the debug_options ALL,1 93,7
> 
> But have not reproduced suspensions and did not find the root cause.

Please note that it is probably enough to reproduce a single failure; 
reproducing suspensions is better, but can be more difficult, and is 
probably less important. If you cannot see individual failures until the 
service is suspended, then use "icap_service_failure_limit 1" during 
your test, so that the service is suspended after the _first_ failure.

If "ALL,1 93,7" debugging prevents you from reproducing the problem, try 
debug_options set to "ALL,1 93,5", then "ALL,1 93,4", etc.


> Checking the source code, can we simply comment out the lines:
> 
> scheduleUpdate(squid_curtime+ TheConfig.service_revival_delay);
> announceStatusChange("suspended", true);

I have to decline this opportunity to discuss Squid source code 
modifications on the squid-users mailing list. If you want to disable 
service suspensions without understanding why ICAP transactions fail, 
then use a very large icap_service_failure_limit in squid.conf.


HTH,

Alex.