Bug 199792 - glibc errata updates modify system time zone
glibc errata updates modify system time zone
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-21 22:16 EDT by Jefferson Ogata
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-22 02:39:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jefferson Ogata 2006-07-21 22:16:18 EDT
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.

How reproducible:
100%

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
/usr/share/zoneinfo.
  
Actual results:
System localized time zone modified; in my case all systems get moved from UTC
to the wrong zone.

Expected results:
System localized time zone should not be modified.

Additional info:
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.
Comment 1 Jakub Jelinek 2006-07-22 02:39:46 EDT
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
to UTC:
ZONE="UTC"
Comment 2 Jefferson Ogata 2006-07-22 02:55:09 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.