| Summary: | stale localtime file after sys-libs/timezone-data update | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Paul B. Henson <henson> |
| Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | brant, chris, jkt, kolesen.a, m.debruijne, nathan, ooblick, r.goates, stefano.varesi |
| Priority: | Low | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Paul B. Henson
2006-03-28 12:29:38 UTC
Perhaps it would make sense to make an eselect module for this? Eselect could then store the selected timezone in /etc/eselect/ and sys-libs/timezone-data could instruct the user to rerun the eselect command for re-copying the file? Note: I've never really used eselect, it was just an idea that occured to me. I think it would be better if sys-libs/timezone-data automatically copied the appropriate new time zone file into place rather than requiring explicit action by the user. Perhaps the time zone configuration could be added into /etc/rc.conf or /etc/conf.d/clock, and one of the bootup scripts could automatically copy the appropriate time zone into place, either unilaterally or only if the current copy is different from the authoritative copy. http://www.nightsys.net/find_localtime my opinion is to use something like that, to find and copy a tz over...rather than require a config option. PHP >5.1 requires a config option for date.timezone for it to be calculated sanely, and i almost forgot myself till i noticed everything out by an hour (DST issue, irrelevant to this problem). it wouldnt be easy to have everybody update their TZ, and actually make sure they do it... id be steering for something to check what TZ their using now, and copy an equivalent localtime at the end of src_install() or something... feedback? (my only solution atm is going on checksum of the old version's tz zoneinfo binaries, as i dont think the exact TZ eg. Australia/Brisbane is stored in the binaries. you can choose a better hash if you prefer) We use make.conf for things like ALSA_CARDS and VIDEO_CARDS, so maybe we should use it for TIMEZONE, too? is something like TIMEZONE a little too critical to have there? without stuff like ALSA_CARDS and VIDEO_CARDS, a system still boots... you could maybe do it with a die in the timezone-data ebuild to fail if TIMEZONE isnt specified, and tell ppl to set their TZ there or whatever...that would probably work. I have a better idea yet, why do we even need /etc/localtime? Let's do away with it. Anything that even looks at that file (read: does not have a TZ env. var. set) should probably be using UTC anyway.* * Wild assumption alert. *** Bug 143296 has been marked as a duplicate of this bug. *** Isn't this all causing more pain than just returning to the symlink - Is there any evidence that the confusion caused by incorrect timestamps on a /usr mount failure is greater than the confusion caused by incorrect timestamps when DST dates change? Either way someone is going to be confused - but if your /usr partition has failed you've got a whole lot of other problems to be looking at too. I recently installed the new sys-libs/timezone-data, and as expected, have a stale /etc/localtime: # ls -l /etc/localtime -rw-r--r-- 1 root root 1017 Mar 20 07:03 /etc/localtime # ls -l /usr/share/zoneinfo/PST8PDT -rw-r--r-- 1 root root 837 Jul 12 13:36 /usr/share/zoneinfo/PST8PDT This doesn't really seem like a hard problem, there are a variety of reasonably appropriate solutions available, whoever is in charge of this just needs to pick one. Personally, I think the time zone should be configured somewhere, it doesn't matter where (/etc/conf.d/clock seems appropriate, or /etc/conf.d/rc, or whatever), and the timezone ebuild should automatically copy the configured time zone to /etc/localtime as a post install action. Any objections to this approach? Looking at the change log for syslibs/timezone-data, it seems Mike Frysinger <vapier@gentoo.org> is the most active developer on that ebuild. I'm not sure if he's seen this bug, anyone paying attention this happen to know him and could perhaps ask him to follow up? yep ive spoken to Mike about this a few months back...he knows the issue is there and his response to me was if i find a good solution put it to him and he will commit :) im all for the method of trying to read the localtime file somehow to determine which tz it is, and use that to determine which new localtime to copy over...configuration is good and all but its one more thing for ppl to keep up to date/screw with :) While it would be nice for things to just magically work, I think that approach perhaps might be overengineering this problem. I'm not sure how easy it would be to determine from the binary file itself what time zone it represents. Before the upgrade, I suppose you could do a brute force comparison between the /etc/localtime file and all of the files in /usr/share/zoneinfo. After the upgrade, that would no longer work. In particular, this approach might be problematic for all of the people that already have an out-of-synchronization /etc/localtime file, which is probably most people in the US at least. You already have a time zone configuration step as part of an installation, I don't really see why it is more hassle to edit a TZ variable in a configuration file than to copy a file as the current instructions indicate. It's not like you change your time zone on a regular basis, typically once it is configured you don't touch it again. Adding a configuration variable seems like an easy and reliable mechanism to resolve this issue quickly. Unless there's something in the binary file itself (which I don't think there is) to uniquely identify what time zone it represents, any automatic attempt to identify it would be at best a heuristic. http://www.nightsys.net/find_localtime ...good point about if ppl already have an out of date tz though, doing a bruteforce comparison there wouldnt work. im pretty sure most of the info used to accurately identify which tz file is used is stripped when the tz file is compiled into a binary, only the necessary info is left from there i think (could be wrong, just guessing here). i spose a config option wouldnt be too bad for new users, but what would we do for existing installation users? i know what ppl are like, theyll forget to change it or something, youd probly have to have it defaulted somewhere in baselayout so that its updated on update maybe... unless you had a separate file in conf.d for timezone related stuff, do it in tzdata then... and in that case, what do you default it to? :) I don't recall the author, but I saw a quote once in a forum post -- "Gentoo is not your Grandma's Linux distribution"... Whatever solution is implemented, there will be sufficient notification via ewarnings in the time zone ebuild, or changes in configuration files that should be noticed if someone is appropriately updating them after upgrading. I'm really not that concerned about somebody that pays so little attention to upgrading their system that they screw this up. I say we make it a configuration variable, and the timezone ebuild will generate a warning or even a fatal error if it is not set (if it is set, the timezone ebuild will copy the appropriate one over during install). So if somebody forgets to configure it during a configuration file update, they will definitely catch it the next time they try to update the timezone package. yea something like that would probly work... Can you follow up with Mike then and see what he thinks? Presumably he will update the timezone ebuild as necessary, who do we need to involve to update baselayout with a new configuration variable? Any progress on this? 2007 is getting closer :)... I do think the most convenient way would be to let the user set the timezone e.g. in rc.conf or conf.d/rc. TIMEZONE=foo and then doing diff /etc/localtime /usr/share/zoneinfo/<deduced_tz_file> &>/dev/null if [[ $? != 0 ]] ; then echo "/etc/localtime doesn't match /usr/share/zoneinfo/<deduced_tz_file>." echo "Copying <deduced_tz_file> to /etc/localtime cp ... fi within an timezone init script should work. emerge --config would simply be pausing and starting the init script again and if someone forgets about it, it would happen automatically on the next boot. The above is pseudo code of course, not checking for if /usr is mounted/available, file existence etc.. /etc/rc.conf seems like the sanest place ... and that idea doesnt sound to shabby start a thread on gentoo-dev i guess I've discovered another problem with the potentially stale copy... (Sun's) Java has its own version of the zoneinfo database, so it doesn't depend directly on the contents of /usr/share/zoneinfo. However, when it needs to work out the system default timezone, it does look at /etc/localtime. If it's a sym-link, it uses the target of the sym-link as the name of the timezone, which it then looks up in its own database. This works. If it's a copy, then it can't work out the timezone directly because the name isn't contained in the file (this is the real flaw). To get round this, it compares the size and then contents of /etc/localtime with all files it can find in /usr/share/zoneinfo. If it finds a match, then it uses the name of that file as the timezone and looks it up in its own database. This mechanism fails if /etc/zoneinfo is a stale copy. Obviously, the work around is to go back to using a sym-link (and it's more efficient). Perhaps the install guide should revert to recommending a sym-link unless you have a specific need not to mount /usr. While doing a fresh install on a new AMD64 system using install-amd64-minimal-2006.1, after chroot'ing to /mnt/gentoo I found the entire /usr/share/zoneinfo directory to be missing. Some search on the forum gave me the tip to emerge sys-libs/timezone-data so I have the directory now. Just thought I should mention it. /etc/conf.d/clock in new baselayouts record the TIMEZONE and the timezone-data package keys off of this to update /etc/localtime accordingly For completeness, you could add the possibility to reset /etc/localtime without reinstalling the entire sys-libs/timezone-data ebuild.
This could be achieved using "emerge --config" feature renaming the pkg_postinst() function to pkg_config() and adding the function
pkg_postinst() {
pkg_config
}
to the ebuild.
In this way /etc/localtime would be correctly set on ebuild installation, but the user could also get a correct /etc/localtime even if he later changes the TIMEZONE variable in /etc/conf.d/clock, by executing "emerge --config sys-libs/timezone-data". A message about this feature could also be added in the comments in /etc/conf.d/clock and/or in the ebuild's einfos, just to notify the user about that.
Do you think this can be useful?
that sounds like a good idea ... ive done it in 2007a, thanks (In reply to comment #23) > that sounds like a good idea ... ive done it in 2007a, thanks > Well, I am not 100% sure, but I think the following sequence did not update /etc/localtime: Emerged timezone-info (version 2007c) figured out /etc/conf.d/clock did not have TIMEZONE set, set it to CST6CDT Emerged again timezone-info The time was not updated. Only after changing /etc/localtime to a symlink the sytem got the correct time... I will try to reproduce it, but won't happen until this weekend... you can test the process manually by just running `emerge --config timezone-data` *** Bug 389091 has been marked as a duplicate of this bug. *** |
