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@xxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
