clock problems

[Kassler]

Hello all!

I have a problem concerning ntp.
I tried to attach a server to a ntp-server and i get an
offset of -213692 with "ntpq -p".

In the syslog file i get an error.
xntpd[12937]: time error -2136.833089 is way too large (set clock manually)

But with "date" i have the same time as on the ntp-server.

Is there a problem with the hardware clock?? And how can i fix this problem.

OS: HPUX 11.00
Server: L3000

Thanks for help.

Greetings
Markus

[harry d brown jr]

What is your TZ set to?

live free or die
harry

[Kassler]

TZ is

Middle European Time/Summer Time (MET-1METDST).

thx

Markus

[Bill McNAMARA_1]

the times need to be less than 1000 seconds if they will sync or not.

What is the time difference?

Bill

[Mark Greene_1]

You can run ntpdate to fix the time between the two servers. Be sure to do this on a quite system (all users off, no background jobs running, check cron for an open time) so you don't get files with odd timestamps if it changes the time back, as this can give applications fits.

Then keep an eye on the syslog for xntpd messages.

HTH
mark

[harry d brown jr]

here's the manual:

http://www.docs.hp.com/hpux/onlinedocs/B2355-90685/B2355-90685_top.html

and here is a great thread:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x7d9303bbece8d5118ff40090279cd0f9,00.html


live free or die
harry

[A. Clay Stephenson]

Hi:

This is rather puzzling if your date command agrees with your NTP timesource. The first thing I would do is to get the timezone stuff out of the picture with a date -u command. See if the UTC time agrees with your NTP time source. If they are not within 1000 seconds then use the ntpdate command to force the time. I prefer to use the -B option to force the clock to slew the time. It make take a while but it will sync the time safely. You should then be able to start the xntpd daemon.

[Bill Thorsteinson]

Newer version of NTP have two options to deal with large time offsets.
-g prevents the server from shutting down on large offsets.
-x always slews the time rather than stepping the time.

Slewing time will take a long time if the offset is as bad as indicated.

Some versions of ntp seem to have a bug when resetting maximum slew rates and set invert the sign on the slew rate. You may need to step the time.

You may want to check the timezone variable in then environment. I have seen clocks corrected by adjusting the timezone variable.
echo $TZ