[SOLVED] ntpd is kind of working but time constantly moves ahead

kevin_j_morse · 10-22-2015, 09:41 PM

Hi there,

I have a CentOS 5.7 VM running on a Hyper-V server. The integration tools are installed and the VM is running fine with the exception of the time.

hwclock always returns the correct time but date does not. Depending on how long I leave it for I have seen it get 7 hours ahead of the real time and ahead of hwclock.

In my research I have found that the tinker panic 0 setting should be used when running ntpd on VMs. I have also disabled the local clock as a source.

My ntp.conf is the following

Code:

tinker panic 0

restrict default limited kod nomodify notrap nopeer noquery

restrict 127.0.0.1

server 0.cr.pool.ntp.org
server 3.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org

logfile /var/log/ntp.log

driftfile /var/lib/ntp/drift

keys /etc/ntp/keys

My ntp/step-tickers is as follows

Code:

server 0.cr.pool.ntp.org
server 3.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org

and the drift file is 0.000

When I run ntpdate with no options I get a message

Code:

22 Oct 20:32:51 ntpdate[31017]: no servers can be used, exiting

but when I run it with one of the pool servers it works

Code:

ntpdate 3.north-america.pool.ntp.org
22 Oct 20:34:08 ntpdate[31077]: step time server 129.250.35.250 offset -7.941339 sec

ntpd appears to start fine but I don't know why ntpdate always has the same can't find host server message

Code:

Oct 22 20:35:05 localhost ntpdate[31350]: can't find host server
Oct 22 20:35:05 localhost last message repeated 2 times
Oct 22 20:35:07 localhost ntpdate[31350]: step time server 200.59.16.50 offset -1.483682 sec
Oct 22 20:35:07 localhost kernel: dahdi: Detected time shift.
Oct 22 20:35:07 localhost ntpd[31354]: ntpd 4.2.2p1@1.1570-o Sat Dec 20 02:52:11 UTC 2014 (1)
Oct 22 20:35:07 localhost ntpd[31355]: precision = 1.000 usec
Oct 22 20:35:07 localhost ntpd[31355]: Listening on interface wildcard, 0.0.0.0#123 Disabled
Oct 22 20:35:07 localhost ntpd[31355]: Listening on interface lo, 127.0.0.1#123 Enabled
Oct 22 20:35:07 localhost ntpd[31355]: Listening on interface seth0, 10.10.20.200#123 Enabled
Oct 22 20:35:07 localhost ntpd[31355]: Listening on interface seth1, 10.10.10.60#123 Enabled
Oct 22 20:35:07 localhost ntpd[31355]: Listening on interface seth2, 190.7.216.72#123 Enabled
Oct 22 20:35:07 localhost ntpd[31355]: kernel time sync status 0040

When ntpd has been running for a while I query it and get the following

Code:

[root@localhost plugins]# ntpstat
unsynchronised
  time server re-starting
   polling server every 64 s
[root@localhost plugins]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 barva.crisp.cr  200.59.16.50     2 u   21   64    7  116.230  -1813.2 1640.14
 x.ns.gin.ntt.ne 236.42.142.144   2 u   19   64    7   51.159  -3449.2 2616.14
 209.118.204.201 128.9.176.30     2 u   18   64    7  126.849  -3480.0 2614.83

so it seems like it isn't actually working properly.

I've spent several hours researching this and trying everything I can think of but I'm out of ideas. Any help would be greatly appreciated.

Thanks,

Kevin

TB0ne · 10-23-2015, 12:54 PM

Quote:

Originally Posted by kevin_j_morse

Hi there,
I have a CentOS 5.7 VM running on a Hyper-V server. The integration tools are installed and the VM is running fine with the exception of the time. hwclock always returns the correct time but date does not. Depending on how long I leave it for I have seen it get 7 hours ahead of the real time and ahead of hwclock.

In my research I have found that the tinker panic 0 setting should be used when running ntpd on VMs. I have also disabled the local clock as a source. My ntp.conf is the following

When ntpd has been running for a while I query it and get the following so it seems like it isn't actually working properly. I've spent several hours researching this and trying everything I can think of but I'm out of ideas. Any help would be greatly appreciated.

There was a known bug/issue with RHEL5 in a virtual environment, which caused this. Patches had to be applied to both the hypervisor and to the RHEL5 system to correct it. I realize you're using CentOS5, but chances are the bug applies. It's covered in the Red Hat knowledgebase, but you need to be a subscriber to view it.

I don't know what patch level you're on now, but are you up to date? Your hypervisor? And CentOS 5.7 is fairly old...consider loading the latest 7.x. You can *TRY* adding:

Code:

clock=pmtmr divider=10

..to your kernel boot line in GRUB, and see if it helps. That was a suggested fix with VMware, and may also work in your situation. Honestly, we wound up having to low-tech a solution, by shoving something in CRON to run every 30 minutes to do an ntpdate command, and adjust the time that way. NTP just didn't work well in that particular situation. 'Real' servers never seem to have that issue.

kevin_j_morse · 10-23-2015, 01:30 PM

Code:

[root@localhost plugins]# uname -r
2.6.18-238.12.1.el5

Code:

[root@localhost plugins]# cat /etc/redhat-release
CentOS release 5.7 (Final)

The hypervisor is Server 2012 which I realize is also a little older. This particular appliance was a physical server for most of it's lifetime but was virtualized so the physical server could be retired. Like you mention, the physical server had no ntp issues.

Is https://access.redhat.com/solutions/66777 the known issue that you are referring to? As you could probably guess by the fact that I'm using CentOS, I am not a RHEL subscriber.

kevin_j_morse · 10-24-2015, 02:22 AM

I ended up just adding an hourly ntpdate and it seems to be working fine. Not as elegant of a solution as I hoped but I won't be using CentOS 5 in the future.

TB0ne · 10-25-2015, 09:58 AM

Quote:

Originally Posted by kevin_j_morse

Code:

[root@localhost plugins]# uname -r
2.6.18-238.12.1.el5

Code:

[root@localhost plugins]# cat /etc/redhat-release
CentOS release 5.7 (Final)

The hypervisor is Server 2012 which I realize is also a little older. This particular appliance was a physical server for most of it's lifetime but was virtualized so the physical server could be retired. Like you mention, the physical server had no ntp issues.

Is https://access.redhat.com/solutions/66777 the known issue that you are referring to? As you could probably guess by the fact that I'm using CentOS, I am not a RHEL subscriber.

Yes, that's why I acknowledged that in my first reply. However, since CentOS is a clone of RHEL, the issue applies.

Quote:

I ended up just adding an hourly ntpdate and it seems to be working fine. Not as elegant of a solution as I hoped but I won't be using CentOS 5 in the future.

Yeah, that's the only thing we could do too. Updating the system seemed to correct that issue, as well as several others.