From owner-freebsd-current@freebsd.org Mon Sep 9 19:28:43 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 08429DCF66 for ; Mon, 9 Sep 2019 19:28:43 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46RyrV0BJqz4S8k; Mon, 9 Sep 2019 19:28:41 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 7PL2i1PpQIhW97PL3i2KAX; Mon, 09 Sep 2019 13:28:39 -0600 X-Authority-Analysis: v=2.3 cv=FcFJO626 c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=J70Eh1EUuV4A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=dGt7y4mFooTMp67Xen0A:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id E8A6AAC0; Mon, 9 Sep 2019 12:28:35 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x89JSZ23062485; Mon, 9 Sep 2019 12:28:35 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x89JSZMm062482; Mon, 9 Sep 2019 12:28:35 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201909091928.x89JSZMm062482@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Konstantin Belousov cc: Ian Lepore , "Rodney W. Grimes" , Cy Schubert , Harlan Stenn , Vladimir Zakharov , freebsd-current@freebsd.org Subject: Re: ntpd segfaults on start In-reply-to: <20190909184446.GU2559@kib.kiev.ua> References: <201909091630.x89GUjGX044288@gndrsh.dnsmgr.net> <20190909184446.GU2559@kib.kiev.ua> Comments: In-reply-to Konstantin Belousov message dated "Mon, 09 Sep 2019 21:44:46 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Sep 2019 12:28:35 -0700 X-CMAE-Envelope: MS4wfCNdLMMFu3T+xzAFxBXSvUKj0SzhkIIgldO5/QnxhzgxjV1wEHU17Yd6R+/KmL5Va0LZ3UcIP5BjQKQrofbyr2fZJiLiYiwEJaBkTpxZhzIUqBQS+Wqp LDmk5oNVllnFT3wYus0ZKaGHCramev9Qvdzu0dbLzYiBn0pyokfo5zBVnE20zs83lO4H3rTduhOMCkf9ZQSgcqKOTjZ9Tfn1iM64ZN1ymO/cuz6D9H2I2tr/ 2BAyflQHGM3LlnBS/VofA9mvzkv6GsLses6ss/RmcaquqNYRe5JGiE60mxVH+HCZ X-Rspamd-Queue-Id: 46RyrV0BJqz4S8k X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.138) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-2.42 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-2.32)[ip: (-6.06), ipnet: 64.59.128.0/20(-3.08), asn: 6327(-2.39), country: CA(-0.09)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[138.136.59.64.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; SUSPICIOUS_RECIPS(1.50)[] 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 19:28:43 -0000 In message <20190909184446.GU2559@kib.kiev.ua>, Konstantin Belousov writes: > On Mon, Sep 09, 2019 at 12:13:24PM -0600, Ian Lepore wrote: > > 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 > Wiring process memory has no effect on OOM selection. More, because > all potentially allocated pages are allocated for real after mlockall(), > the size of the vmspace, as accounted by OOM, is the largest possible > size from the whole lifetime. > > On the other hand, the code execution times are not predictable if the > process's pages can be paged out. Under severe load next instruction > might take several seconds or even minutes to start. It is quite unlike > the scheduler delays. That introduces a jitter in the local time > measurements and their usage as done in userspace. Wouldn't this affect > the accuracy ? IMO it would and would be unacceptable when used as a stratum N server or with some OLTP or database applications. Locking a few megabytes is a small cost. > > > > > 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 > > -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.