Red Hat Bugzilla – Bug 199792
glibc errata updates modify system time zone
Last modified: 2007-11-30 17:07:10 EST
Description of problem:
glibc upgrade screws with /etc/localtime.
Version-Release number of selected component (if applicable):
Seen it before. Latest case is with 2.3.2-95.44.
Steps to Reproduce:
1. Check your customized /etc/localtime.
2. Upgrade glibc with an erratum.
3. See how /etc/localtime has been replaced, generally with the wrong file from
System localized time zone modified; in my case all systems get moved from UTC
to the wrong zone.
System localized time zone should not be modified.
All my systems must remain on UTC time. Unfortunately the Red Hat installer no
longer offers UTC as an installation time zone option, nor does timeconfig
include any non-geographic time zone designations. Consequently I end up having
to choose a geographic time zone at installation time. Afterward, I fix
/etc/localtime by copying /usr/share/zoneinfo/UTC in its place. Then every time
a glibc update comes out, the update overwrites /etc/localtime with the
geographic localized zone file that was designated at installation time. I
subsequently have to log in to every system to fix /etc/localtime and restart
numerous services which are now operating in the wrong zone.
This problem could alternately be fixed by putting UTC and other logical zones
back into timeconfig.
If you manually tweak /etc/localtime rather than rely on timeconfig, then
you need to tell the system you have done that.
That can be done by changing /etc/sysconfig/clock, so that the ZONE var is set
Then the next time someone runs timeconfig, guess what happens? Timeconfig
doesn't recognize UTC as a zone name, and sets the zone to America/New_York.
Like I say, it could be resolved alternately by un-breaking timeconfig. Believe
it or not, the world doesn't live or die by geographic zone names. If your
system supports Olsen zone names, support them all.
It could also be fixed by not having glibc fsck with /etc/localtime, or drop in
an /etc/localtime.rpmnew if you really think you need to fsck with things. I'd
love to see an explanation of why anyone would find it necessary to mess with
that; particular in cases where no zone or leap-second redefinitions have occurred.