1

If have SLES 11 SP2 and this is the problem:

I have configured the NTP service and when I restart it then it is synchronizing correctly the time.

Then, suddenly after around 7-8 minutes the time changes. Here is a log of the date command displayed every 10 seconds:

Tue May 24 20:11:35 CEST 2016
Tue May 24 20:10:38 CEST 2016   <-- Restart of the NTP service
Tue May 24 20:10:48 CEST 2016
....
Tue May 24 20:17:59 CEST 2016
Tue May 24 20:19:16 CEST 2016   <-- Here it changed

What can be the problem?

Update:

  1. Yes, it is a VM on a XenServer 6.5
  2. No, in /var/log/messages/ there is NO entry when the time changed.
  3. Output of ntpq -p:
 remote           refid           st t when poll reach   delay   offset  jitter
 ------------------------------------------------------------------------------
 LOCAL(0)        .LOCL.           10 l   24   64  377    0.000    0.000   0.001
 *rs000486.fastro 192.53.103.108   2 u  119  256  377   21.547  -66949.   1.243

Update:

I have in total 10 Linux SLES 11 SP2 VM located on 2 host systems: 1 system is XenServer 6.5 and the other is XenServer 6.0. This issue is only on the host with XenServer 6.5 - all VMs running on host with XenServer 6.0 don't have this issue.

I copied the /etc/ntp.conf file from the correct running VM but no change.

  • 1
    Is this a virtual machine ? Anything pertinent written to /var/log/messages during the period ? What does ntpq -p show ? – steve May 24 '16 at 18:36
  • 1
    @steve I updated my question with the requested information. – Al Bundy May 24 '16 at 18:43
  • Try removing the local server from your ntp.conf ? – steve May 24 '16 at 18:58
  • 1
    Ah ok. Sorry missed that! I just wondered as I had a similar issue with VMware guests a year or so ago and the answer was I had to configure guests to ignore the hardware clock of the host. – sysadmiral May 24 '16 at 21:42
  • 1
    @MarkPlotnick You are the best! The time on the XenServer 6.5 is exactly what is replicated to the VMs on the host.The ntp service is running on the host and therefore I don't understand why the time is wrong. At least now we know why the time is wrong. I don't have to run the ntp client on the VMs - they are synchronized by XenServer. – Al Bundy May 24 '16 at 22:24
2

sysadmiral was already on the correct path and Mark Plotnick finalized the thought. The XenServer host has a wrong time and this time is then replicated to the VMs.

That far the reason for my question has been found and now I have to sort out how to correct the time issue on the XenServer but this may be another question.

I can now - according to sysadmiral - configure the clients to ignore the host or set the correct time on the host. The last option has the advantage that I do not have to configure the ntp service at all...

  • Although for instance, VmWare advises not to sync from the host time, I do it. I do not know the full explanation, however saving a little memory/CPU seems to be beneficial to the VMs, it is one less service to administer/update and on top of that, ntp daemons have had historically lots of security problems. It also fits like a glove to the philosophy of Unix of only installing and running the strictly necessary services. Nevertheless, if you have services that are highly dependent on the consistency of time, running the ntp daemon will provide a smoother adjustment as meuh states. – Rui F Ribeiro Jun 24 '16 at 9:25
0

Your ntpq -p output shows an offset of -66949. milliseconds with the selected (by * in col 1) reference. When this was stabilised, ntp did a step of 66 seconds to fix the time, corresponding to your observed jump from 20:17:59 to 20:19:16 (+10 seconds between observations).

You can usually run ntpdate to get an good estimate of the time, then run ntpd to slowly stabilise and then slowly move the clock into sync.

I dont know what your OS provides, but look for options -x and -g, and configurations with iburst at the end of the server ... line.

  • To be honest, I don't understand your answer and what I have to do. ntpdate is deprecated on SLES 11 SP2 and is doing - as I can see it - nothing. The time changed now again after 14 minutes... – Al Bundy May 24 '16 at 19:44
  • 1
    If it is deprecated that should mean it is built-in to ntpd, so ntpd -x and ntpd -g should work, though I dont know how ntpd is started on SLES. However, in your /etc/ntp.conf you should have a line beginning server to which you can add iburst at the end to make it synch up faster at the start. – meuh May 24 '16 at 19:51
  • In /etc/ntp.conf each server line had the iburst tag. I ran ntpd -x and ntpd -g. Now the gap changed from 66 seconds to 54 seconds. Is it getting better or not? – Al Bundy May 24 '16 at 19:56
  • I dont think the gap is important, but the time taken to get in sync. It shouldnt take 8 minutes at startup. – meuh May 24 '16 at 20:02
  • I have the feeling there is a misunderstanding. The problem is not that it takes 8 minutes to get in sync at startup, the problem is, that the time changes to a wrong value within 8 minutes once it was set correctly [e.q. the service started]. This is the problem! I don't understand what forces the system to change the time. I couldn't find anything in any log file. – Al Bundy May 24 '16 at 20:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.