Okie dokie! boxes are crashing all over the place today so I finally have
some back traces without stuff optimised out.
Here are the details from two of these crashes which occurred on two
separate deployments—please let me know if they actually contain actionable
information now and I will
Resending this after the last attempt went into the mail server black hole:
Hey Amos
I decided I’m not confident enough in 3.5.HEAD, after last time, to go back
into production with it. Going to to do some more local testing first.
That being said, I now have 3.4.12 in production with
On 20/03/2015 1:07 p.m., Dan Charlesworth wrote:
Well I got 3.5.2 into production for a few hours and Bad Things happened:
*1) A hefty performance hit*
Load average was maybe a tad higher but CPU. memory and I/O were about the
same.
However the system seemed to top out at around 40
Well I got 3.5.2 into production for a few hours and Bad Things happened:1) A hefty performance hitLoad average was maybe a tad higher but CPU. memory and I/O were about the same. However the system seemed to top out at around 40 requests per second (on a client that usually hits 100—150 rps) and
Hello Dan:
i used 3.5.2 just now , i worried 3.5.3 isn't
very stable too ,
i use 2.7stable 9 ago , and you ?
if version is 3.xxx , which version is stablest
until now .
Best Regard
于
John -
For us the 3.4 series is definitely the stablest.
I was hoping 3.5.2 + plus a patch would avoid the error in this thread’s
subject—and it might have done—but it introduced two other major problems (for
us).
On 20 Mar 2015, at 2:29 pm, johnzeng johnzeng2...@yahoo.com wrote:
Hello
Hello Dan:
i used squid 2.7stable9 ago ,and i worried whether
squid 3.5.2 is stablest for us until now too .
and you ?
Do you think Whether version is stablest at squid
3.xxx ?
Well I got 3.5.2 into production for a few hours and
On 27/02/2015 12:25 p.m., Dan Charlesworth wrote:
Alright I got abrtd on board, finally.
Here’s a a backtrace from this morning (bt and bt full versions included
separately):
Wonderful.
Can you get a print from frame 3 please of which of the connIsUsable()
checks if failing?
gdb
Alright I got abrtd on board, finally.Here’s a a backtrace from this morning (bt and bt full versions included separately):#0 0x00397e232625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00397e233e05 in abort () at abort.c:92
#2 0x005656ef in xassert
By the way, I think Eliezer suggested I should file a bug report. There is in
fact one already filed here:
http://bugs.squid-cache.org/show_bug.cgi?id=3930
Which brings me to my next question ...
Amos, is it possible to sponsor bug fixes?
On Tue, Feb 24, 2015 at 2:47 PM, null
On 2015-02-25 15:11, d...@getbusi.com wrote:
By the way, I think Eliezer suggested I should file a bug report.
There is in fact one already filed here:
http://bugs.squid-cache.org/show_bug.cgi?id=3930
Which brings me to my next question ...
Amos, is it possible to sponsor bug fixes?
Of
This is kind of off-topic but on one of our deployments this crash is now
consistently deadlocking squid whenever it occurs rather than just ending the
process. Meaning that is can’t be restarted by any means except kill -9, which
obviously a huge disruption to hundreds of clients and
On 20/02/2015 5:46 p.m., Eliezer Croitoru wrote:
Hey Dan,
The basic rule of thumb in programming lands is script vs compiled code.
Where compiled code can be considered very reliable and in most cases
tested much more then scripts.
I am fearing that there is some race between all sorts of
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
Hey Dan,
The basic rule of thumb in programming lands is script vs compiled code.
Where compiled code can be considered very reliable and in most cases
tested much more then scripts.
I am fearing that there is some race between all sorts of things on
runtime which might lead to this failed
On 20/02/2015 7:15 p.m., Dan Charlesworth wrote:
Thanks Amos -
So then it more than likely is related to our external ACLs that deal with
the HTTP response?
I think they may be making the issue more noticable by slowing down the
request processing. But Squid should not be getting into
Thanks Amos -
So then it more than likely is related to our external ACLs that deal with the
HTTP response?
On 20 Feb 2015, at 5:06 pm, Amos Jeffries squ...@treenet.co.nz wrote:
On 20/02/2015 5:46 p.m., Eliezer Croitoru wrote:
Hey Dan,
The basic rule of thumb in programming lands is
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
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
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
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/92cf0b04afbd7917
https://gist.github.com/djch/92cf0b04afbd7917
Let me know if there’s any
Hi Eliezer
Thanks for paying attention, as always. I’m working on getting an
(appropriately censored) example of our squid.conf up for your perusal.
In the mean time I just wanted to point out that when this crash occurs some of
the most busy external_acl_types appear to crash too. Though the
Bumping this one for the new year 'cause I still don't understand squid
traces and because it's still happening with v3.4.11.
I would speculate that's it's something to do with the External ACLs
(there's a bunch). Let me know if a more recent traceback (than those
earlier in the thread) would
Hey Dan,
Just to get around the environment, can you share your
squid.conf?(censuring confidential data)
Thanks,
Eliezer
On 02/02/2015 01:14, Dan Charlesworth wrote:
Bumping this one for the new year 'cause I still don't understand squid
traces and because it's still happening with v3.4.11.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/11/2014 12:25 p.m., dan wrote:
Bumping this with another backtrace. Happened at 16:05 this time,
when the system was not very very busy.
It’s causing squid to crash in such a way that I actually have to
`kill -9` the process in order to get
Oh sure, sorry:
Squid Cache: Version 3.4.8
configure options: '--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu'
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin'
'--sbindir=/usr/sbin' '--sysconfdir=/etc'
26 matches
Mail list logo
