Bug 321911 - /etc/localtime is not updated when tzdata is updated
/etc/localtime is not updated when tzdata is updated
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: tzdata (Show other bugs)
5.0
All Linux
low Severity low
: ---
: ---
Assigned To: Petr Machata
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-07 06:08 EDT by Alain D D Williams
Modified: 2015-05-04 21:33 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-10 20:10:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alain D D Williams 2007-10-07 06:08:33 EDT
Description of problem:
/etc/localtime is a copy of a file in /usr/share/zoneinfo/, this copy is made
when the system is installed. This file is not updated when an updating tzdata
RPM is installed - as happened recently.

Would it not be better to make this file a symbolic link, then it always reads
correctly, this is what Debian does.
Alternatively the tzdata postinstall script could use ZONE in
/etc/sysconfig/clock to copy up the latest version.
Comment 1 Petr Machata 2007-10-08 10:51:27 EDT
Update of /etc/localtime is taken care of by glibc trigger.  How do you know
that the update has not been performed?

We can't make /etc/localtime a symlink, because /usr/ can be mounted separately,
and glibc needs to know zoneinfo even then.
Comment 2 Alain D D Williams 2007-10-08 11:00:28 EDT
I thought that that might be the reason, so why not have the postinstall script
in the updating RPM copy up the latest version ? Would that cause problems with
rpm --verify ?
Comment 3 Petr Machata 2007-10-08 11:21:01 EDT
tzdata package is installed very early, even before libc, and certainly before
shell.  So you can't just use cp to update /etc/localtime in postinstall.  You
probably could create a binary that does the same, and link it statically, but
then tzdata would lose their noarch status.  That's not problem on itself, but
it makes little sense to do that just for update script.

Comment 4 Petr Machata 2007-10-10 10:51:42 EDT
So, why do you think that the update of /etc/localtime has not been performed? 
Have you compared /etc/localtime and the file matching your zone in some way? 
Or did one of the applications just fail to have synced time?  If that is the
case, which one -- it may well be bug in that application (e.g. evolution and
java use their own copy of tzdata, IIRC).

This should not happen during routine update, about the only scenario that I can
imagine is update from old-ish version of RHEL-4, where the trigger has not yet
been available, and failure of rpm to run the trigger during subsequent update
of glibc.
Comment 5 Alain D D Williams 2007-10-10 11:00:00 EDT
I noticed new /usr/share/zoneinfo/Europe/London files coming down (eg a few days
ago), but the date on /etc/localtime is never changed. I don't know how often I
would expect it to change, but I would expect to see an update.

I have not had any application problems.
Comment 6 Petr Machata 2007-10-10 11:46:17 EDT
Hmm, that is strange, London has not been changed in ages... But let's see this
scenario: new tzdata arrived via latest erratum
http://rhn.redhat.com/errata/RHEA-2007-0928.html

What happens is that London zoneinfo file gets updated, because it's overwritten
from new tzdata package.  But it's contents didn't chagne.  Now trigger in glibc
is written in such a way that it doesn't update /etc/localtime when its zone
contents didn't change, so it skips the update, and /etc/localtime seems to be
outdated.

Does it make a sense?
Comment 7 Alain D D Williams 2007-10-10 13:54:32 EDT
Ahah - so you are saying that if it had changed, the copy in /etc/localtime
would have been updated. If so - no problem.

Sorry for raising a non issue.
Comment 8 Petr Machata 2007-10-10 20:10:53 EDT
Glad to be of help.

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