Date: Mon, 09 Sep 2019 12:13:24 -0600 From: Ian Lepore <ian@freebsd.org> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, Konstantin Belousov <kostikbel@gmail.com>, Harlan Stenn <stenn@nwtime.org>, Vladimir Zakharov <zakharov.vv@gmail.com>, freebsd-current@freebsd.org Subject: Re: ntpd segfaults on start Message-ID: <ef8b67577e6512313261693cbbf40e24f007b6c4.camel@freebsd.org> In-Reply-To: <201909091630.x89GUjGX044288@gndrsh.dnsmgr.net> References: <201909091630.x89GUjGX044288@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote: > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote: > > > In message <20190907161749.GJ2559@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. > Does it have that effect? I don't know. But I would argue that that's a separate issue, and we should make that happen by adding ntpd_oomprotect=YES to /etc/defaults/rc.conf Right now only syslogd has oomprotect set to YES by default. Maybe that's a good choice -- once we start declaring one daemon to be more important than others, you'll discover there's a whole back lot full of bikesheds that need painting. So maybe we should just document ntpd_oomprotect=YES in some more- prominent way. If we were to add a comment block to ntp.conf describing rlimit, that might be a good place to mention setting ntpd_oomprotect in rc.conf. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ef8b67577e6512313261693cbbf40e24f007b6c4.camel>