<div dir="ltr">After enabling IPv6 in the kernel, building squid with IPv6 and firewalling IPv6 no crash was observed any more. <br><br>Thanks for the tip Amos.<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 11, 2016 at 7:14 AM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 3/06/2016 3:47 a.m., Tomas Mozes wrote:<br>
> On Wed, Jun 1, 2016 at 1:53 PM, Amos Jeffries <<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>> wrote:<br>
><br>
>> On 31/05/2016 9:56 p.m., Tomas Mozes wrote:<br>
>>> On Thu, May 26, 2016 at 8:04 AM, Amos Jeffries wrote:<br>
>>><br>
>>>> On 24/05/2016 7:52 p.m., Tomas Mozes wrote:<br>
>>>>> Hello,<br>
>>>>> on two different squid servers I've observed a crash of pinger. First<br>
>> it<br>
>>>>> appeared on version 3.5.15 and later on version 3.5.17.<br>
>>>>><br>
>>>>> Cache.log contains these lines:<br>
>>>>><br>
>>>>> (pinger): Address.cc:671: void Ip::Address::getAddrInfo(<wbr>addrinfo*&,<br>
>> int)<br>
>>>>> const: Assertion `false' failed.<br>
>>>>> 2016/05/14 21:55:25 kid1| Bad opcode: 112 from<br>
>>>>> [6661:6c73:6522:2061:7420:<wbr>6c69:6e65:2036]<br>
>>>>> 2016/05/14 21:59:13 kid1| recv: (111) Connection refused<br>
>>>>> 2016/05/14 21:59:13 kid1| Closing Pinger socket on FD 17<br>
>>>>><br>
>>>>> On both servers, that IPv6 address was the same -<br>
>>>>> 6661:6c73:6522:2061:7420:6c69:<wbr>6e65:2036<br>
>>>>><br>
>>>><br>
>>>> That is the hexadecimal representation of the error:<br>
>>>>  false" at line 6<br>
>>>><br>
>>>> Which means that your kernel is producing garbage when asked to resolve<br>
>>>> an IPv6 address or respond to an ICMPv6 packet.<br>
>>>><br>
>>><br>
>>> Cannot we prevent Squid from crashing in these cases?<br>
>>><br>
>><br>
>> Squid is not crashing. The pinger is. Squid continues with degraded<br>
>> service latency.<br>
>><br>
><br>
> Yes, sorry, I wasn't specific. I meant like some part of Squid, not the<br>
> Squid caching process itself.<br>
><br>
><br>
>> What kind of continued operations would you expect a program to do when<br>
>> it discovers at least some portion of its RAM has been filled with<br>
>> garbage by the system kernel?<br>
>><br>
><br>
><br>
> In the worst case - wouldn't it be possible for the master process to<br>
> restart it?<br>
><br>
<br>
</div></div>For most helpers that is exacty what happens, but with frequent enough<br>
failures killing Squid. That latter bit has been part of the problem<br>
preventing this one being the same so far.<br>
<br>
This paticular helper needs root permission to use ICMP sockets. It has<br>
a long history of being installed with wrong ownership and access<br>
permissions, which cause it to exit early. So the most common form of it<br>
dying is not a situation in which Squid can reasonably restart it - or<br>
risks almost certainly dying itself.<br>
<br>
Thesituation has been improving in recent years though. So I'm hopeful<br>
we will get there eventually. If you wish to sponsor some work to speed<br>
that up it could be made a configurable action.<br>
<span class=""><br>
<br>
><br>
>><br>
>> Now cross your fingers and pray that no other programs on your whole<br>
>> system (network, if you did the same "disable" on other machines) are<br>
>> behaving badly in secret when given the garbage by the kernel like<br>
>> Squid's pinger was.<br>
>><br>
><br>
> You know, the strange thing is I only found those strings on google<br>
> attached with Squid. No other place. If it's a general issue in the Linux<br>
> kernel, then it's been there for years, unnoticed. And as I mentioned<br>
> before, it happened on two machines, separate from each other, in<br>
> completely different data-centers with the same error message.<br>
><br>
> What would you suggest?<br>
><br>
<br>
</span>I suggest enabling IPv6 within your network. :-) It can be firewalled if<br>
you want it not to be used, same as any other digital service.<br>
<br>
That will also give you a way to measure whether you have reached<br>
tipping point of it being useful. The global traffic passed 12% last<br>
weekend and growth rate is somewhere between exponential and hyperbolic<br>
despite a lot of networks still clinging to IPv4.<br>
<span class="HOEnZb"><font color="#888888"><br>
Amos<br>
<br>
</font></span></blockquote></div><br></div></div></div>