how to prepare older Linux systems for 2007 DST changes
I thought tzdata RPM package alone should prepare RHEL/RHL/CentOS/Fedora Core linux systems for the coming 2007 DST changes. Well, it was not entirely true. It turns out many applications use a file called ‘/etc/localtime’, which is not part of tzdata, but of glibc RPM package.
In our lab, a CentOS 4.1 test server failed the simple readiness verification for 2007 DST changes, after its tzdata package got upgraded to the latest tzdata-2006m-3.el4 RPM from CentOS 4.4 upgrade YUM repository.
$ date -d “2007-03-11 04:59:00″
Sun Mar 11 04:59:00 EST 2007
Surprised, I did a strace to see where date gets its idea. It uses /etc/localtime, which belongs to glibc pacakge.
open(”/etc/localtime”, O_RDONLY) = 3
$ rpm -qf /etc/localtime
glibc-2.3.4-2.9
To check whether /etc/localtime really contains the outdated DST information, I used ‘zdump -v’ :
$ /usr/sbin/zdump -v /etc/localtime | grep 2007
/etc/localtime Sun Apr 1 06:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 EST isdst=0 gmtoff=-18000
/etc/localtime Sun Apr 1 07:00:00 2007 UTC = Sun Apr 1 03:00:00 2007 EDT isdst=1 gmtoff=-14400
/etc/localtime Sun Oct 28 05:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 EDT isdst=1 gmtoff=-14400
/etc/localtime Sun Oct 28 06:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 EST isdst=0 gmtoff=-18000
Well, /etc/localtime is outdated for sure, while tzdata is up-to-date. To me, it’d make more sense to have /etc/localtime synced up with whatever zone file you have from tzdata, whenever you upgrade glibc or tzdata, a trigger would be there to do post-installation sync-up.
Sure enough, the changelog (excerpted below) of glibc RPM package on an up-to-date CentOS 4.4 confirmed my line of thinking. I am just a bit surprised and disappointed in FOSS why it wasn’t caught on earlier.
* Fri May 05 2006 Jakub Jelinek <jakub@redhat.com> 2.3.4-2.20
- add %triggerin for tzdata to glibc-common, so that tzdata updates
update /etc/localtime and /var/spool/postfix/etc/localtime if they exist
Pleaset note that trigger added to glibc-common for tzdata can be verified using rpm command on FC6 but not on RHEL4 (CentOS 4)
FC6$ rpm -q –triggeredby tzdata
glibc-common-2.5-10.fc6
RHEL4$ rpm -q –triggeredby tzdata
no package triggers tzdata
So, as much as I dislike to do it outside the “perfect” world of RPM, one has to manually update /etc/localtime, unless you opt to upgrade glibc + glibc-common to versions newer than 2.3.4-2.20 (May 05 2006) along with tzdata to prepare older Linux systems for the 2007 DST changes.
For a test CentOS 4.1 server located in Atlanta, GA, the timezone is ‘EST5EDT’. It is easy to see and confirm the /etc/localtime is from /usr/share/zoneinfo/America/New_York instead of EST5EDT file. EST5EDT used to be a hard link to America/New_York (as of tzdata-2005f), now it is not even the same file any more in newer tzdata (tzdata-2006).
$ md5sum /etc/localtime /usr/share/zoneinfo/America/New_York
4894d160f97e824d37378342cfe73ff0 /etc/localtime
4894d160f97e824d37378342cfe73ff0 /usr/share/zoneinfo/America/New_York
With no further ado, I manually synced up /etc/localtime with the new /usr/share/zoneinfo/America/New_York.
# cp -p /usr/share/zoneinfo/America/New_York /etc/localtime
Now the test CentOS 4.1 server passed verification using “zdump -v” as well as the simple ‘date -d’ verification test.
$ /usr/sbin/zdump -v “America/New_York” |grep 2007
America/New_York Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1 gmtoff=-14400
$ date -d “2007-03-11 04:59:00″
Sun Mar 11 04:59:00 EDT 2007
As noted in the glibc changelog excerpt above, same manual update may need to be applied if you have Postfix’s /var/spool/postfix/etc/localtime. Apparently there are applications out there have their own copy of ‘localtime’ as well, besides JAVA. On a FC6 server,
- OpenSSH-server has /var/empty/sshd/etc/localtime # same as /etc/localtime
- avahi has /etc/avahi/etc/localtime # different from /etc/localtime. It passed the simple ‘date -d’ verification though.
For mission-critical systems, one may need to go through code audit similar to what people did for Y2K.
In summary, to prepare older Linux systems, including CentOS 4.1, 4.2, RHEL AS 4.1, RHEL 2, RHEL 3, RHL 9 or older, more than likely you need follow these steps to prepare for 2007 DST changes.
Please note, truly old RHL 9 (RHEL 2, RHEL 3) systems will need to get their glibc upgraded to 2.3.2-64 or newer first (More details here).
- choose and upgrade to the latest tzdata RPM package. A local repository of tzdata RPM packages for varous Linux distributions is avaiable for your convenience.
- need to manually update /etc/localtime to the timezone file suitable for your site/city/country/locale
- Check for and update applications’ own local copies of timezone files as well.
- verification is the key.
