I'm trying to set up time sync on a CentOS 5.5 VDS but can't figure out why it won't update to the correct timezone. e.g. After manually setting the correct date and time when I run this:

date && ntpdate au.pool.ntp.org && date

I get this:

Mon Oct 17 08:58:48 EDT 2011
16 Oct 17:58:01 ntpdate[14659]: step time server offset -54048.345159 sec
Sun Oct 16 17:58:01 EDT 2011

etc/localtime has been replaced with a link to the Australia/Melbourne timezone file and `/etc/sysconfig/clock' has been edited accordingly. The server has been rebooted since those changes and appears to (at long last) be using the correct timezone, so why does ntpdate appear to be ignoring it?

Incidentally, rdate simply times out and I've yet to determine why. I also have the ntpd service installed but have it disabled until I get this issue sorted out.

  • Was your timezone overwritten by another one? Can you do "strace ntpdate au.pool.ntp.org", at the end you should see a line similar to "read(5, "\nCET-1CEST,M3.5.0,M10.5.0/3\n", 4096)". What does it show for you? – ott-- Oct 16 '11 at 23:03
  • @ott, it shows read(5, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"..., 4096) = 3519 and I don't know how to interpret that. – John Gardeniers Oct 16 '11 at 23:11
  • No, it's the read() 2 lines beyond that – ott-- Oct 16 '11 at 23:15
  • In the past I had time problems (on Debian/Ubuntu) when the /etc/localtime was a soft link. Some programs and chrooted software behaved strangely. From there on I make sure that this is a real copy and not a link. – mailq Oct 16 '11 at 23:43
  • My trace looks different, the read is followed by lseek() and another read(). What does "tail -1 /etc/localtime" tell you? – ott-- Oct 16 '11 at 23:47

My Melbourne has EST-10EST,M10.1.0,M4.1.0/3. Yours is like the file for New_York.

| improve this answer | |

I had a similar issue. I finally determined my /usr/share/zoneinfo/Australia/Melbourne file was the same as New_York.

Once I had changed it by copying a Australia Melbourne file from another server, all was fine with time again.

Simple to just do the following to reinstall tzdata

sudo yum reinstall tzdata

Very annoying issue but all fixed after that.

| improve this answer | |
  • That did indeed turn out to be the problem in my case, which ott's answer alerted me to, and I fixed it the same way as you did. – John Gardeniers Jan 22 '12 at 22:32

on debian-based systems, run as root:

dpkg-reconfigure tzdata

And select your correct timezone.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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