HI, I'm now running HEAD (for latest SSL bump fixes) on revision 8886 on a new box pulled last Friday, so may it has those fixed. The above bug was from HEAD from early august. If that does not help, I'll try "icap_persistent_connections off". I also found ready that one should have "bypass=1" to ensure squid continue if it cannot talk to icap? icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav Thanks, Sean On 4 December 2012 15:33, Eliezer Croitoru <eliezer@xxxxxxxxxxxx> wrote: > Hey Sean and Knop, > > There was a bug in squid ICAP for a very long time since 3.1 and it there > was a patch tried and applied the last week. > > If you had problems before you can try the last 3.3 revision 12500. > I will test it myself in the next month\year. > > Eliezer > > > On 12/4/2012 4:22 PM, Knop, Uwe wrote: >> >> Hi Sean, >> >> the conversion of squid 3.1 to 3.2, we had the same error. >> We solved the problem with the parameter "icap_persistent_connections off" >> >> Bye >> UK >> >>> -----Ursprüngliche Nachricht----- >>> Von: boran@xxxxxxxx [mailto:boran@xxxxxxxx] Im Auftrag von Sean Boran >>> Gesendet: Dienstag, 4. Dezember 2012 10:49 >>> An: squid-users@xxxxxxxxxxxxxxx >>> Betreff: essential ICAP service is suspended >>> >>> Hi, >>> >>> I've been running a squid 3.3 live with SSL inspection for over a week, >>> AV >>> scanning with clamav+c-icap work fine until now (about 500k GETS per >>> day). >>> Then users started seen icap errors in their browser:: >>> >>> In the squid logs: >>> essential ICAP service is suspended: icap://127.0.0.1:1344/squidclamav >>> [down,susp,fail11] >>> >>> c-icap was then tuned a bit: >>> - increase the number of processes (now have 90) >>> - set debug=0 (less logs`: they were massive) >>> - exclude large files from scanning and certain media types >>> >>> The system was not that heavily loaded (load bout 0.3, icap getting maybe >>> 20 requests/sec), the above measure did seem to make much difference. >>> Any suggestions for avoiding this? >>> >>> Also, when this happens, squid takes a few minutes to talk to icap again: >>> 15:30:31 kid1| essential ICAP service is suspended: >>> icap://127.0.0.1:1344/squidclamav [down,susp,fail11] >>> 15:33:31 kid1| essential ICAP service is up: >>> icap://127.0.0.1:1344/squidclamav [up] >>> >>> Is there a timeout variable to ask squid to talk to icap much quick >>> again? >>> >>> Squid config: >>> icap_enable on >>> icap_send_client_ip on >>> icap_send_client_username on >>> icap_client_username_encode off >>> icap_client_username_header X-Authenticated-User icap_preview_enable >>> on icap_preview_size 1024 scanned via squidclamav Service via ICAP >>> icap_service service_req reqmod_precache bypass=1 >>> icap://127.0.0.1:1344/squidclamav adaptation_access service_req deny >>> CONNECT adaptation_access service_req allow all icap_service service_resp >>> respmod_precache bypass=0 icap://127.0.0.1:1344/squidclamav >>> adaptation_access service_resp deny CONNECT adaptation_access >>> service_resp allow all >>> >>> Sean > > > -- > Eliezer Croitoru > https://www1.ngtech.co.il > sip:ngtech@xxxxxxxxxxxx > IT consulting for Nonprofit organizations > eliezer <at> ngtech.co.il
