<span id="mailbox-conversation">By the way, I think Eliezer suggested I should file a bug report. There is in fact one already filed here:<div>
<div id="mb-reply">http://bugs.squid-cache.org/show_bug.cgi?id=3930</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">Which brings me to my next question ...</div>
</div>
<div>Amos, is it possible to sponsor bug fixes?</div></span><div class="mailbox_signature">
<br> </div>
<br><br><div class="gmail_quote"><p>On Tue, Feb 24, 2015 at 2:47 PM, dan@getbusi.com <span dir="ltr"><<a href="mailto:dan@getbusi.com" target="_blank">dan@getbusi.com</a>></span> wrote:<br></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>
<span id="mailbox-conversation"><div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>I have a very similar deployment where this still crashes “cleanly”.</div>
<div><br></div>
<div>Both on CentOS 6.6 and Squid 3.4.12.</div>
<div><br></div>
<div>Anyone have a clue what might cause this “deadlocking” type behaviour after an “assertion failed" crash?</div>
<div><br></div>
<div><br></div>
<div><br></div></span><div class="mailbox_signature">
<br> </div>
<br><br><div class="gmail_quote">
<p>On Fri, Feb 20, 2015 at 5:23 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>></span> wrote:<br></p>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p>On 20/02/2015 7:15 p.m., Dan Charlesworth wrote:
<br>> Thanks Amos -
<br>>
<br>> So then it more than likely is related to our external ACLs that deal with the HTTP response?
<br>>
<br><br>I think they may be making the issue more noticable by slowing down the
<br>request processing. But Squid should not be getting into that state
<br>either way.
<br><br>Amos
<br><br></p></blockquote>
</div>
<br></div></blockquote></div><br>