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