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@xxxxxxxxxxxxxxxxxxxxx/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.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
