Use of pool servers reveals unacceptable crash rate in async DNS

Eric S. Raymond esr at
Tue Jun 28 23:26:39 UTC 2016

Hal Murray <hmurray at>:
> 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.

(You should camp on #ntpsec.  Also join our Signal channel - because that's
secured, most of the vuln discussions happen there.)

> I'd be a lot happier if you had a plan for what to do if it turned out to be 
> a problem and/or a way to verify that we don't need it or detect that it 
> causes trouble.

I have a plan.  Love is the plan, the plan is git (classical reference).
The two patches that removed it are pretty well isolated and should be
easily revertible.  As in, the work of minutes.

As for how to tell if it causes problems, that's not very difficult either.
If it's suspected, graph jitter against memory utilization.

> Consider ntpd running on an old system that is mostly lightly loaded and 
> doesn't have a lot of memory.  I could easily imagine ntpd getting swapped 
> out when some load did come along.  I don't know how to evaluate if that will 
> cause problems and I don't think we have a test environment that is likely to 
> blunder into it.

I remember page faults causing enough processing lag to be a real issue here,
but not since the mid-1990s at the latest.  And certainly not with SSDs.

But I think you've brought another issue to the surface which I'll start a
separate thread about.

> I poked around a bit.  Linux and NetBSD and FreeBSD all have getrusage().  I 
> didn't notice any differences.  It covers page faults and CPU usage.  When 
> I'm in the right mood, I'll add another file parallel to sysstats to collect 
> that sort of data.  The CPU usage will probably be interesting even if page 
> faults are boring.

That kind of data is always useful and I would welcome it.
		<a href="">Eric S. Raymond</a>

More information about the devel mailing list