[pkg-ntp-maintainers] Bug#802768: Bug#802768: Confusing NEWS.Debian entry

[Kurt Roeckx]

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 <kurt at roeckx.be>  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.


Kurt