0

This is a XenServer 7.1 CU1 host. NTP should behave as in any other Linux distro. We have configured /etc/ntp.conf with following servers (have tried other servers with similar results and these servers worked in another environment:

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

After restarting the service, we check stats:

[root@c0101 ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*tock.usshc.com  .GPS.            1 u   56   64    1   32.936   36.036   0.000
 www.tripout.tec 128.233.154.245  2 u   56   64    1   82.397   46.653   0.000
+t2.time.bf1.yah 98.139.133.62    2 u   57   64    1   17.589   26.316   0.000
 mirrors.switch. 206.108.0.134    2 u   55   64    1   63.777   57.423   0.000

From this, I can see that tock.usshc.com was chosen (has * star symbol), the poll is at 62s which is minimum due to bad source, the offset is high (since I checked on a server on a different environment and it shows only -0.81), the jitter is 0 which looks odd as in all cases I have seen at least one low number such as 0.1 and the delay looks normal.

After about ten minutes, no servers had chosen (no * symbol) due to "bad sources", also the offset and jitter look pretty bad:

[root@c0101 ~]# ntpq -c peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 tock.usshc.com  .GPS.            1 u   52   64  205   32.952  6021.94 4422.72
 www.tripout.tec 128.233.154.245  2 u   64   64  377   82.473  5880.01 3724.85
 t2.time.bf1.yah 98.139.133.62    2 u    3   64  377   17.812  6647.80 3704.53
 mirrors.switch. 206.108.0.134    2 u    1   64  377   63.746  6678.59 3723.43

Here is the ntp log, which I am having a hard time understanding.

[root@c0101 ~]# cat /var/log/ntp.log
14 Sep 12:01:20 ntpd[3914]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
14 Sep 12:01:20 ntpd[3914]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
14 Sep 12:01:20 ntpd[3914]: Listen and drop on 1 v6wildcard :: UDP 123
14 Sep 12:01:20 ntpd[3914]: Listen normally on 2 lo 127.0.0.1 UDP 123
14 Sep 12:01:20 ntpd[3914]: Listen normally on 3 xapi1 10.131.250.22 UDP 123
14 Sep 12:01:20 ntpd[3914]: Listening on routing socket on fd #20 for interface updates
14 Sep 12:01:20 ntpd[3914]: 0.0.0.0 c016 06 restart
14 Sep 12:01:20 ntpd[3914]: 0.0.0.0 c012 02 freq_set kernel 500.000 PPM
14 Sep 12:01:21 ntpd[3914]: 0.0.0.0 c61c 0c clock_step +1014.260362 s
14 Sep 12:18:15 ntpd[3914]: 0.0.0.0 c614 04 freq_mode
14 Sep 12:18:16 ntpd[3914]: 0.0.0.0 c618 08 no_sys_peer
14 Sep 12:19:39 ntpd[3914]: ntpd exiting on signal 15
14 Sep 12:19:39 ntpd[4689]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
14 Sep 12:19:39 ntpd[4689]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
14 Sep 12:19:39 ntpd[4689]: Listen and drop on 1 v6wildcard :: UDP 123
14 Sep 12:19:39 ntpd[4689]: Listen normally on 2 lo 127.0.0.1 UDP 123
14 Sep 12:19:39 ntpd[4689]: Listen normally on 3 xapi1 10.131.250.22 UDP 123
14 Sep 12:19:39 ntpd[4689]: Listening on routing socket on fd #20 for interface updates
14 Sep 12:19:39 ntpd[4689]: 0.0.0.0 c016 06 restart
14 Sep 12:19:39 ntpd[4689]: 0.0.0.0 c012 02 freq_set kernel 500.000 PPM
14 Sep 12:19:40 ntpd[4689]: 0.0.0.0 c61c 0c clock_step +1.067923 s
14 Sep 12:19:41 ntpd[4689]: 0.0.0.0 c614 04 freq_mode
14 Sep 12:19:42 ntpd[4689]: 0.0.0.0 c618 08 no_sys_peer
14 Sep 12:22:58 ntpd[4689]: 0.0.0.0 c628 08 no_sys_peer
14 Sep 12:26:11 ntpd[4689]: 0.0.0.0 c638 08 no_sys_peer

Here are Additional outputs of ntpq -c as and others that I am trying to understand as well.

I have been using this links to troubleshoot: http://support.ntp.org/bin/view/Support/TroubleshootingNTP https://rags.wordpress.com/2011/10/17/how-to-debug-ntp-issues/

Improve this question
5
  • curious that something is sending SIGTERM to ntp: ntpd exiting on signal 15
    – Jeff Schaller ♦
    Sep 15, 2018 at 0:39
  • Is it possible it is in a control network without direct Internet access and it should be using the corporate NTP?
    – Rui F Ribeiro
    Sep 15, 2018 at 1:04
  • Feels like a bad drift file, so the kernel is overcompensating for clock drift. I'll try to get a write up on how to fix that. Another possibility is that there are two things trying to discipline the clock (chrony and ntpd, for example).
    – roaima
    Sep 15, 2018 at 13:36
  • 1
    @JeffSchaller that's a suicide signal when the clock drift becomes unmanageable.
    – roaima
    Sep 15, 2018 at 13:51
  • I have found that jitter is high since the offsets are constantly changing. See additional outputs: filtoffset= 2537.62 1723.98 885.37 46.65 0.00 0.00 0.00 0.00" And this should all be caused because the system clock is ticking with the wrong frequency. I understand that if ticks with the right frequency, the jitter should go down and then ntp can start fixing the offset. I found this great article and will keep posted of the result log.or.cz/?p=80
    – Pietro Doninelli
    Sep 19, 2018 at 17:22

2 Answers 2

Reset to default
0

If this is a virtual machine, make sure:

  1. You have tinker panic 0 set in your ntp.conf (NOTE: this MUST be the first line int the conf file!). This will prevent ntpd from bailing out if the clock drifts to far. And...

  2. Make sure you aren't running in slew mode (ntpd -x). Slew mode will try to make gradual adjustments, rather than stepping the clock. This can be a problem on VMs if the clock is drifting faster than the slew rate.

Improve this answer
3
  • 1
    OP says it's a Xen host, not a VM.
    – roaima
    Sep 15, 2018 at 7:07
  • Ah, right you are. In any case, I would still try the tinker panic 0 to see if that stops ntpd from exiting.
    – guzzijason
    Sep 15, 2018 at 19:02
  • If it can't discipline the clock, exiting hard is a good a way as any to raise attention to the issue
    – roaima
    Sep 15, 2018 at 22:41
0

We were able to fix this by changing the clocksource to xen (the hypervisor) instead of dom0 (the management VM) with /opt/xensource/libexec/xen-cmdline --set-dom0 clocksource=xen

Another more complicated fix was adjusting the tick frequency, see this link

I don't have much information about the cause, other that NTP is not able to adjust the clock as it is drifting too fast due to some bug on the current release combined with the use of some kinds of Dell hardware.

This is while the fix is released in newer versions.

Improve this answer

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.