System time vs Hardware time and Daylight Savings Time
 

I posted this yesterday in the networking forum, its had a lot of views, but no replies so I thought I'd try here. I'm running Mandrake 10.1 on a home desktop. I downloaded and installed this rpm timezone-2.4-7mdv2007.0.i586.rpm. On March 11th it all appeared to go as planned, my hourly log snip showed that at 2am the time changed to 3am and I looked no further in the log, should have though. Tonight as I was looking at the hourly log snip for errors I noticed this in my 7pm log snip which runs from 6:00pm to 6:59pm:

Mar 13 17:00:00 localhost postfix/pickup[28507]: 5B308434066: uid=0 from=<root>
Mar 13 17:00:00 localhost postfix/cleanup[31661]: 5B308434066: message-id=<20070313230000.5B308434066@cpollock.localdomain>
Mar 13 17:00:00 localhost postfix/qmgr[6892]: 5B308434066: from=<cpollock@earthlink.net>, size=17280, nrcpt=1 (queue active)
Mar 13 18:00:01 localhost postfix/smtp[31663]: 5B308434066: to=<cpollock@earthlink.net>, relay=smtpauth.earthlink.net[207.69.189.209], delay=1,

Mar 13 18:16:13 localhost fetchmail[21303]: 1 message for cpollock at pop.earthlink.net (2267 octets).
Mar 13 17:16:13 localhost spamd[31024]: spamd: connection from localhost.localdomain [127.0.0.1] at port 34887
Mar 13 17:16:13 localhost spamd[31024]: spamd: setuid to chris succeeded

Mar 13 18:18:23 localhost postfix/smtp[503]: 24F5D434066: to=<spam@uce.gov>, relay=smtpauth.earthlink.net[207.69.189.208], delay=0, status=sent (250 OK id=1HRGG7-00016o-Pi)
Mar 13 17:18:23 localhost postfix/qmgr[6892]: 24F5D434066: removed

It seems like by looking at the above that part of postfix is on central standard time and part on central daylight time, also spamassassin seems to be running an hour behind. I went and had a look at webmin -> Hardware -> System Time and I see two different times shown. At the moment it shows that system time is 18:40 and hardware time is 19:40. Time Zone is set to America/Chicago which is correct and I'm using this as my ntp server ntp-0.cso.uiuc.edu (United states IL). Date from the CLI is correct, Tue Mar 13 19:42:02 CDT 2007. In webmin even clicking "Set System Time to Hardware Time" doesn't correct this. My cronjobs were off by an hour but now seem to be running at the correct times. Any help would be appreciated, I don't think its a problem, its just annoying and it may correct itself when the old DST rolls around next month.

Thanks
Chris

Did you do "zdump -v /etc/localtime |grep 2007" to verify it shows Mar 11? The rpm probably created your new America/Chicago but if you didn't recopy it over /etc/localtime or have /etc/localtime as symbolic link to America/Chicago its probably not updated.

Also did you reboot after applying the change to insure all processes got the new timezone information?

I did forget to mention, yes I did run zdump

[root@cpollock ~]# zdump -v /etc/localtime | grep 2007
/etc/localtime Sun Mar 11 07:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 CST isdst=0 gmtoff=-21600
/etc/localtime Sun Mar 11 08:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 CDT isdst=1 gmtoff=-18000
/etc/localtime Sun Nov 4 06:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 CDT isdst=1 gmtoff=-18000
/etc/localtime Sun Nov 4 07:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 CST isdst=0 gmtoff=-21600

-rw-r--r-- 2 root root 1279 Jan 18 12:53 Chicago

lrwxrwxrwx 1 root root 35 Mar 13 06:04 localtime -> /usr/share/zoneinfo/America/Chicago


The reason that localtime has a different time stamp is because I was trying through webmin to sync the times as I explained in my initial post. I did log out and back in, question though, why would I have to reboot?

Are you running a Debian distribution?

If you go to http://rpm.pbone.net and type the word "timezone" in the search field and hit enter you'll find on page 3 the proper package for Mandrake 10.1 Official does not have "mdv2007" in the package name which is a package for Mandriva 2007. You can mix version packages with Debian, and some have fought to do so with Fedora, but it's not recommended with Mandriva.
Remove that package with urpme and install the proper one with command:

urpmi timezone

The reboot is because some processes only get timezone information when they start and never check again. The reboot insures that all processes are using your updated timezone information rather than something they stored before you updated it.

A cold boot of the box fixed the problem, thanks to all who replied and the suggestions.

Chris

Please post your thread in only one forum. Posting a single thread in the most relevant forum will make it easier for members to help you and will keep the discussion in one place. This thread is being closed because it is a duplicate.