Re: ntpd segfaults on start

In message <66f80012757134b6317b673f9eeb24db66c996a2.camel_at_freebsd.org>, 
Ian Le
pore writes:
> On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote:
> > In message <20190907161749.GJ2559_at_kib.kiev.ua>, Konstantin Belousov writes:
> > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote:
> > > > I've been able to set the memlock rlimit as low as 20 MB. The issue is 
> > > > letting it default to 0 which allows ntp to mlockall() anything it want
> s. 
> > > > ntpd on my sandbox is currently using 18 MB.
> > > 
> > > Default stack size on amd64 is 512M, and default stack gap percentage is
> > > 3%. This means that the gap can be as large as ~17MB. If 3MB is enough
> > > for the stack of the main thread of ntpd, then fine.
> > 
> > The default stack is 200K, which is also tuneable in ntp.conf.
> > 
> > [...]
>
> I haven't seen anyone ask what I consider to be the crucial question
> yet:  why are we locking ntpd into memory by default at all?
>
> I have seen two rationales for ntpd using mlockall() and setrlimit(): 
>
>    - There are claims that it improves timing performance.
>
>    - Because ntpd is a daemon that can run for months at a time,
>    setting limits on memory and stack growth can help detect and
>    mitigate against memory leak problems in the daemon.
>
> I am *highly* skeptical of claims that locking ntpd in memory will
> improve timing performance on freebsd (to the point where I'm inclined
> to dismiss them out of hand, but I'd be willing to look at any actual
> evidence).
>
> The second point has at least some validity, but would be better
> implemented (IMO) by decoupling the address space limit from the act of
> locking down memory, and allowing configuration of RLIMIT_AS separately
> from RLIMIT_MEMLOCK.  If there's any interest in this, I could try to
> put together a patchset and submit it upstream for that.

Our upstream is already cc'd on this thread.

diff --git a/usr.sbin/ntp/config.h b/usr.sbin/ntp/config.h
index 56dbfedba6e..b26dd417885 100644
--- a/usr.sbin/ntp/config.h
+++ b/usr.sbin/ntp/config.h
_at__at_ -287,7 +287,7 _at__at_
 #define DEFAULT_HZ 100
 
 /* Default number of megabytes for RLIMIT_MEMLOCK */
-#define DFLT_RLIMIT_MEMLOCK 32
+#define DFLT_RLIMIT_MEMLOCK -1
 
 /* Default number of 4k pages for RLIMIT_STACK */
 #define DFLT_RLIMIT_STACK 50

But I'd wait for Harlan to weigh in on this. I agree with kib_at_ that this 
may introduce unwanted jitter. I'd also want to understand why this 
defaults to -1 for Linux only.

>
> I would propose that for freebsd, the autoconf-generated value for

For the port but in base we control this directly.

> DFLT_RLIMIT_MEMLOCK should be -1 to avoid calling setrlimit() and
> mlockall() by default.  Then in the ntp.conf we distribute we have a
> section like:
>
>    # To lock ntpd into memory, uncomment the following rlimit line.
>    # This should not be necessary on most systems, but may improve
>    # performance on heavily-loaded servers experiencing enough
>    # memory pressure to cause ntpd to be paged out.
>    # rlimit memlock <something> stacksize <something>
>
> Then we would need to come up with reasonable values for <something>.

I haven't had a chance to look at this in depth yet but I suspect that 
<something> isn't in fact 32 as specified in config.h. It behaves as if 
this is set to 0 to mlockall() all it asks for.

>
> -- Ian


-- 
Cheers,
Cy Schubert <Cy.Schubert_at_cschubert.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.