Use of pool servers reveals unacceptable crash rate in async DNS

[Matthew Selsky]

On Tue, Jun 28, 2016 at 07:26:39PM -0400, Eric S. Raymond wrote:
> Hal Murray <hmurray at megapathdsl.net>:
> > I think you have extrapolated from some modern systems to our whole target 
> > environment.  I don't remember any discussion supporting memlock not being 
> > interesting/important.
> 
> There were actually two threads about this attached to memlock-related bug
> reports in Classic.  They initially thought memlocking was important, then
> figured out it wasn't.  Matt Selsky has been following those bugs; he and I
> discussed the issue on #ntpsec.

"rlimit memlock 0" using Classic causes ntpd to died after 3 minutes with this error
2016-06-29T00:13:21.903+00:00 host.example.com ntpd[27206]: libgcc_s.so.1 must be installed for pthread_cancel to work

I've attached 15 minute graphs for "rlimit memlock -1" and "rlimit memlock 128" using Classic.  Locking memory seems to result in more stable graphs over the time period that I was able to collect quickly.


Cheers,
-Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memlock128.PNG
Type: image/png
Size: 18518 bytes
Desc: not available
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160628/6e1d2136/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memlock-1.PNG
Type: image/png
Size: 36531 bytes
Desc: not available
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160628/6e1d2136/attachment-0001.png>