Bug 199792

Summary: glibc errata updates modify system time zone
Product: Red Hat Enterprise Linux 3 Reporter: Jefferson Ogata <jefferson.ogata>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-07-22 06:39:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jefferson Ogata 2006-07-22 02:16:18 UTC
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 06:39:46 UTC
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 06:55:09 UTC
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.