ntp not working

[Manoj Bhardwaj]

Dear all,

on few server ntp is not working properly and time is not getting synchronized regularly:

1. xntpd deamons is running fine.
ps -ef |grep xntpd
root 21107 1 0 00:20:26 ? 0:00 /usr/sbin/xntpd
2. ntpq gives below information w/o (*) with any of the entry

ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
sgp-hr.sgp.st.c 0.0.0.0 16 u 27 64 0 0.00 0.000 16000.0
pgva417.sgp.st. 10.80.0.13 6 u 26 64 17 2.59 2251199 1876.22
pncy034.sgp.st. 57.7.62.97 4 u 25 64 17 3.43 2251199 1875.18

3. If i run ntpdate it wortks fine
ntpdate -q pncy034.sgp.st.com
server 164.129.230.20, stratum 4, offset 22511.995277, delay 0.02921
22 Jan 00:25:19 ntpdate[21548]: step time server 164.129.230.20 offset 22511.995277 sec

4. COnfiguration of ntp.conf is as below
server 164.129.230.22 version 3 prefer
server 164.129.230.19 version 3
server 164.129.230.20 version 3
driftfile /var/adm/syslog/ntp.drift
logconfig =syncall -sysall +clockall -peerall allinfo

please suggest what i should do correct this problem

regards
Manoj

[Matti_Kurkela]

The ntpdate output indicates there is a huge difference between the NTP time and time of the server's local clock: more than 6 hours.

In this case, the xntpd does not do anything because correcting such a gross error may require other sysadmin actions (for example, deciding what to do with any cron jobs that might normally be run during the time that will be skipped over).

Also check your timezone settings: the NTP protocol always uses UTC time. If your timezone settings are incorrect, your system clock will then show a "wrong" local time.

MK

[Manoj Bhardwaj]

MK,

Time zone is set to MET-1METDST which same on all server where it is working fine. ntpdate also working fine after we modified the time manually. but still there is no reference server :

ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
sgp-hr.sgp.st.c 0.0.0.0 16 u 1 64 0 0.00 0.000 16000.0
pgva417.sgp.st. 10.80.0.13 6 u 64 64 1 2.62 75.762 15875.0
pncy034.sgp.st. 57.7.62.97 4 u 63 64 3 2.35 -1.467 7916.81

# ntpdate -q pncy034.sgp.st.com
server 164.129.230.20, stratum 4, offset 0.161043, delay 0.02754
22 Jan 09:57:32 ntpdate[5495]: adjust time server 164.129.230.20 offset 0.161043 sec


#cat /etc/TIMEZONE
TZ=MET-1METDST
export TZ

regards
Manoj

[Dennis Handly]

>Time zone is set to MET-1METDST which same on all server where it is working fine.

What does "date -u" show on all of them? Roughly the same time?

[Manoj Bhardwaj]

Hi Dennis,

date -u gived below output, roughly same time on the servers where Ntp is working fine or not working:

Thu Jan 22 11:41:40 UTC 2009

Also TimeZone is MET-1METDST on all the server where NTP is working fine or not working.

Regards
Manoj

[Bill Hassell]

> sgp-hr.sgp.st.c 0.0.0.0 16 u 1 64 0 0.00 0.000 16000.0
> pgva417.sgp.st. 10.80.0.13 6 u 64 64 1 2.62 75.762 15875.0
> pncy034.sgp.st. 57.7.62.97 4 u 63 64 3 2.35 -1.467 7916.81

The NTP server sgp-hr is not working at all. Either the IP address is wrong, the address is blocked, NTP services are denied to your server at sgp-hr, or this is not an NTP server. The last number (16000.0 indicates that you are communicating with this server. I would remove the "prefer" option since the server isn't working and let NTP use all servers equally. You can verify that a remote NTP server is working OK for your system by using ntpq -p server-IP. This will query the remote server as to its time sources.

This line:
> logconfig =syncall -sysall +clockall -peerall allinfo

does not appear in the man pages for xntpd or in the default config file comments for ntp.conf.

[Manoj Bhardwaj]

Hi Bill,

Below is output for ntpq -p server_name:

ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
sgp-hr.sgp.st.c 0.0.0.0 16 u 25 64 0 0.00 0.000 16000.0
pgva417.sgp.st. 10.80.0.13 6 u 24 64 17 2.04 310.494 1982.51
pncy034.sgp.st. 57.7.62.97 4 u 23 64 37 1.54 306.075 1002.17
# ntpq -p sgp-hr.sgp.st.com
remote refid st t when poll reach delay offset disp
==============================================================================
+CHU(1) CHU(1) 9 - 38 64 377 0.00 0.000 0.02
ntp.sgp.st.com .GPS. 1 u 7 64 0 8.47 0.069 16000.0
+conssaf2.sgp.st sgpeu1.sgp.st.c 6 u 996 1024 252 8.65 0.210 16000.0
#consesc1.sgp.st sgpeu1.sgp.st.c 6 u 529 1024 376 4.99 93.947 16000.0
# ntpq -p pgva417.sgp.st.com
remote refid st t when poll reach delay offset disp
==============================================================================
+crn-pwr.crn.st. 57.221.145.13 5 u 736 1024 377 134.54 0.678 2.61
*10.80.0.13 pncy034.sgp.st. 5 u 621 1024 377 200.23 -3.286 0.95
pncy034.sgp.st. 0.0.0.0 16 u - 1024 0 0.00 0.000 16000.0

# ntpq -p pncy034.sgp.st.com
remote refid st t when poll reach delay offset disp
==============================================================================
+57.7.62.113 57.7.127.22 3 - 151 512 377 224.06 9.963 0.58
pgva417.sgp.st. crn-pwr.crn.st. 6 - 288d 1024 0 3.85 -4.766 16000.0
*57.7.62.97 57.7.127.22 3 - 52 512 377 14.80 -2.039 1.05

Also i tried to start xntpd without prefer option and with changing the preferred server but still the same problem as below:

ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
pncy034.sgp.st. 57.7.62.97 4 u 10 64 1 1.97 234.399 15875.0
sgp-hr.sgp.st.c 0.0.0.0 16 u 9 64 0 0.00 0.000 16000.0
pgva417.sgp.st. 10.80.0.13 6 u 8 64 1 1.77 242.637 15875.0

regards
Manoj

[Dennis Handly]

>date -u given below output, roughly same time on the servers where NTP is working fine or not working:

This should be the same on all UNIX computers in the world. So at least you have them all roughly synchronized.

>Also TimeZone is MET-1METDST on all the server

This isn't important, only UTC.

[rick jones]

Make certain that you have a working time server configured for NTPDATE_SERVER in /etc/rc.config.d/netdaemons. That way, whenever you boot, you stand a decent chance of the system time being within the limits of xntpd's willingness to start synchronizing time.

And since sgp-hr.sgp.st.c shows no reachability, the suggestions that it is either toast or being precluded from talking with your system sounds about right.

Also, it will take xntpd _several_ minutes to synchronize time with one of the servers. IIRC it will only happen after the "reach" statistic gets reasonably large - and the "disp" metric reasonably small.

[Manoj Bhardwaj]

Hello All,

eux290{root}# date -u
Wed Feb 4 06:46:49 UTC 2009
eux290{root}# cat /etc/ntp.conf |grep -v '^#'
server 164.129.230.20 prefer
server 164.129.230.19
driftfile /var/adm/syslog/ntp.drift
eux290{root}# ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
pncy034.sgp.st. 57.7.62.97 4 u 24 64 7 1.34 130.781 3926.18
pgva417.sgp.st. 10.80.0.13 6 u 23 64 17 3.98 196.428 1967.04
eux290{root}# ntpdate -d -v 164.129.230.20
transmit(164.129.230.20)
receive(164.129.230.20)
transmit(164.129.230.20)
receive(164.129.230.20)
transmit(164.129.230.20)
receive(164.129.230.20)
transmit(164.129.230.20)
receive(164.129.230.20)
transmit(164.129.230.20)
server 164.129.230.20, port 123
stratum 4, precision -18, leap 00, trust 000
refid [57.7.62.97], delay 0.02846, dispersion 0.00014
transmitted 4, in filter 4
reference time: cd33b810.4744509c Wed, Feb 4 2009 7:45:36.278
originate timestamp: cd33b887.387ddb7e Wed, Feb 4 2009 7:47:35.220
transmit timestamp: cd33b886.f9bb6000 Wed, Feb 4 2009 7:47:34.975
filter delay: 0.02971 0.02866 0.02846 0.02888
0.00000 0.00000 0.00000 0.00000
filter offset: 0.243713 0.243798 0.243576 0.243506
0.000000 0.000000 0.000000 0.000000
delay 0.02846, dispersion 0.00014
offset 0.243576

4 Feb 07:47:34 ntpdate[4191]: adjust time server 164.129.230.20 offset 0.243576 sec
eux290{root}# cat /etc/rc.config.d/netdaemons |grep -v '^#'
export NTPDATE_SERVER=
export XNTPD=1
export XNTPD_ARGS=
eux290{root}# ps -ef |grep ntp
root 4430 13893 1 07:48:47 pts/7 0:00 grep ntp
root 1643 1 0 07:39:21 ? 0:00 /usr/sbin/xntpd
eux290{root}# pw
sh: pw: not found.
eux290{root}# pwd
/var/adm/syslog
eux290{root}# grep ntp syslog.log |tail -5
Feb 4 07:43:38 eux290 xntpd[1643]: time reset (step) 0.235678 s
Feb 4 07:43:38 eux290 xntpd[1643]: synchronisation lost
Feb 4 07:47:55 eux290 xntpd[1643]: synchronized to 164.129.230.19, stratum=6
Feb 4 07:47:55 eux290 xntpd[1643]: time reset (step) 0.263163 s
Feb 4 07:47:55 eux290 xntpd[1643]: synchronisation lost
eux290{root}# grep ntp syslog.log |tail -6
Feb 4 07:43:38 eux290 xntpd[1643]: synchronized to 164.129.230.20, stratum=4
Feb 4 07:43:38 eux290 xntpd[1643]: time reset (step) 0.235678 s
Feb 4 07:43:38 eux290 xntpd[1643]: synchronisation lost
Feb 4 07:47:55 eux290 xntpd[1643]: synchronized to 164.129.230.19, stratum=6
Feb 4 07:47:55 eux290 xntpd[1643]: time reset (step) 0.263163 s
Feb 4 07:47:55 eux290 xntpd[1643]: synchronisation lost


Please see NTP configuration again, I still don't any (*) in output of ntpq -p and now getting synchronisation lost message in syslog.
Please suggest something

regards
MB