From owner-freebsd-current@freebsd.org Mon Sep 9 18:22:52 2019 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A38D2DB174 for ; Mon, 9 Sep 2019 18:22:52 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46RxNW1lFtz4MYK for ; Mon, 9 Sep 2019 18:22:50 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x89IMkAt044809; Mon, 9 Sep 2019 11:22:46 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x89IMkdK044808; Mon, 9 Sep 2019 11:22:46 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201909091822.x89IMkdK044808@gndrsh.dnsmgr.net> Subject: Re: ntpd segfaults on start In-Reply-To: To: Ian Lepore Date: Mon, 9 Sep 2019 11:22:46 -0700 (PDT) CC: "Rodney W. Grimes" , Cy Schubert , Konstantin Belousov , Harlan Stenn , Vladimir Zakharov , freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 46RxNW1lFtz4MYK X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.93 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.64)[-0.636,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.04)[ip: (0.15), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.04), country: US(-0.05)]; NEURAL_SPAM_LONG(0.13)[0.125,0]; RCPT_COUNT_SEVEN(0.00)[7]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUSPICIOUS_RECIPS(1.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2019 18:22:52 -0000 > 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 All very reasonable, thanks Ian. -- Rod Grimes rgrimes@freebsd.org