-   Linux - Server (
-   -   NTP - ntpdate works but does not update system clock (

Laedrus 02-20-2014 11:43 AM

NTP - ntpdate works but does not update system clock

That's pretty odd, first time I see it. I've seen ntpd not doing its job but never ntpdate not helping, this is how it looks like :


20 Feb 10:16:24 ntpdate[23877]: step time server offset -2770.341672 sec
[root@bugzilla ~]# ntpdate
20 Feb 10:16:24 ntpdate[23878]: step time server offset -2770.341754 sec
[root@bugzilla ~]# ntpdate
20 Feb 10:16:40 ntpdate[23881]: step time server offset -2770.345091 sec
[root@bugzilla ~]# ntpdate
20 Feb 10:16:43 ntpdate[23882]: step time server offset -2770.345357 sec
[root@bugzilla ~]# service ntpd status
ntpd is stopped
OBS: is the campus NTP server, disguised.

But as you see, not even the official CentOS servers help. It is something client side.

Has anyone seen this before?

Let me know if ntp.conf can give any clue, ommited it to not send a lot of junk to the thread at first.


custangro 02-20-2014 12:03 PM

The hardware clock maybe?

What does...


hwclock --show

Laedrus 02-20-2014 01:18 PM

Ah, a very important detail that I forgot to include : It's a Xen VM.

I also heard of Xen VMs clocks misbehaving before, but not like that and nothing that ntpd running wouldn't solve.

Thanks for the idea hwclock gave me an error :

[root@bugzilla ~]# hwclock --show
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.

As well as in other hardware machines I had. I decided to check in the host machine, and it also had a big skew. This time ntpdate worked as expected and ntpd running and active in chkconfig will keep things working in the long run.

Then as the VM would stay stuck in the same bad skew, I tried rebooting it to see if it would restore it to a decent state. It did, after reboot ntpd got the right date and ntpdate showed a small skew :

[root@bugzilla ~]# ntpdate
20 Feb 11:12:54 ntpdate[2474]: adjust time server offset -0.004173 sec

That solves my problem, it's a pity that I didn't manage to find the reason to share here for people with the same problem in the future. Bottom line is that solving the issue in the host and rebooting the VM helped.


michaelk 02-20-2014 01:27 PM

A VM does not have access to the hardware clock.

This might shed some light...

Laedrus 02-20-2014 04:25 PM

Thanks Michael, that is some helpful documentation to understand how it happened. Marking the thread as solved.

yo8rxp 02-21-2014 06:57 AM

Well ntp cannot update system clock at once if delay is too big ! ( one hour as i remember), set up date manually once and it will do the job.

michaelk 02-21-2014 07:08 AM

The maximum offset is actually 1024 seconds.

All times are GMT -5. The time now is 12:20 AM.