NTP Issue

[ln_unix]

Hello All,

I need as ever help from you all.

I am not able to start NTP service,after starting,everytime it stops automatically after some time.
================================
Logs of syslog.log are as follows:-

Jul 1 05:48:46 cvx011 xntpd[25702]: tickadj = 625, tick = 10000, tvu_maxslew = 61875
Jul 1 05:48:46 cvx011 xntpd[25702]: precision = 11 usec
Jul 1 05:53:03 cvx011 xntpd[25702]: time error 33834.576361 is way too large (set clock manually)
========================================
Also, the output of < ntpq -pn > is as follows:-

# ntpq -pn
ntpq: read: Can't assign requested address
#
========================================
OUTPUT OF DATE COMMAND IS :-
# date
Thu Jul 1 06:06:21 EAT 2010
# date -u
Wed Jun 30 22:06:25 UTC 2010
#
=================================

Waiting for reply from you all.....

Best regards,
LN

[Michal Kapalka (mikap)]

hi,

thats normall, because the differenc is too big, so you need to stop the xntpd server and set the time manually with the date or ntpdate, them if its ok start the NTP server again.

mikap

[ln_unix]

Ok fine MIKAP.....Thanks for the quickest reply

[ln_unix]

But MIKAP,How can I find ,reason of the time change.....How can I find this????

[johnsonpk]

Hi ,

Are you doing NTP sync first time ? or it was working and suddenly started giving giving issues?

what is your timezone ?
can you post the output for the below commands to check the time difference between your server and the ntp server

export TZ=GMT
ntpdate -d


Regards!
Johnson

[ln_unix]

Hello Johnson,

Reply by my side is as follows:-

no, actually its an incident but it was running before.....

TZ=EAT-8
export TZ


# ntpdate -d 10.96.255.140
transmit(10.96.255.140)
receive(10.96.255.140)
transmit(10.96.255.140)
receive(10.96.255.140)
transmit(10.96.255.140)
receive(10.96.255.140)
transmit(10.96.255.140)
receive(10.96.255.140)
transmit(10.96.255.140)
server 10.96.255.140, port 123
stratum 5, precision -18, leap 00, trust 000
refid [57.212.163.97], delay 0.27817, dispersion 0.00066
transmitted 4, in filter 4
reference time: cfd6cc86.c4cf3d98 Thu, Jul 1 2010 16:12:54.768
originate timestamp: cfd6cef3.4d2b5d45 Thu, Jul 1 2010 16:23:15.301
transmit timestamp: cfd64ac8.9d8a5000 Thu, Jul 1 2010 6:59:20.615
filter delay: 0.28189 0.28162 0.28014 0.27817
0.00000 0.00000 0.00000 0.00000
filter offset: 33834.55 33834.55 33834.56 33834.55
0.000000 0.000000 0.000000 0.000000
delay 0.27817, dispersion 0.00066
offset 33834.559767

1 Jul 06:59:20 ntpdate[11958]: step time server 10.96.255.140 offset 33834.559767 sec

[johnsonpk]

>>reference time: cfd6cc86.c4cf3d98 Thu, Jul 1 2010 16:12:54.768

the above time refers the NTP server time according to the timezone you set before executing ntpdate command with debug option

is that time shows your local time ?
if not check the TZ variable value and set it properly until you get the time value equal to your local time from NTP server
(if the NTP client located GMT-8 (canada ) , the offset value for Unix is +8 not -8


>>>transmit timestamp: cfd64ac8.9d8a5000 Thu, Jul 1 2010 6:59:20.615

the above time is shows the NTP client time

1 Jul 06:59:20 ntpdate[11958]: step time server 10.96.255.140 offset 33834.559767 sec

the offset value nearly 9.30 hours which may occured because of a recent timezone and time changes on the NTP client


Can you tell me the NTP client location and the time zone which you set on the unix box?


looks like you need a change in TZ value and reset you server(NTP client) clock to local time

[rick jones]

Just for sake of completeness, NTP itself does not do any of its calculations in local time. It is all done in UTC (like the kernel). Issues with TZ aren't time synchronization issues, just issues with the correct setting of TZ :)

If a computer's clock is not synced it can drift considerably over time - it is designed to be a computer, not a Swiss watch :) Which is precisely why NTP was created in the first place - to help keep the clocks of computers from drifting from the "true" time.

[Elmar P. Kolkman]

What the debug tells you, is that your NTP server and the NTP client have a clock difference of about an hour.

What you can do to fix this, is run a ntpdate. Depending on the requirements, I would suggest running ntpdate with a -B option to force the clock to slowly get up to date. This is something programs and databases can handle. Jumping the clock with ntpdate (default action) might break things like schedulers and databases down, especially if the clock is stepped backwards.

Also, you might put the NTP server in the /etc/rc.config.d/ntpconf to make sure a ntpdate is run at every boot.