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>