Re: Bug#802768: Confusing NEWS.Debian entry
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.)
> This is under the assumption that rlimit memlock is, indeed, an
> ntp.conf statement. I couldn't find any reference to that in the
> documentation, so it could be wrong.
I don't see it in the man pages or anywhere like that, but the HTML
docs in Sid's ntp-doc do have a section on "rlimit", and in particular
"rlimit memlock _Nmegabytes_":
Specify the number of megabytes of memory that should be
allocated and locked. Probably only available under Linux, this
option may be useful when dropping root (the -i option). The
default is 32 megabytes on non-Linux machines, and -1 under
Linux. -1 means "do not lock the process into memory". 0 means
"lock whatever memory the process wants into memory".
(Whereas the "official, definitive" version at
says that 0 = disabled.)
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.
> 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.
I haven't been able to find anything useful for this.
(Pointless moaning: "rlimit" strikes me as a rather esoteric name for
something that might as well just have been called "limit". It's not
the name of a glibc system call, or an esoteric POSIX function, let
alone anything even remotely user-visible - no, all those things have
different names; "rlimit" is just what the *struct* is called!)
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package