[ntp:hackers] Linux and rlimit memlock

Harlan Stenn stenn at ntp.org
Wed Apr 29 09:57:25 UTC 2015

Hal Murray writes:
> > We've been fielding bug reports about glibc and rlimit memlock for a while
> > now.  We haven't gotten any closer to finding a useful solution to this.
> Do you have a collection of bug numbers with interesting ideas?

Not handy, and I'm getting tired tonight.

But searching the bugs for 'memlock' suggests bugs 2362, 2471, 2489,
2643, and  2779.

There may be others, too.  Some of these other bugs have probably been

> Is it associated with any particular distro or kernel version?  Were
> there any interesting kernel changes in this area recently?  Or malloc
> in libc?

I have no idea.  We think it's a libc thing, most likely.

> Did the reports start with the release of 4.3?  if so, how much did
> ntpd's memory usage change?

The number started out much bigger and we got a lot of complaints from
embedded folks saying our defaults were way too high, and it looked like
32M was *plenty* for everybody.  Except *some* linux/glibc boxes.

> Is the mrulist tangled up with this problem?

I doubt it, but I'm not certain.

> What other ideas have you already eliminated?  :)

Mostly that I, as one who cannot routinely duplicate this, will be able
to divine the correct answer.  What works for some (48M) does not work
for others, who need various numbers from 64-128M.  Except for everybody
else, for whom 32M is plenty.


More information about the hackers mailing list