Red Hat Bugzilla – Full Text Bug Listing
|Summary:||/etc/localtime not updated with new tzdata|
|Product:||[Fedora] Fedora||Reporter:||Travers Carter <tcarter>|
|Component:||tzdata||Assignee:||Petr Machata <pmachata>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Version:||16||CC:||bookreviewer, burn, fche, kluge, lannet, mnewsome|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-03-28 18:20:44 EDT||Type:||---|
|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.