I posted this originally on the -questions list but did not make any headway.
We have an application where the user can change the date/time via a GUI. One
of the options the user has is to specify that the time is to be synced using
ntp. Our coding worked fine under BSD 7 but since we've moved to BSD 8 we've
encountered a problem where the command that we initiate from the GUI:
ntpd -g -q
to perform the initial time sync is hanging indefinitely. Logs we've captured
do not give any clues. This is the log from a BSD 7 system produced when this
ntpd command is run:
17 Feb 06:35:36 ntpd[3578]: logging to file /var/log/ntpd.log
17 Feb 06:35:36 ntpd[3578]: ntpd 4.2.0-a Sun Feb 24 09:12:07 UTC 2008 (1)
17 Feb 06:35:36 ntpd[3578]: precision = 1.676 usec
17 Feb 06:35:36 ntpd[3578]: kernel time sync status 2040
17 Feb 06:35:36 ntpd[3578]: frequency initialized -10.706 PPM from
/var/db/ntpd.drift
17 Feb 06:35:45 ntpd[3578]: synchronized to 198.186.191.229, stratum=2
17 Feb 06:35:45 ntpd[3578]: time slew +0.003648 s
and this is the log from a BSD 8 system:
17 Feb 06:35:36 ntpd[2293]: logging to file /var/log/ntpd.log
17 Feb 06:35:36 ntpd[2293]: precision = 1.676 usec
17 Feb 06:35:36 ntpd[2293]: Listening on interface #0 wildcard, 0.0.0.0#123
Disabled
17 Feb 06:35:36 ntpd[2293]: Listening on interface #1 wildcard, ::#123 Disabled
17 Feb 06:35:36 ntpd[2293]: Listening on interface #2 nic0,
fe80::2a0:d1ff:fee3:53cc#123 Enabled
17 Feb 06:35:36 ntpd[2293]: Listening on interface #3 nic1,
fe80::2a0:d1ff:fee3:53cd#123 Enabled
17 Feb 06:35:36 ntpd[2293]: Listening on interface #4 lo0, fe80::1#123 Enabled
17 Feb 06:35:36 ntpd[2293]: Listening on interface #5 lo0, ::1#123 Enabled
17 Feb 06:35:36 ntpd[2293]: Listening on interface #6 lo0, 127.0.0.1#123 Enabled
17 Feb 06:35:36 ntpd[2293]: Listening on interface #7 lagg0, 192.168.17.46#123
Enabled
17 Feb 06:35:36 ntpd[2293]: Listening on routing socket on fd #29 for interface
updates
17 Feb 06:35:36 ntpd[2293]: kernel time sync status 2040
17 Feb 06:35:36 ntpd[2293]: frequency initialized -10.706 PPM from
/var/db/ntpd.drift
It never gets past this last log line and we have to do a kill -9 on the ntpd
process. The ntp.conf file we're using is
# General Configuration
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org
# Drift file
driftfile /var/db/ntpd.drift
The versions of the two ntpd binaries are different--4.2.0-a for FBSD 7 and
4.2.4p5 for FBSD 8. Someone suggested that I try the command:
ntpq -pc rv localhost
But I'm not sure how to interpret the output. On a FBSD 7 system I get this:
remote refid st t when poll reach delay offset jitter
==============================================================================
+169.229.70.183 169.229.128.214 3 u 40 512 37 7.921 9.170 8.836
*208.75.88.4 192.12.19.20 2 u 43 512 37 12.049 8.224 8.168
+217.160.254.116 209.51.161.238 2 u 38 512 37 55.111 -7.128 10.347
+198.247.173.220 128.206.12.130 3 u 39 512 37 47.401 -1.149 3.659
status=c624 sync_alarm, sync_ntp, 2 events, event_peer/strat_chg, version="ntpd
4.2.0-a Sun Feb 24 09:12:07 UTC 2008 (1)", processor="amd64",
system="FreeBSD/7.0-RELEASE-p9", leap=11, stratum=16, precision=-20,
rootdelay=0.000, rootdispersion=8.340, peer=25349, refid=INIT,
reftime=00000000.00000000 Wed, Feb 6 2036 22:28:16.000, poll=4,
clock=cf26c2d5.ea2b4541 Wed, Feb 17 2010 11:32:37.914, state=1, offset=0.000,
frequency=-13.269, jitter=0.001, stability=0.000
and on a FBSD 8 system I get this:
remote refid st t when poll reach delay offset jitter
==============================================================================
assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
version="ntpd 4.2.4p5-a (1)", processor="amd64", system="FreeBSD/8.0-CURRENT",
leap=11, stratum=16, precision=-19, rootdelay=0.000, rootdispersion=0.000,
peer=0, refid=INIT,
reftime=00000000.00000000 Wed, Feb 6 2036 22:28:16.000, poll=6,
clock=cf26c4d1.d21b33f1 Wed, Feb 17 2010 11:41:05.820, state=1, offset=0.000,
frequency=-14.299, jitter=0.002, noise=0.002, stability=0.000, tai=0
169.229.70.183 .INIT. 16 u - 64 0 0.000 0.000 0.002
208.75.88.4 .INIT. 16 u - 64 0 0.000 0.000 0.002
217.160.254.116 .INIT. 16 u - 64 0 0.000 0.000 0.002
198.137.202.16 .INIT. 16 u - 64 0 0.000 0.000 0.002
In the case of the FBSD8 output, I collected this while one of these hangs was
happening. The most obvious difference is the .INIT. entries, but there also
appear to be several "0.0" type of entries that look like the ntpd process is
stuck in some kind of initialization state.
Anyone have any ideas what's going on here?
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
