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