I am using ntpd service to sync our RHEL 5.9 system to synch with GPS clock.
When I change the RHEL system time more than 7 seconds than the present system time (through "Datetime" command), ntpd service does not adjust the system time to the present GPS time.But if the time is with in 7 seconds, the system time is correctly adjusted after we change the system time manually by "datetime" command.
7 second is specified in our drift file. Once I restarts the ntpd service manually, the time is again adjusted with the present GPS time. I have read many article in google and my understanding from the articles are as follows.
The ntpd service adjusts the drift (drift is specified in drift file).It assumes that systeem clock should be always synched with the GPS clock (reliable time source) unless and until ntpd
malfunctions. Can any one tell how ntpd works in comparison with W32tm service in window system?
Do you have "ntpdate peers" in /etc/ntp/step-tickers?
Is your system a virtual host (which one)?
Please give output of
ps -eo args | grep '[n]tpd'
Q1:Do you have ntpdate peers in /etc/ntp/step-tickers ?
Ans: Yes.The name of GPS Clock device is mentioned their.
Q2: Is your system a virtual host (which one)?
Ans: Do you mean to Say whether it is a virtual machine or not?
Is so then, we are having mix setup. The machine from where I am giving you the command output of Q3 is a Virtual Machine hosted in VM (VMWare Esxi 6.0.0)
and there are other machines (RHEL 5.9 basesd) whish are not VM are also having the same observations asked in the questions.
Q3: Please give output of:
ps -eo args | grep '[n]tpd'
Ans:
ntpd -u ntp:ntp -p /var/run/ntpd.pid
If your problem is only with the virtual machines (VMware guests),
then you need to look into the VMware hosts. Do they have the correct time, are they running ntp?
Then, they might provide different modes for the guest's HW clock. A VMware expert might know more. But should not matter if the HW clock is correct.
No.The same problem persist for the RHEL 5.9 machines that are non VM.
If you have the NTP configuration correct, then I would use ntpdate timeserver to get the clock to jump to the correct time. Remember that this will set the system clock to CUT/UTC/GMT/ZULU and it is the timezone that changes the displayed date. You may be changing the date to what looks correct, but it is too far out for NTP to then follow the external source. NTP always follows the zero timezone.
Does this help?
Robin
That's what it does with the servers in /etc/ntp/step-tickers
You do not need a driftfile.
If your driftfile makes problems, check if it has got the right permissions ntp:ntp
For example the pathname is /var/lib/ntp/ntp.drift
ls -ld /var/lib/ntp/ntp.drift /var/lib/ntp
drwxr-xr-x 2 ntp ntp date /var/lib/ntp
-rw-r--r-- 1 ntp ntp date /var/lib/ntp/ntp.drift
And initially this file should be empty, so the then started ntpd will write it after some hours according to its measurement.
A good debug command for the ntpd is
ntpq -p
or
ntpq -np
1 Like