[squid-users] assertion failed: client_side.cc:1515: "connIsUsable(http->getConn())

[Dan Charlesworth]

Thanks Eliezer …

We've only ever used `kill` as very last resort when the squid process wouldn’t respond to anything else.

Anyway, I think I missed what led you to think the crash is related to the reply_body_max_size rules' external ACL as opposed to the many others we define?

That would certainly narrow it down a lot further than before.

Cheers
Dan

> On 20 Feb 2015, at 2:57 pm, Eliezer Croitoru <eliezer at ngtech.co.il> wrote:
> 
> Hey Dan,
> 
> I am not the best at reading squid long debug output and it is needed in order to understand the path that the request is traveling between the ACLs and helper to determine if the issue is since the connection is unusable because of a helper or because of another reason.
> 
> And so from what you describe I assume that the needed helper\external ACL is a fake one so a python helper is out of the question for such a purpose.
> The fact that it's crashing describes some kind of failure from the combination of something.
> In order to test if the issue is because of the helper or something related to the existence of this specific helper for the reply body max try to disable this helper and use only the basic limit, while it will force you to not show a nice deny info page it will prevent the some of the issues from happening.
> 
> From stability point of view running all these kill -9 what so ever is a very wrong approach.
> The crashes else then causing "down time" causing a much deeper issue.
> Assuming that the users transactions are important these crashes are damaging in many cases even more then any "down time".
> I know that some admins do not agree with my approach but a stable service is one of the basic fundamentals for success and happiness!!
> 
> I must admit that there are cases which a kill -9 can help but it has it's price.
> 
> Just asking loudly from both CEO + SYSADMIN + CLIENTS + others:
> What would you prefer?
> - stability based a good product
> - stability based on patches
> - stability based on human resources recruitment's
> - stability based on some unclosed known bugs
> - stability based on 1k programmers work
> - stability based on protocol compatibility
> ....
> 
> And I must stop here with the list since the above list can become very long and which will prove that humans can look at the same picture and see many different things.
> 
> Eliezer
> 
> * I am almost sure that you may use a "fake" acl that will match all requests instead of using an external_acl helper that will help you to "select" the 100MB limit.
> 
> On 20/02/2015 05:34, Dan Charlesworth wrote:
>> Installed v3.4.12 and almost went a whole day without this crash.
>> Ended up rearing its head during a spike in traffic after lunch. Seems
>> to be more prone to occurring when the HTTP requests per second
>> reaches about 100.
>> 
>> I have a script running that runs a squid reload whenever this crash
>> occurs and that seems to limit the impact (downtime) to a few
>> seconds—but occasionally Squid seems to get deadlocked by the crash
>> and needs to be killed (sometimes with -9) before it can be restarted.
>> 
>> In lieu of being able to diagnose and fix this, does anyone have any
>> other creative ideas as to limiting its impact?
>> 
>> Thanks
>> Dan
>> 
>> 
>> On 12 February 2015 at 09:51, Dan Charlesworth <dan at getbusi.com> wrote:
>>> Hey Eliezer
>>> 
>>> With the response_size_100 ACL definition:
>>> - 100 tells the external ACL the limit in MB
>>> - 192.168.0.10 tells the external ACL the squid IP
>>> 
>>> I think one or both of these is only needed to build the deny page. You can’t use deny_info with reply_body_max_size so we had to customise the ERR_TOO_BIG source to do a redirect to our own page.
>>> 
>>> The http_access allow line is because result caching cannot alter the EXT_LOG for fast ACLs as cache lookups include the EXT_LOG, so we need to check the result twice to alter the EXT_LOG and then have the result cached against the altered EXT_LOG.
>>> 
>>> Cheers
>>> Dan
>>> 
>>>> On 11 Feb 2015, at 11:09 pm, Eliezer Croitoru <eliezer at ngtech.co.il> wrote:
>>>> 
>>>> Hey Dan,
>>>> 
>>>> First I must admit that this squid.conf is quite complicated but kind of self explanatory.
>>>> 
>>>> I have tried to understand the next lines:
>>>> # File size (download) restrictions
>>>> acl response_size_100 external response_size_type 100 192.168.0.10
>>>> http_access allow response_size_100 response_size_100
>>>> reply_body_max_size 100 MB response_size_100
>>>> 
>>>> But I am unsure how it works with external_acl exactly.
>>>> If you wish to deny 100MB size files you should have only one rule for the reply body max size, what are the others for exactly?
>>>> 
>>>> Eliezer
>>>> 
>>>> * I might missing some concepts some sorry in advance.
>>>> 
>>>> On 11/02/2015 00:30, Dan Charlesworth wrote:
>>>>> Hi Eliezer
>>>>> 
>>>>> Took a while to get this up—sorry about that. Here’s an example of a production config of ours (with some confidential stuff necessarily taken out/edited):
>>>>> https://gist.github.com/djch/92cf44440b04afbd7917  <https://gist.github.com/djch/92cf44440b04afbd7917>
>>>>> 
>>>>> Let me know if there’s any other info I can provide that might point towards the cause of this crash.
>>>>> 
>>>>> And thanks again for taking a look.
>>>> 
>>>> 
>>> 
> 
>