3

I am setting up my Ubuntu 10.0.4 server to sync clock with a Windows 2008 AD. As none of the "remote" has a "*" in front (worst it had a blank space in front), does it mean no time sync source is selected? The offset just keep increasing. I tried ntpdate to the same server it worked OK.

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 172.18.133.201  .LOCL.           1 u   38   64  377    0.827  277.677  58.375

Any help to fix this?

Here is my ntp.conf (with all comments removed)

driftfile /var/lib/ntp/ntp.drift     

statistics loopstats peerstats clockstats

filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

restrict 127.0.0.1
restrict ::1

server 172.18.133.201 iburst

Here is result of ntpdata, ntpq and ntptime:

master@ds02:~$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 172.18.133.201  .LOCL.           1 u   38   64  377    1.094  527.521   8.092
master@ds02:~$
master@ds02:~$ ntpdc -c sysstat
time since restart:     15349
time since reset:       15349
packets received:       2163
packets processed:      246
current version:        0
previous version:       246
bad version:            0
access denied:          0
bad length or format:   0
bad authentication:     0
rate exceeded:          0

master@ds02:~$ ntpdate -d 172.18.133.201
18 Sep 13:51:42 ntpdate[12661]: ntpdate 4.2.4p8@1.1612-o Tue Apr 19 07:08:19 UTC 2011 (1)
Looking for host 172.18.133.201 and service ntp
host found : windc01.dom01.com
transmit(172.18.133.201)
receive(172.18.133.201)
transmit(172.18.133.201)
receive(172.18.133.201)
transmit(172.18.133.201)
receive(172.18.133.201)
transmit(172.18.133.201)
receive(172.18.133.201)
transmit(172.18.133.201)
server 172.18.133.201, port 123
stratum 1, precision -6, leap 00, trust 000
refid [LOCL], delay 0.04182, dispersion 0.00066
transmitted 4, in filter 4
reference time:    d40246c6.e7e11e93  Tue, Sep 18 2012  9:03:02.905
originate timestamp: d4028a6f.6657e747  Tue, Sep 18 2012 13:51:43.399
transmit timestamp:  d4028a6e.dc7980f5  Tue, Sep 18 2012 13:51:42.861
filter delay:  0.04202  0.04189  0.04182  0.04193
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.540268 0.539520 0.538873 0.538204
         0.000000 0.000000 0.000000 0.000000
delay 0.04182, dispersion 0.00066
offset 0.538873    
18 Sep 13:51:42 ntpdate[12661]: step time server 172.18.133.201 offset 0.538873 sec

master@ds02:~$ ntptime
ntp_gettime() returns code 5 (ERROR)
  time d4028a79.7d1947a0  Tue, Sep 18 2012 13:51:53.488, (.488667603),
  maximum error 7705516 us, estimated error 16 us
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 0.000 ppm, interval 1 s,
  maximum error 7705516 us, estimated error 16 us,
  status 0x2040 (UNSYNC,NANO),
  time constant 0, precision 0.001 us, tolerance 500 ppm,

ntpq's rv result:

ntpq> rv 45516
assID=45516 status=9014 reach, conf, 1 event, event_reach,
srcadr=windc01.dom01.com, srcport=123, dstadr=172.18.133.53,
dstport=123, leap=00, stratum=1, precision=-6, rootdelay=0.000,
rootdispersion=10300.171, refid=LOCL, reach=001, unreach=1, hmode=3,
pmode=4, hpoll=6, ppoll=6, flash=400 peer_dist, keyid=0, ttl=0,
offset=746.777, delay=0.587, dispersion=15.594, jitter=7.193,
reftime=d40246c6.e7346994  Tue, Sep 18 2012  9:03:02.903,
org=d402a6d2.ec1198ae  Tue, Sep 18 2012 15:52:50.922,
rec=d402a6d2.2cf807c0  Tue, Sep 18 2012 15:52:50.175,
xmt=d402a6d2.2cd18fe0  Tue, Sep 18 2012 15:52:50.175,
filtdelay=     0.59    0.64    0.59    0.65    0.61    0.67    0.50    0.65,
filtoffset=  746.78  749.88  753.20  756.30  759.51  747.08  750.40  753.52,
filtdisp=     15.63   15.66   15.69   15.72   15.75   15.78   15.81   15.84
David
  • 31
  • 1
  • 1
  • 3

2 Answers2

1

Yeah, it means no time source is being selected. The refid shows local, have you commented out local fudge clock lines in your ntp.conf file.

Also, I know from experience that there are issues while syncing with windows AD servers, I have seen this myself in case of RHEL servers getting time from windows AD. What timesource the AD server is using. Can you omit the AD server and use some public pool NTP server to see that in fact it is not a problem with NTP server, before debugging the client.

If you are determined to sync between the AD server and the ubuntu machine, then following output might help.

ntpq -pn

ntpdc -c sysstat

ntpdate -d <time-server-ip>

ntptime

Run ntpq in root prompt and then in the shell run these. associations rv

This should give some other clues.

Soviero
  • 4,366
  • 8
  • 36
  • 60
Soham Chakraborty
  • 3,584
  • 17
  • 24
  • Thanks, I posted my ntp.conf above. I am behind firewall so I cannot test any public NTP server. Could you explain a bit about the commands you want me to run? Is ntpq shell or ntpdc shell? – David Sep 18 '12 at 03:15
  • I think it is problem with the AD server. How the AD server is getting it's time, is it synced with another stratum 1 server or giving it's own time. The offset is too huge, meaning the time difference between server and client can't be matched. Your best bet would be to sync with AD server with a stratum 1 server and then use it to sync the ubuntu client. Look at the ntptime output, it also throws error in adjtime call. As root, run the command ntpq and it will give you a shell. There run associations and then rv to get some more finer detail. – Soham Chakraborty Sep 18 '12 at 06:54
  • Could you tell me which offset (a lot offset in the output) indicate it is a problem? Also, I run **ntpdate** before start **ntp**, when **ntp** start should the offset be very small to begin with? – David Sep 18 '12 at 08:04
  • The offset in ntpq -pn output is too large. ntpd will discard packets where offset is larger than 128 ms unless it runs with the -x option in /etc/sysconfig/ntpd. Ideally, you should try with that. Set -x in the options line in /etc/sysconfig/ntpd and then do service ntpd stop. Run ntpdate and then service ntpd start. – Soham Chakraborty Sep 18 '12 at 09:31
  • I added the "-x", the offset from **ntpq** started with -0.05. The offset from **ntpq** has been increasing. Also, Windows AD was not selected as time source (no * in front of the server name, it was still blank) – David Sep 19 '12 at 01:23
1

I was recently facing this very same issye, and by following the guide on VMWare homepage I was able to sync linux ntp clock with windows AD:

By default, an unsynced Windows server chooses a 10-second dispersion and adds to the dispersion on each poll interval that it remains in sync. An ESXi/ESX host, by default, does not accept any NTP reply with a root dispersion greater than 1.5 seconds.

As the ESX:es run ntp too, the same solution is applicable for Ubuntu: add following line to ntp.conf, and reload daemon:

tos maxdist 30
Petter H
  • 3,443
  • 1
  • 16
  • 19