Re: AW: [squid-users] essential ICAP service is suspended

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_at_ngtech.co.il> 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_at_boran.ch [mailto:boran_at_boran.ch] Im Auftrag von Sean Boran
>>> Gesendet: Dienstag, 4. Dezember 2012 10:49
>>> An: squid-users_at_squid-cache.org
>>> Betreff: [squid-users] 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_at_sip2sip.info
> IT consulting for Nonprofit organizations
> eliezer <at> ngtech.co.il
Received on Tue Dec 04 2012 - 14:55:24 MST