Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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


:~# 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

share|improve this question
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 0:47
Thanks for the advice, it really helps. – garconcn Jun 12 '10 at 1:05

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.

share|improve this answer
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

Why not use ntpd rather than ntp from a cron?

share|improve this answer
We have ntpd running too. Thanks. – garconcn Jun 12 '10 at 0:38
Can you show us the output of ntpdc -c peers? – jneves Jun 12 '10 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 xx.xx.xx.xx 2 1024 377 0.02995 0.000909 0.21153 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

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.

share|improve this answer
Thanks. We are using VM. I have changed the setting to use ntpd only. :) – garconcn Jun 14 '10 at 17:12

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).

share|improve this answer
Thanks for the advice. I will look into the timezone. :) – garconcn Jun 14 '10 at 17:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.