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 protected]> 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
