strange time issue

[Maaz]

OS: SUSE Linux Enterprise 9 SP 3

I have almost 12 SLES9 SP3 Servers, that are running fine, and getting their time from an NTP server properly.

the machine in question is also a SLES9 SP3. This machine has a very strange problem. I did manually adjust the timezone/date/time, and then made this machine the ntp client, then start the ntp service(or ntpdate ip.of.ntp.server), now the time went bad.. i.e its almost 10 Hours back.

after manully adjusting the date/time/timezone
# date
Thu Jun 25 21:43:44 GMT+5

then
# rcxntp start
Thu Jun 25 11:38:19 GMT+5

and these are the messages from /var/log/messages
Jun 25 11:38:19 fsdumber03 ntpdate[12018]: step time server 10.0.0.79 offset -35966.778569 sec
Jun 25 11:38:19 fsdumber03 ntpd[12023]: ntpd 4.2.0a@1.1213-r Tue Nov 8 17:39:08 UTC 2005 (1)
Jun 25 11:38:19 fsdumber03 ntpd[12023]: precision = 1.000 usec
Jun 25 11:38:19 fsdumber03 ntpd[12023]: Listening on interface wildcard, 0.0.0.0#123
Jun 25 11:38:19 fsdumber03 ntpd[12023]: Listening on interface wildcard, ::#123
Jun 25 11:38:19 fsdumber03 ntpd[12023]: Listening on interface lo, 127.0.0.1#123
Jun 25 11:38:19 fsdumber03 ntpd[12023]: Listening on interface eth0, 10.55.1.51#123
Jun 25 11:38:19 fsdumber03 ntpd[12023]: kernel time sync status 0040
Jun 25 11:38:19 fsdumber03 ntpd[12023]: frequency initialized 124.648 PPM from /var/lib/ntp/drift/ntp.drift

# cat /var/lib/ntp/drift/ntp.drift
124.648

all other 12 machines(with similar OS/ntp server) doesn't has such issue/problem.

all machines(including the machine in question) has 'Hardware Clock set to 'UTC').

Regards
Maaz

[Colin Topliss]

So what does

ntpdate -q

give you? Does it match across servers? It looks like it isn't talking to the NTP server at all.

Also take a look with

ntpq -p

This will show all of your peers....
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 15 64 377 0.000 0.000 0.001
*88-96-233-89.ds .PPS. 1 u 601 1024 377 75.009 -2.068 3.712
132.146.236.132 .STEP. 16 u - 1024 0 0.000 0.000 0.000

If the '*' is next to LOCAL, then it means its not taking the time from the peers but from the system itself.

Col

[Steven E. Protter]

Shalom Maaz,

In addition to: ntpdate -q

It should be understood that ntp will not adjust servers off more than a few hours.

A server that is disconnected or not talking to its ntp server will if its internal clock is running very slow or fast, get so far out of adjustment that a manual update is required to get it back to adjustment. that or the ntpdate command.

If the ntpdate command fails then there is a problem with the ntp server or connecting to it.

SEP

[Matti_Kurkela]

Hmm... the error is almost exactly 10 hours, and your desired timezone is "GMT+5".

In the Unix timezone specifiers, the sign is often opposite of what you'd think it should be. This comes from the POSIX standard definition of the TZ environment variable: the signed number in the timezone specifier is the value that must be added to the _local_ time to get _GMT/UTC_ time.

This allowed omitting the sign of the number for North America, as computer memory was expensive back in the 1980's and most of the computers were built and used there.

If you set TZ=GMT+5, that means "add +5 hours to local time to get UTC"... so that actually means "the local time is of timezone GMT-5".
Run "date -u; date" and compare the times to see if this is your problem.

This confusion was probably one of the reasons why Linux and many other Unix-style systems have now moved to a new "Continent/Capital" style timezone specifications.

MK