[blfs-dev] NTP

Matt Burgess matthew at linuxfromscratch.org
Thu Feb 16 14:27:06 PST 2012


On Thu, 2012-02-16 at 14:13 -0800, Qrux wrote:
> On Feb 16, 2012, at 4:38 AM, Matthew Burgess wrote:
> 
> > On Thu, 16 Feb 2012 11:16:12 +0000, Andrew Benton <b3nton at gmail.com> wrote:
> >> On Wed, 15 Feb 2012 18:47:37 -0800
> >> Qrux <qrux.qed at gmail.com> wrote:
> >> 
> >>> 	* So, I propose turning -x off.
> >> 
> >> I agree, I run ntpd -g
> >> However, I also think the ntpd bootscript will work fine for most
> >> people and for those (like me) who think it should be done differently
> >> it's trivial to edit the bootscript; your distro, your rules and all
> >> that ;)
> > 
> > It probably doesn't affect many LFSers, but Oracle's RAC installation/
> > configuration wizard explicitly checks for '-x' in the ntpd options.
> > 
> > It does this because you really don't want your database server's time
> > from jumping backwards, and '-x' (or 'tinker step 0' in /etc/ntp.conf)
> > is the only way to guarantee that won't happen.

> 
> In case anyone has forgotten, NTP gives slewing by default.  The question is not whether monotonically increasing time is good.  You get that with OR WITHOUT -x.  The issue is, -x doesn't guarantee anything.

Good, I'm glad you said that, because that was my understanding from
reading the man page as well, which made me wonder why Oracle demands
'-x'.  Sometimes though, in order to get past their 1st/2nd line
support, it's easier to just give in and do what they want rather than
what is technically correct :-)

> So, getting back to your RAC system...Sure, it can check for it.  But let's hope your database app doesn't stop operating when you can't find a timesource.

In the particular environment that I was directly involved in, our time
source was the RAC server's default gateway (or more accurately, the NTP
service running on the Cisco switch, which the RAC servers were directly
connected to).  If they lost their time source, we'd have much bigger
issues than their notion of what the correct time was :-)

Regards,

Matt.




More information about the blfs-dev mailing list