Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Nov 2017 15:36:22 -0700
From:      Ian Lepore <ian@freebsd.org>
To:        Warner Losh <imp@bsdimp.com>, "Rodney W. Grimes" <rgrimes@freebsd.org>
Cc:        Emmanuel Vadot <manu@bidouilliste.com>, Allan Jude <allanjude@freebsd.org>, "Conrad E. Meyer" <cem@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>
Subject:   Re: svn commit: r326095 - head/usr.sbin/bsdinstall/scripts
Message-ID:  <1511562982.1349.8.camel@freebsd.org>
In-Reply-To: <CANCZdfpS1bQRM8ZasrQ0LpuFn8z7x8U_Dp2BFAcefeR0GBN4cw@mail.gmail.com>
References:  <cae9ed597d249af3fc89b206c19cfd65@megadrive.org> <201711242114.vAOLE4b6097164@pdx.rh.CN85.dnsmgr.net> <CANCZdfpS1bQRM8ZasrQ0LpuFn8z7x8U_Dp2BFAcefeR0GBN4cw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2017-11-24 at 14:57 -0700, Warner Losh wrote:
> On Fri, Nov 24, 2017 at 2:14 PM, Rodney W. Grimes <
> freebsd@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > 
> > 
> > > 
> > > > 
> > > > We are not talking about removing ntpdate in this thread.
> > >   Well, after Ian said that it was deprecated I ask if we should remove
> > > it to be honest.
> > And I think we have come to the agreement not to do that until the
> > official distribution does it as well, is that also correct?
> > 
> I think we should do whatever Ian suggests. I did time things with atomic
> clocks and ntpd for about 8 years. He's done them for the same company I
> have and knows the current set of quirks better than anybody else in this
> thread. These days, it's generally better to use the freebsd ntp pool, like
> we have in ntp.conf, and in that scenario, an invocation of ntpd with the
> appropriate flags can give you almost identical behavior to ntpdate. The
> 'almost' here has a lot of quibbles that aren't relevant to the installer.
> And if you don't like the freebsd ntpd pool, then the installer should be
> writing an appropriate ntpd.conf file anyway, which has the host. It can
> all be done w/o using ntpdate (note: I didn't say remove it), and once
> that's in place, and we know there's something not unforeseen, we'll be
> ready if the ntpd folks ever make good on their threat to kill ntpdate. So
> remove the use of ntpdate here, but keep the utility around.
> 
> tl;dr: Do what ever Ian says, if he doesn't do it himself. He's the expert
> with a decade of daily experience making products with ntpd work and
> shipping those to customers that have... somewhat diverse environments...
> 
> Warner

And yet, even with all that experience, I still neglected to consider
the case where ntpd_sync_on_start=YES can cause a time-step on a
running system if ntpd is restarted.  (Not that that's a common
scenario, but it's still a Bad Thing for people with strict auditing
requirements or timing-critical software running.)

What the ntpd developers currently say[1] is:

    The combination of ntpd and sntp now implements the functions of
    ntpdate. As soon as a few remaining issues with sntp are resolved
    the ntpdate program will be retired.

If you look at what they link to for the "sntp issues"[2] it hasn't
been updated since 2011.  So that leads me to the conclusions:

 - They have not yet provided a complete path away from ntpdate.
 - They don't seem to be in a big hurry to eliminate ntpdate.

All in all, I think what Manu committed is Good Enough For Now(tm).

[1] https://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
[2] https://support.ntp.org/bin/view/Dev/SntpIssues

-- Ian




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1511562982.1349.8.camel>