2

I have a RHEL6 server running an Oracle database. When the server was built, NTP wasn't enabled or configured. My task is to do that without impacting the database. After doing some research, I was under the assumption that, when enabling NTP on RHEL6, the time would drift until it was in sync. However, when I did this on my test machine, the system clocked immediately jumped to the NTP time. The time was approximately 2 1/2 minutes off before enabling NTP. When I ran the ntpstat command, it was unsynchronized for a little while but is now in sync.

So, how do I enable NTP and have it drift into the correct time instead of "brute-forcing" it into sync? Thanks for your help!!

[root@host etc]# service ntpd status
ntpd is stopped
[root@host etc]#
[root@host etc]# ntpdate -q time.mydomain.com
server 1.1.1.1, stratum 2, offset 154.573234, delay 0.02890
 2 May 15:47:59 ntpdate[21584]: step time server 1.1.1.1 offset 154.573234 sec
[root@host etc]#
[root@host etc]# service ntpd start
Starting ntpd:                                             [  OK  ]
[root@host etc]# ntpdate -q time.mydomain.com
server 1.1.1.1, stratum 2, offset -0.000118, delay 0.02876 
 2 May 15:50:47 ntpdate[21606]: adjust time server 1.1.1.1 offset -0.000118 sec
[root@host etc]# date
Tue May  2 15:51:01 EDT 2017
[root@host etc]# ntpstat
unsynchronised
polling server every 64 s
[root@host etc]# ntpstat
synchronised to NTP server (1.1.1.1) at stratum 3
 time correct to within 80 ms
 polling server every 1024 s

1 Answer 1

2

NTPD can adjust your clock in slow increments if it's off, clock slewing. The idea behind that is that slow steps won't cause issues with software timers, strange gaps in log files and your data etc.

The maximum slew rate possible is limited to 500 parts-per-million (PPM) by the Unix kernel. As a result, the clock can take 2000s for each second the clock is outside the acceptable range.

According to the manual page ntpd won't work if your clock is more then 1000 seconds off. (Although you can tune that with the -g switch slowly compensating a 1000 second offset will already take more than 3 weeks.)

Second the time jump you observed when you started ntpd is the result of the default ntpd behaviour to step rather than slew the clock when the offset is greater than 128 ms when ntpd starts up. That makes sense when ntpd is started at boot but not quite what you want on a running system.

You can prevent that by adding the -x switch to the start-up options for ntpd. From the 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 complete. This option can be used with the -g and -q options

In RHEL systems that would be adjusted the in /etc/sysconfig/ntpd config file before starting the ntpd service:

# /etc/sysconfig/ntpd
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -g -x" 
1
  • I appreciate the quick and useful feedback. Even after reading the man page, I guess I didn't quite understand what ntp was doing by default. I'll play with these options and test again. Thanks very much!!
    – bzinger
    May 3, 2017 at 13:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .