DST Time Change Issues
From BLUG
This page is here to document and attempt to resolve the Linux issues related to the switch to Daylight Savings Time in most of Indiana. The section on restarting all services after upgrading /etc/localtime is also relavent to anyone who has changed their /etc/localtime file. This is important for next year when the U.S. switches to an extended DST that will be 8 weeks longer.
Upgrading Your Timezone
By now, you should have upgraded your timezone data to the latest available for your distrobution. Once you have upgraded your data, you should reset your timezone to ooordinate with America/Indianapolis, this should copy a new /etc/localtime file into place or change the symlink. DO NOT MOVE YOUR SYSTEM TIME FORWARD. Changing the timezone should be enough to fix the date.
Recommend changing hardware clock to UTC/GMT
I would highly recommend changing your hardware clock to UTC/GMT and telling your OS that the hardware clock is in UTC/GMT. To make this change, boot to your system and set the system clock to the correct time and time zone. Then run this command as root:
hwclock --utc --systohc
That will set your hardware clock to UTC/GMT. Then change your the clock settings for your distro to realize that your HC is in GMT. On RedHat, this can be done through the system-config-date or redhat-config-date programs.
Restart all services
Most people probably haven't done this part.
Some services load /etc/localtime once when starting up and never reload it unless you restart the service. If those services started running before you made the upgrade, you will need to restart them one by one. It may be best just to restart the server itself to make sure that you get everything.
If you don't do this, services like syslogd, klogd, crond and sshd will have the wrong time and will log times incorrectly. Crond may have futher issues like running jobs at the wrong time.
People normally don't have this problem when they switch to DST, it is just happening to Indiana because we have actually changed our timezone, which people usually don't do.
Check if you have this problem
One easy way that you can check for this problem is to look in your log files. Especially /var/log/messages, /var/log/cron and /var/log/maillog. You might see a series of lines simular to these where the time alternates back and forth between two different hours:
Apr 2 03:00:10 acidburn sshd(pam_unix)[11444]: session opened for user bboyken by (uid=0) Apr 2 04:00:31 acidburn login(pam_unix)[11767]: session opened for user jsmith by (uid=0) Apr 2 04:00:31 acidburn -- jsmith[11767]: LOGIN ON pts/11 BY mmathews FROM 206.97.64.2 Apr 2 03:00:40 acidburn sshd(pam_unix)[11444]: session closed for user jsmith Apr 2 03:00:41 acidburn sshd(pam_unix)[12900]: session opened for user jsmith by (uid=0)
You can also create a log message for ssh by trying to login to your computer through localhost and checking the logs immediately afterword to see if the logged time matches the real time.
If you are having this problem, please add your distrobution of Linux and version to the list below if it is not already there. Feel free to update this page with any new issues that you find or things that should be checked.
Platforms that we've seen this issue on
- RHEL 4 (some)
- RHEL 3
- RedHat 7.2
- RedHat 6.2
- Gentoo 2006.0 (glibc-2.3.5-r2)
Programs that experience this issue
Services
- syslogd
- klogd
- vixie crond
- opensshd
- sendmail
- postfix
- net-snmpd
- BIND named
Other
- gkrellm2
Links
Credits
This problem was discovered on April 2nd by Mark Krenz.

