If you're still running Red Hat or Fedora Linux systems that were being updated by the Fedora Legacy project before it was shut down, you should have received the tzdata update last year to correct the Daylight Saving Time switchover for this year. However, the updates from fedoralegacy.org only installed the new /usr/share/zoneinfo files, but didn't update /etc/localtime from that. (On RH/FC systems, /etc/localtime is a copy of the appropriate zoneinfo file, not a symbolic link.)
What I found is that for these systems (RH9, FC1-3), I needed to do the following:
cp -p /usr/share/zoneinfo/America/Winnipeg /etc/localtime
After that, I either rebooted the system, or restarted these services: syslog, crond, xinetd, sendmail, httpd. FC4 updated itself automatically last spring, so as long as you rebooted since then, the DST change should have happened without a snag. FC5-6 had the changes at release time.
I also managed to update a very old Red Hat 6.2 system by copying the zoneinfo file from a Red Hat 9 system updated by fedoralegacy.
Just thought these tips might be of help if you're supporting legacy linux boxes.
Just out of curiosity; is your system clock set to UTC?
When the system time changed, the processes on some machines seem to have picked up the time change no problem while on other machines the processes had to be restarted or the machine rebooted.
I'm just trying to figure out why that would be the case?
Anyone have any ideas?
As a side question; why the heck are the timzone files in a binary format? Wouldn't life be much easier if they were just plain text?
John
On Wed, 2007-03-14 at 11:43 -0500, Gilles Detillieux wrote:
On 03/14/2007 12:11 PM, John Lange wrote:
Just out of curiosity; is your system clock set to UTC?
No, I use local time for the RTC on all our Linux systems. Just a habit from the days when many of them dual-booted between Linux and Windows. However, I was able to tell by the timezone string that the date command put out whether the change had taken effect or not.
I imagine it would depend on whether the process had already done a localtime conversion or not. If it had done it prior to the update, it would have the old zoneinfo data cached in memory and wouldn't pick up the change without having to be restarted.
As a side question; why the heck are the timzone files in a binary format? Wouldn't life be much easier if they were just plain text?
This keeps the zoneinfo files small and very quick for the tzset() function to load and process. Plain text files would mean a bigger zoneinfo collection and a bit more time for every process to read in and "compile" the data on the first tzset(). With today's fairly bloated systems, it might not make a big difference, but when BSD first developed this scheme I'm betting it helped.
Trouble is the transition times are 32-bit integers, so the whole format will need to be scrapped or extended before 2038. Actually, the documentation ("man tzfile") says "type long", so maybe on 64-bit machines, the format will automatically extend to 64-bit if the compiler makes 64 bits the default for long ints -- it'll just mean that binary zoneinfo files will be different on 32 and 64 bit machines. However, currently the i386 and x86_64 RPMs of tzdata-2007c-1.fc6.noarch.rpm are identical "noarch" files, so I'm guessing that right now at least they're 32-bit only.
Yes, that nabbed me on my Myth box -- the only box where I really care about the time.
BTW, I wrote a quick note on how to rebuild the packages on older Fedora/RH servers:
http://ertw.com/blog/2007/03/06/upgrading-legacy-fedora-boxen-for-the-dst-ti...
Sean
On 3/14/07, Gilles Detillieux grdetil@scrc.umanitoba.ca wrote:
-
Gilles Detillieux -
John Lange -
Sean Walberg