1

I have a server where a lot of time chronyd isn't able to sync the system clock leading at a situation like that :

Reference ID    : 0A263C14 (10.38.60.20)
Stratum         : 4
Ref time (UTC)  : Tue Jun 04 12:20:09 2019
System time     : 4576.955566406 seconds fast of NTP time
Last offset     : +0.000107134 seconds
RMS offset      : 1.026136756 seconds
Frequency       : 80.575 ppm slow
Residual freq   : -0.003 ppm
Skew            : 0.019 ppm
Root delay      : 0.024930937 seconds
Root dispersion : 0.071089722 seconds
Update interval : 1030.2 seconds
Leap status     : Normal

If a issue a command like chronyc makestep which force the synchronization the system time went back to normal but after one days or two i have the same problem, the only thing which i have noticed is that the "last sample" from chronyc sources is very high :

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^? 10.37.23.20                   0   6     0     -     +0ns[   +0ns] +/-    0ns
^? 10.13.186.21                  0   6     0     -     +0ns[   +0ns] +/-    0ns
^* 10.38.60.20                   3  10   377   222  -4128us[-3993us] +/-  105ms
^? 10.15.214.60                  0   6     0     -     +0ns[   +0ns] +/-    0ns
^? 10.29.147.252                 0   6     0     -     +0ns[   +0ns] +/-    0ns
^? 10.25.100.172                 0   6     0     -     +0ns[   +0ns] +/-    0ns
^? 10.32.117.205                 0   6     0     -     +0ns[   +0ns] +/-    0ns
^? 10.32.62.252                  0   6     0     -     +0ns[   +0ns] +/-    0ns
^? 10.38.156.92                  0   6     0     -     +0ns[   +0ns] +/-    0ns
^+ 10.25.144.92                  4  10   377   242  -4371us[-4235us] +/-  121ms
^+ 10.38.27.76                   4  10   265   568  -4863us[-4724us] +/-

Any clue about what could be ? The server is a vmware virtual machine.

Thanks, Tommaso.

thomas
  • 13
  • 2

1 Answers1

1

Before makestep, you were +4576 seconds offset from 10.38.60.20. After, you are -0.003993 seconds. Microseconds unit is important, that's 6 decimal places difference.

Estimated error in the last column is +/- 0.105 seconds. That is on the high end of what I expect from a LAN, because it only takes about 0.200 s latency on many paths to the other side of Earth.

Improve on this by making more, low latency NTP servers reachable; none should be reach 0. Confirm each is a NTP server. Remove any firewall rules unnecessarily blocking you from accessing NTP servers.

Regarding hypervisors, be sure the host clock is synced to the same NTP service as everything else.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • Hi, thanks for your explanation hovewer i didn't do any makestep yet the value of -3993us is taken when the clock is out of sync of 4576s what i can't undestand is why chronyd isn't able to correct the system clock automatically as should be, this happen only with these virtual machine. Best regards Tommaso. – thomas Jun 05 '19 at 06:33
  • Then fix the VM host's NTP, plus on the guest stop any services that don't like being stepped and run `makestep`. Do so before some event happens that forces a guest time sync, like a guest snapshot. Depends on the makestep directive in chrony.conf, but usually step is not allowed after chronyd is started. – John Mahowald Jun 05 '19 at 09:57