Interesting time issue …

Interesting Time issue in Linux.<-->

To complicate things a little, this was Redhat Enterprise Linux 4 update 2 in a VMware VM – reason why it makes it a little more complicated is because that there’s a time problem for Virtual Machines – in virtualization, you can’t afford to give the clock ticks that the older 2.6 kernels ask for (default 1000HZ). You can read more on it here: http://www.vmware.com/vmtn/resources/238.

So in this case, virtualization wasn’t the problem.

Here’s where I started:

ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime

date

Mon Feb 13 18:25:28 UTC 2006

ls -ld /etc/localtime

lrwxrwxrwx 1 root root 35 Feb 13 18:25 /etc/localtime -> /usr/share/zoneinfo/America/Chicago

cat /etc/sysconfig/clock

ZONE=”America/Chicago”

UTC=false

ARC=false

run hwclock – it just gives you the prompt back.

date -s “Feb 13 20:25:28 PST 2006”

run date and get

Mon Feb 13 04:25:28 UTC 2006

run setup – go through the options set it to America/Chicago and still … UTC … why!?

set:

export TZ=America/chicago

still … date shows UTC!

reboot the Vm, go into the bios … same thing …. why!!??

zdump -v America/Chicago … shows a bunch of bullshit – nothing that helps.

finally:

rpm -qf /usr/share/zoneinfo/America/Chicago

rpm –verify tzdata-2004e-2

S.5….T. /usr/share/zoneinfo/America/Chicago

S.5….T. /usr/share/zoneinfo/CST6CDT

S.5….T. /usr/share/zoneinfo/SystemV/CST6CDT

S.5….T. /usr/share/zoneinfo/US/Central

ahh … wonder how the files got changed. Anyways, it doesn’t matter.

reinstalled rpm

rpm –force -Uvh tzdata-2004e-2.noarch.rpm

Now run:

ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime

Now the date’s okay … cool deal!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.