Bug 186742

Summary: /etc/localtime not updated with new tzdata
Product: [Fedora] Fedora Reporter: Travers Carter <tcarter>
Component: tzdataAssignee: Petr Machata <pmachata>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 16CC: bookreviewer, burn, fche, kluge, lannet, mnewsome
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-28 18:20:44 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Travers Carter 2006-03-25 19:53:02 EST
Description of problem: 
/etc/localtime is not updated when tzdata is upgraded, which leads to the 
system time being incorrect. 
 
Version-Release number of selected component (if applicable): 
tzdata-2006b-2.fc4 noarch 
 
How reproducible: 
Always 
 
Steps to Reproduce: 
1. Install updated tzdata with /etc/localtime & /etc/sysconfig/clock set to an 
affected timezone 
   
Actual results: 
/etc/localtime != /usr/share/zoneinfo/Australia/Sydney 
Where /etc/sysconfig/clock contains ZONE="Australia/Sydney" 
 
Expected results: 
/etc/localtime should contain the updated version of the timezone it represents 
 
Additional info: 
This also applies to glibc-common in fedora-legacy
Comment 1 Travers Carter 2006-03-26 18:50:05 EST
/var/spool/postfix/etc/localtime is also not updated by a tzdata upgrade. 
 
Comment 2 Steffen Kluge 2006-03-26 22:36:26 EST
> /var/spool/postfix/etc/localtime is also not updated by a tzdata upgrade. 

Or any localtime file in chroot jails, such as in /var/named/etc.

The problem goes back as far as RH 7.x, at least.
Comment 3 Glen Turner 2006-03-27 02:42:18 EST
This bug has wide impact, since users in some states of Australia which have not
copied /usr/share/zoneinfo/Australia/... to /etc/localtime (eg, by running
system-config-date) since tzdata 2005m was released have the wrong time for the
coming week.

Fix is to create a RPM postinstall script which checks for ZONE in
/etc/sysconfig/clock and copies "/usr/share/zoneinfo/$ZONE" to /etc/localtime.
Comment 4 Danny Yee 2006-03-27 23:01:34 EST
The traditional approach is for /etc/localtime to be a symlink to
/usr/share/zoneinfo/$ZONE (or whatever is appropriate), but if it's supposed to
be possible to boot a machine without /usr mounted, a copy in a post-install
script in the tzdata rpm might be a better approach.
Comment 5 Petr Machata 2006-03-29 05:07:27 EST
*** Bug 186743 has been marked as a duplicate of this bug. ***
Comment 6 Petr Machata 2006-03-29 05:11:20 EST
After running system-config-date, the /etc/localtime file gets updated, so this
can be fixed on affected machines quite simply. I'll look if there is something
that prevents the file to be copied upon postinstall.
Comment 7 lannet 2006-03-29 16:04:09 EST
There is another point where this problem will occur:
/var/name/chroot/etc/locatime
Again the postinstall process for both tzdata and caching-nameserver will need
to consider this.
Comment 8 Steffen Kluge 2006-03-29 19:31:05 EST
(In reply to comment #6)
> After running system-config-date, the /etc/localtime file gets updated, so this
> can be fixed on affected machines quite simply. I'll look if there is something
> that prevents the file to be copied upon postinstall.

Apparently, Fedora Core 5 comes with a little utility /usr/sbin/tzdata-update,
that parses /etc/sysconfig/clock for the TZ variable and copies the appropriate
zone file over /etc/localtime. It gets called by the tzdata post-update scipt.

Maybe this mechanism can simply be back-ported to FC4?
Comment 9 lannet 2006-03-29 19:42:20 EST
If this previous comment is correct (I haven't checked) then it needs to also
take account of /var/named/chroot/etc/localtime where it exists, as per my
previous comment #7
Comment 10 Petr Machata 2006-04-06 09:41:18 EDT
*** Bug 186777 has been marked as a duplicate of this bug. ***
Comment 11 Petr Machata 2006-04-06 10:24:17 EDT
This can't be done. There is no guarantee that shell and coreutils are here when
tzdata %post is fired. I'd like to have this fixed, people often ask for it, but
there is no straightforward way. Wontfix.
Comment 12 Danny Yee 2006-04-07 00:06:26 EDT
OS X 10.4 Macs and Windows XP managed the switchover ok (though Windows can only
do so by breaking historical times) and Debian managed it fine, but there's no
way to fix this in Fedora Core?!?

Making /etc/localtime a symlink is better than having the time break.  I guess
I'll have to go around and do that by hand...
Comment 13 lannet 2006-04-07 00:47:04 EDT
(In reply to comment #11)
> This can't be done. There is no guarantee that shell and coreutils are here when
> tzdata %post is fired. I'd like to have this fixed, people often ask for it, but
> there is no straightforward way. Wontfix.

If this is the case, then surely a warning would be in order.  tzdata gets
regularly updated for many global situations and this is too important to just
let slide without either fixing or warning.
Comment 14 Frank Ch. Eigler 2012-03-28 12:34:36 EDT
If the showstopper to this bug being fixed is: "There is no guarantee that shell and coreutils are here when tzdata %post is fired." (and presumably the same for glibc-common), then let's think of another solution.  A cron job?  A test for the presence of the shell/coreutils before endavouring to update from within %post?  (After all, this is an issue only for updates, not for initial installs.)
Comment 15 Petr Machata 2012-03-28 18:20:44 EDT
glibc has a hook responsible for updating tzdata.  AFAI recall, it's written in such a way that it doesn't need even glibc, much less coreutils.  This should now be taken care of.

Actually, now that we have UsrMove in effect and /usr can't be mounted separately anymore, there's no reason not to make /etc/localtime a symlink.