When installing Oracle 11gR2 Grid Infrastructure either the cluster verify utility or the prerequisite checks find that the NTP daemon does not have the slewing option set.
- PRVF-5439 : NTP daemon does not slewing option "-x" set on node "ordrac1" - Cause: NTP daemon on the specified node does not have the slewing option set - Action: Shutdown and restart the NTP daemon with the slewing option set. For more information on the NTP daemon slewing option refer the NTP daemon's man pages.
What is slewing?
The NTP daemon will periodically update the system clock with the time from a reference clock. If the time on the reference clock is behind the time on the system clock, the system clock will be set backwards in one large decrement. Such swift changes in time can lead to Oracle shutting down the node due to inconsistent timers. To avoid this problem, NTP can be configured to slew the clock. When slewing the clock the time on system is incremented slower until the system clock is in sync with the time on the reference system.
How to set up slewing
Stop the NTP service on the node.
[root@odrac1 ~]# service ntpd stop Shutting down ntpd: [ OK ] [root@odrac1 ~]# [/text/] Edit the file <code>/etc/sysconfig/ntpd</code> # Drop root to id 'ntp:ntp' by default. OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid" # Set to 'yes' to sync hw clock after successful ntpdate SYNC_HWCLOCK=no # Additional options for ntpdate NTPDATE_OPTIONS=""
Change the line
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid"
to
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"
After saving the file restart the NTP service. Re-execute the cluster verify utility or the prerequisite checks.
Hi,
thank you for the explanation WHY this is used.
On the downside, I had several incidents over the last 2 years where RAC systems get totally out of sync using this ‘-x’ option due to the fact that the internal hardware clocks run faster than the correction factor introduced in ‘-x’. So I ended up with not-in-sync- clocks while using ntp. That’s kind of weird, right?
What we did to fix this was resetting time manually via ntpdate which is – according to your post – not a good idea due to some timing problem inside the grid clusterware. Until now, we didn’t encounter any problems using this approach, yet had more problems with the slewing parameter.
Anyone experiencing similar problems?
Best,
Andreas
Hi, thanks very much for the explanation.
I had same issue with my installation and your solution worked.
yes we ran into the same problem. with slewing turned on it can take up to 14 days to correct the time. we also tried with a drift file this didn’t help. only removing the the slewing option solved the issue. i have included the -x option from ntpd manual
-x Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped
if above the threshold. This option sets the threshold to 600 s, which is well within the accuracy window to set the
clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment
requires an amortization interval of 2000 s. Thus, an adjustment as much as 600 s will take almost 14 days to com-
plete. This option can be used with the -g and -q options. See the tinker command for other options. Note: The ker-
nel time discipline is disabled with this option.