From owner-freebsd-current@freebsd.org Sat Mar 18 03:52:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D7F2D10758 for ; Sat, 18 Mar 2017 03:52:28 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (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 1F0E31C9D; Sat, 18 Mar 2017 03:52:27 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id p5PecLh46cWiHp5Pfcexzh; Fri, 17 Mar 2017 21:52:20 -0600 X-Authority-Analysis: v=2.2 cv=JLBLi4Cb c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=8nJEP1OIZ-IA:10 a=6Iz7jQTuP9IA:10 a=6I5d2MoRAAAA:8 a=85N1-lAfAAAA:8 a=YxBL1-UpAAAA:8 a=lIQFjzKYggohrT3dAzkA:9 a=uv2THEdqtlk0MrbB:21 a=2JB-jUObIajtU_Ea:21 a=wPNLvfGTeEIA:10 a=IjZwj45LgO3ly-622nXo:22 a=cyfSibbquD4hpIoiQNSb:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 107707F2; Fri, 17 Mar 2017 20:52:18 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v2I3qC1W090879; Fri, 17 Mar 2017 20:52:12 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201703180352.v2I3qC1W090879@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Ian Lepore cc: Don Lewis , ohartmann@walstatt.org, Cy.Schubert@komquats.com, freebsd-current@freebsd.org Subject: Re: ntpd dies nightly on a server with jails In-Reply-To: Message from Ian Lepore of "Fri, 17 Mar 2017 14:33:13 -0600." <1489782793.40576.185.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 17 Mar 2017 20:52:12 -0700 X-CMAE-Envelope: MS4wfBzripGNpLAR+JYXCcjeYW3mao5Dso8Vi/1wSQOxFRX4hZAJZXdwwmeJnjlB4XAoVdYiUfSU3oE91nosmKl6HCYb7HMtRKf1US8Z5Z9B8Svvp58dLZxG JzTBLa/c4wyr05N/t/9CHXNT3wm03UBT/G7vQP02xSNVNdgEy7SuOJQHCnx0CvKtfzHlraD6rAHezRfRxxBR0iggVoZ5oC3fRww+VXozX5zweo6HnZqxVwPH Tafflfg6Wju6fTuCKvHmK8M/0t1PhwL1dqVoOjttK4A= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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: Sat, 18 Mar 2017 03:52:28 -0000 In message <1489782793.40576.185.camel@freebsd.org>, Ian Lepore writes: > On Fri, 2017-03-17 at 13:26 -0700, Don Lewis wrote: > > On 17 Mar, O. Hartmann wrote: > > > > > > > > Just some strange news: > > > > > > I left the server the whole day with ntpd disabled and I didn't > > > watch > > > a gain of the RTC by one second, even stressing the machine. > > > > > > But soon after restarting ntpd, I realised immediately a 30 minutes > > > off! This morning, the discrapancy was almost 5 hours - it looked > > > more > > > like a weird ajustment to another time base than UTC. > > > > > > Over the weekend I'll leave the server with ntpd disabled and only > > > RTC > > > running. I've the strange feeling that something is intentionally > > > readjusting the ntpd time due to a misconfiguration or a rogue ntp > > > server in the X.CC.pool.ntp.org > > A ntp should recognize a single bad server and ignore it in favor of  > > the other servers that are sane. > > > > It sounds like something is going off the rails once ntpd starts > > calling > > adjtime().  What is the output of: > > sysctl kern.clockrate > > > > I'd suggest starting ntpd and running "ntpq -c pe" a few times a > > minute > > and capturing its output to monitor the status of ntpd as it starts > > up > > and try to capture things going wrong.   You should probably disable > > iburst in ntp.conf to give more visibility in the early startup. > > > > For the first few minutes ntpd should just be getting reliable > > timestamp > > info and won't start trying to adjust the clock until it has captured > > endough samples and figured out which servers are best.  Then the > > behaviour of the offset is the thing to watch.  If the iniital offset > > is > > large enough, ntpd will step the clock once to get it close to zero, > > otherwise it will just use adjtime to slowy push the offset towards > > zero.  I think though that you will see the offset start gyrating > > madly. > > > > You might want to set /var/db/ntpd.drift to zero beforehand if there > > is > > an insane value in there.  If the initial drift value is bogus, will > > try > > to use it which will push the time offset away from zero so fast that > > it > > will decide to keep stepping the clock back to zero before it can > > capture enough samples from the external servers to determine the > > true > > local clock drift rate. > > Do not set ntpd.drift contents to zero.  Delete the file.  There's a > huge difference between a file that says the clock is perfect and a > missing file which triggers ntpd to do a 15-minute frequency > measurement to come up with the initial drift correction. Yes. And, without debugging output and/or a dump, I don't think we'll be any closer to the truth. Until then the best we can do is make educated guesses. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.