Greg Ercolano wrote:
There's probably similar updates for Windows and Linux; I don't know
what they are at this time. (Feel free to follow up to this thread)
LINUX INFORMATION
-----------------
I just updated linux, and I can tell you that you'll need to,
at least:
RESTART THE RUSH DAEMON AFTER MAKING TIMEZONE CHANGES
..or even better, reboot the box, as my tests show that other
daemons may also be affected.
According to my tests, the rushd daemon's C/C++ libraries *cached*
the old timezone info, so even though the timezone files were updated,
the daemon's C library had already cached the timezone info in memory;
restarting the daemon was necessary to flush that cache.
I was able to prove the C library's behavior by writing a small
C program that runs ctime(3) in a while loop.. basically:
---- snip
#include <stdio.h>
#include <unistd.h>
#include <time.h>
int main(int argc, char**argv) {
while ( 1 ) {
long lt; time(<);
fprintf(stderr, "ctime: %s", ctime(<));
sleep(1);
}
}
---- snip
By starting this program /before/ applying the patch, and letting
it continue to run as I applied the patches, I noticed it continued
to report the WRONG time (eg. 03/11/07 2am instead of 03/11/07 3am)
It's only when I restarted the program, it showed correct times.
To me, this test /proves/ a reboot is needed should be done, even though
some websites say this shouldn't be necessary. I beg to differ, based on
the above test, to ensure daemons like crond/atd/syslogd show correct times.
I did several tests where I warped the clock to 1:55am 03/11/07,
and watched the behavior of the daemon's reporting time/dates
as it ran through the Witching Hour. The daemon still showed standard time
info after the 2am -> 3am jump; eg. 'rush -ljf' for newly submitted jobs
still showed in standard time. But when I restarted the daemon, the same
jobs that had been showing incorrect times now showed correct start time info.
Because of this, I'd advise you REBOOT after making timezone changes,
as likely all daemons (crond, atd, etc), not just rush, will have
cached timezone info.
SEEING THE DST PROBLEM IN LINUX
-------------------------------
It's important to be able to see the problem without warping the clock.
Under linux, whether its redhat 6.1 or Fedora 3, you can do this simple
test.
If you're *not* up to date with the DST fix (eg. for the PST time zone),
you will see:
# zdump -v PST8PDT | grep 2007
PST8PDT Sun Apr 1 09:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 PST isdst=0 gmtoff=-28800
PST8PDT Sun Apr 1 10:00:00 2007 UTC = Sun Apr 1 03:00:00 2007 PDT isdst=1 gmtoff=-25200
PST8PDT Sun Oct 28 08:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 PDT isdst=1 gmtoff=-25200
PST8PDT Sun Oct 28 09:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 PST isdst=0 gmtoff=-28800
..the "Apr 1" and "Oct 28" entries shows I have the old info.
When the DST patch is applied correctly, the zdump command should instead show,
again, for PST:
# zdump -v PST8PDT | grep 2007
PST8PDT Sun Mar 11 09:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 PST isdst=0 gmtoff=-28800
PST8PDT Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 PDT isdst=1 gmtoff=-25200
PST8PDT Sun Nov 4 08:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 PDT isdst=1 gmtoff=-25200
PST8PDT Sun Nov 4 09:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 PST isdst=0 gmtoff=-28800
PATCHING MY LINUX MACHINES FOR DST
----------------------------------
Just FYI, here's the one way I chose to update my linux boxes.
These same steps worked on my old, old redhat 6.1 machine, and my more recent
Fedora 3 machine. The paths and commands were all the same.
There are probably easier ways (yum, rpms, etc), but I wanted to know
what files were being modified for test purposes.
I updated my fedora3 machine by downloading tzdata2007c.tar.gz from
from: ftp://elsie.nci.nih.gov/pub/
..and in my case, saved it to /tmp and installed for the PST timezone with:
# mkdir /tmp/zoneinfo ; cd /tmp/zoneinfo; tar xfz /tmp/tzdata2007c.tar.gz
# zic -d /tmp/zoneinfo northamerica
# /bin/cp -p /tmp/zoneinfo/PST8PDT /usr/share/zoneinfo/PST8PDT
# /bin/cp -p /tmp/zoneinfo/PST8PDT /etc/localtime
# /bin/cp -p /tmp/zoneinfo/America/Los_Angeles /usr/share/zoneinfo/America/Los_Angeles
Note: you may want to save your previous files the above /bin/cp commands
overwrite, in case you want to switch back and forth.
After doing this, running the above zdump command showed the correct
Mar 11/Nov 4 results.
--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)
|