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 incredibly frustrating
for the sysadmin.
Nothing has really changed in the configuration since this deadlocking started
happening but I’ve noticed when that there’s no longer anything in
/var/log/messages from abrtd etc. like there usually would be.
I have a very similar deployment where this still crashes “cleanly”.
Both on CentOS 6.6 and Squid 3.4.12.
Anyone have a clue what might cause this “deadlocking” type behaviour after an
“assertion failed" crash?
On Fri, Feb 20, 2015 at 5:23 PM, Amos Jeffries <squ...@treenet.co.nz>
wrote:
> 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 that state
> either way.
> Amos
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
