<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 1, 2016 at 1:53 PM, 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">On 31/05/2016 9:56 p.m., Tomas Mozes wrote:<br>
<span class="">> 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 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(addrinfo*&, int)<br>
>>> const: Assertion `false' failed.<br>
>>> 2016/05/14 21:55:25 kid1| Bad opcode: 112 from<br>
>>> [6661:6c73:6522:2061:7420: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: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>
</span>Squid is not crashing. The pinger is. Squid continues with degraded<br>
service latency.<br></blockquote><div><br></div><div>Yes, sorry, I wasn't specific. I meant like some part of Squid, not the Squid caching process itself.<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div><br></div><div>In the worst case - wouldn't it be possible for the master process to restart it?<br></div><div><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>You know, the strange thing is I only found those strings on google attached with Squid. No other place. If it's a general issue in the Linux kernel, then it's been there for years, unnoticed. And as I mentioned before, it happened on two machines, separate from each other, in completely different data-centers with the same error message.<br></div><div><br></div><div>What would you suggest?<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Amos<br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</div></div></blockquote></div><br></div></div>