1

The time on one of our Linux box is very weird. Whenever I call date 3 times, the 4th call will give a wrong time(usually 1 hour later). I have setup cron to sync with ntp server. We have 20+ similar servers, only this one has this problem. Any idea? Thanks.

Linux 2.6.18-6-686 #1 SMP Thu Aug 20 21:56:59 UTC 2009 i686 GNU/Linux

Edit:

:~# date; date; date; date; date; date; date; date; date

Fri Jun 11 19:12:46 PDT 2010

Fri Jun 11 17:59:28 PDT 2010

Fri Jun 11 17:59:28 PDT 2010

Fri Jun 11 17:59:28 PDT 2010

Fri Jun 11 19:12:46 PDT 2010

Fri Jun 11 17:59:28 PDT 2010

Fri Jun 11 17:59:28 PDT 2010

Fri Jun 11 17:59:28 PDT 2010

Fri Jun 11 19:12:46 PDT 2010

date; sleep 10; date; sleep 10; date; sleep 10; date; sleep 10; date; sleep 10; date; sleep 10; date

Fri Jun 11 18:05:32 PDT 2010

Fri Jun 11 19:19:00 PDT 2010

Fri Jun 11 18:05:52 PDT 2010

Fri Jun 11 19:19:20 PDT 2010

Fri Jun 11 18:06:12 PDT 2010

Fri Jun 11 19:19:40 PDT 2010

Fri Jun 11 18:06:32 PDT 2010

garconcn
  • 2,388
  • 8
  • 35
  • 46
  • The pattern in your example is 3+1 as you state, but it's also every three seconds. Can you clarify which pattern it actually is? For example, what happens if you (1) issue four date commands one one line at the same time? `date; date; date; date` or (2) wait between times that you repeat the command or (3) use `sleep` like this: `date; sleep 10; date; sleep 10; date; sleep 10; date` ? – Dennis Williamson Jun 12 '10 at 00:47

4 Answers4

3

The fact that it always seems to be about an hour off strongly suggests to me that you have a timezone incorrectly set somewhere, and one of the sync tools you have running is trying to set your time to the incorrect timezone.

We have ntpd running too. Thanks.

You should not be running ntpd and setting the time with another tool via cron. Running multiple tools to synchronize time will almost always make things far worse.

Pick a tool and use it only. If this sever is virtualized please also make sure consider the time sync that is part of your VM tools. There should only be one thing setting time.

Zoredache
  • 130,897
  • 41
  • 276
  • 420
  • I have turned off the ntp setting in cron, but the problem still persists. Yes, the server is virtualized, so as other same servers. We created all those servers from one seed, hence they should have same configuration. It could be we manually changed something on this server. Thanks for the advice, I will try to see if I can find any problem in timezone. :) – garconcn Jun 14 '10 at 16:41
0

Why not use ntpd rather than ntp from a cron?

ircmaxell
  • 1,201
  • 8
  • 20
  • Can you show us the output of `ntpdc -c peers`? – jneves Jun 12 '10 at 07:16
  • # ntpdc -c peers remote local st poll reach delay offset disp ======================================================================= *time2.srv.ualbe xx.xx.xx.xx 1 1024 377 0.01781 0.000390 0.21243 =tb.mircx.com xx.xx.xx.xx 2 1024 377 0.02995 0.000909 0.21153 =zeus.yocum.org xx.xx.xx.xx 2 1024 377 0.08073 0.000266 0.21172 =ppp-7l.cyberabi xx.xx.xx.xx 3 1024 377 0.06616 0.006133 0.17198 – garconcn Jun 12 '10 at 19:16
0

Yeah, pick one method and stick with it. If, after having picked one method, you still have this problem then it's time to think it's due to a hardware bug. I'm not really a hardware person but a it does seem that this is the cause. Failing RTC battery (unlikely), RF interference on the system board (more likely), etc.

And BTW, ntpd is designed for clock syncing, it's designed to be the exclusive controller of the clock. Choose ntpd.

Allen
  • 1,315
  • 7
  • 12
0

From your comments, you have ntp working correctly (it's synchronyzed to time2.srv.ualbe). Disable all other methods of updating the clock. Check the time with date. If it's wrong, one of the following is happening:

  1. You have the wrong timezone defined (in your case PDT). In this case the results of date --utc will match in this and other machines.

  2. The NTP server is providing the wrong time (very unlikely in your situation as you have 4 servers agreeing to the same date - all the offsets are below 0.1 seconds).

jneves
  • 1,041
  • 6
  • 15