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

Improve this question
1
  • 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, 2010 at 0:47

4 Answers 4

Reset to default
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.

Improve this answer
1
  • 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, 2010 at 16:41
0

Why not use ntpd rather than ntp from a cron?

Improve this answer
2
  • Can you show us the output of ntpdc -c peers?
    – jneves
    Jun 12, 2010 at 7: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, 2010 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.

Improve this answer
1
  • Thanks. We are using VM. I have changed the setting to use ntpd only. :)
    – garconcn
    Jun 14, 2010 at 17: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).

Improve this answer
1
  • Thanks for the advice. I will look into the timezone. :)
    – garconcn
    Jun 14, 2010 at 17:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .