Re: ntpd segfaults on start

> 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 wants. 
> > > > 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.

Doesn't locking this memory down also protect ntpd from OOM kills?
If so that is a MUST preserve functionality, as IMHO killing ntpd
on a box that has it configured is a total no win situation.

Regards,
Rod

> 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.
> 
> I would propose that for freebsd, the autoconf-generated value for
> 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>.
> 
> -- Ian
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 

-- 
Rod Grimes                                                 rgrimes_at_freebsd.org