Re: [pkg-ntp-maintainers] Bug#802768: Confusing NEWS.Debian entry
On Fri, Oct 23, 2015 at 05:55:02PM +0100, Justin B Rye wrote:
> Wouter Verhelst wrote:
> > The NEWS.Debian entry for ntp 1:4.2.8p4+dfsg-2 reads as follows:
> > ntp (1:4.2.8p4+dfsg-2) unstable; urgency=medium
> > You now need to use "rlimit memlock -1" to disable locking memory. The
> > behaviour for ""rlimit memlock 0" changed between 4.2.8p3 and 4.2.8p4 and
> > it now tries to lock all the memory. But for various people this still
> > breaks things.
> > -- Kurt Roeckx <email@example.com> Thu, 22 Oct 2015 18:58:56 +0200
> > It took me several times to understand what this meant, and that it
> > didn't apply to me. I would suggest rephrasing this so it is easier to
> > understand. Suggestion:
> > The behaviour of the "rlimit memlock" statement in ntp.conf has
> > changed. Previously, setting the value of that option to 0 would
> > disable the locking of memory; its current behaviour is to lock all
> > the memory. To revert to its previous behaviour, use "rlimit memlock
> > -1". However, note that there are cases in which this may cause
> > problems; for more information, see <reference>
> (I would suggest avoiding "lock all the memory", which sounds as if it
> might mean "consume all my RAM". It's possible this should also
> mention that disabling memlock was and still is the default.)
As far as I know it was broken in 4.2.6 where it didn't result in
anything, which was "fixed" in 4.2.8 causing breakage. This is
why I added the "rlimit memlock 0" in the default ntp.conf before.
The documentation said that 0 disables locking. But now upstream
said that 0 was broken too, that the documentation was wrong, and
that they fixed it to mean unlimited. But looking at the code
it's actually setting a limit of 0 instead of RLIM_INFINITY, and
then calls mlockall(MCL_CURRENT|MCL_FUTURE)), which clearly
doesn't seem to be a good idea.
> So yes, the NEWS entry seems unnecessarily alarmist; *I* don't "need
> to use 'rlimit memlock -1' to disable locking memory". Not unless I
> had already explicitly set it to "rlimit memlock 0", anyway.
Yes, I didn't know at that time the default had changed.
> > If so, please clarify that, too.
> > Obviously that <reference> bit should be replaced by a link to a bug or
> > some bit of the documentation that explains the possible problems.
There is #793745 and #802638.