hey all,
I perused my inbox looking for this subject, but not finding it, -anything I need to keep my server farm of 60 centos servers (that all run ntp) going smoothly during this next time change on March 11?
I noticed on the w2k side my IT staff have to do some scrambling, heh, but that's expected.
Any action required?
-karlski
I perused my inbox looking for this subject, but not finding it, -anything I need to keep my server farm of 60 centos servers (that all run ntp) going smoothly during this next time change on March 11?
I noticed on the w2k side my IT staff have to do some scrambling, heh, but that's expected.
Any action required?
For centos4, no. The update has been in centos for a while now. For centos3, run 'yum update' as the update was (until recently) in the fastrack repository. It is now in the general update repo, and available mainstream.
For centos2, I'm not sure. I don't have any systems currently running it.
You can test the distros by using 'zdump -v /etc/localtime | grep 2007' and verify that the dates are correct.
On Mon, 5 Mar 2007, Jim Perrin wrote:
For centos2, I'm not sure. I don't have any systems currently running it.
I looked for txdata sources for 2.1 updates today, and did not see the file. If someone is still using 2.1 and feels a need, please open a bug. http://bugzilla.centos.org/
For backports into RHL series, I hit a change in cp when backbuilding to RHL 6.0 which I have not yet solved.
-- Russ Herrold
R P Herrold wrote:
On Mon, 5 Mar 2007, Jim Perrin wrote:
For centos2, I'm not sure. I don't have any systems currently running it.
I looked for txdata sources for 2.1 updates today, and did not see the file. If someone is still using 2.1 and feels a need, please open a bug. http://bugzilla.centos.org/
For backports into RHL series, I hit a change in cp when backbuilding to RHL 6.0 which I have not yet solved.
http://mirror.centos.org/centos/2.1/updates/noarch/tzdata-2006m-3.el2_1.noar...
its in noarch not i386 as that RPM is just data files. in later releases, I think noarch was replicated into the other architectures to reduce the confusion.
R P Herrold wrote:
On Mon, 5 Mar 2007, Jim Perrin wrote:
For centos2, I'm not sure. I don't have any systems currently running it.
I looked for txdata sources for 2.1 updates today, and did not see the file. If someone is still using 2.1 and feels a need, please open a bug. http://bugzilla.centos.org/
For backports into RHL series, I hit a change in cp when backbuilding to RHL 6.0 which I have not yet solved.
oh, forgot to add...
for RHL 6, 7, and 9 boxes (got some old iron in coloc centers doing free-nonprofit things that aren't convenient to rebuild from scratch), I've just tarred up the /usr/share/zoneinfo from an updated system, and untarred it onto the legacy systems, and its seemingly works.
after doing teh untar, you must then
cp /usr/share/zoneinfo/<yourtimezone> /etc/localtime
zdump -v PST8PDT |grep 2007 should then show the corrected DST dates.
Karl R. Balsmeier wrote:
Any action required?
Perhaps a naive question, but anyway:
Let's assume I'm running CentOS4 or RHEL4 and I updated it to tzdata-2007c. Before that, it was using an old tzdata package that did not have the US DST '07 patches.
Do I have to restart any service? ntpd? How is the system going to figure out there's a new tzdata package installed? I guess _something_ needs to poll those files regularly and, if there's a change like the DST '07 patch, decide to make the change earlier.
Thanks,
On Wed, Mar 07, 2007 at 09:59:02AM -0800, Florin Andrei wrote:
Karl R. Balsmeier wrote:
Any action required?
Perhaps a naive question, but anyway:
Let's assume I'm running CentOS4 or RHEL4 and I updated it to tzdata-2007c. Before that, it was using an old tzdata package that did not have the US DST '07 patches.
Do I have to restart any service? ntpd?
Yes.
Any process started before you update /etc/localtime (and ensure that got updated correctly; it may not have been) may need to be restarted if it uses zoneinfo information. Two obvious ones are syslog and cron. The safest solution is to reboot.
One way to check that localtime is correct (using /bin/sh or similar)
. /etc/sysconfig/clock cmp /usr/share/zoneinfo/$ZONE /etc/localtime
If it reports differences the cp /usr/share/zoneinfo/$ZONE /etc/localtime
and then reboot.
See also http://kbase.redhat.com/faq/FAQ_79_9950.shtm
Once updated, a restart of all the applications relying on /etc/localtime is required. The easiest solution would be to reboot the machine in order to ensure that all the applications are properly updated.
Use following command to check. you can login as any user.
/usr/sbin/zdump -v /etc/localtime | grep 2007
--- Stephen Harris lists@spuddy.org 說：
On Wed, Mar 07, 2007 at 09:59:02AM -0800, Florin Andrei wrote:
Karl R. Balsmeier wrote:
Any action required?
Perhaps a naive question, but anyway:
Let's assume I'm running CentOS4 or RHEL4 and I
updated it to
tzdata-2007c. Before that, it was using an old
tzdata package that did
not have the US DST '07 patches.
Do I have to restart any service? ntpd?
Yes.
Any process started before you update /etc/localtime (and ensure that got updated correctly; it may not have been) may need to be restarted if it uses zoneinfo information. Two obvious ones are syslog and cron. The safest solution is to reboot.
One way to check that localtime is correct (using /bin/sh or similar)
. /etc/sysconfig/clock cmp /usr/share/zoneinfo/$ZONE /etc/localtime
If it reports differences the cp /usr/share/zoneinfo/$ZONE /etc/localtime
and then reboot.
See also http://kbase.redhat.com/faq/FAQ_79_9950.shtm
Once updated, a restart of all the applications relying on /etc/localtime is required. The easiest solution would be to reboot the machine in order to ensure that all the applications are properly updated.
--
rgds Stephen _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
___________________________________________________ 您的生活即時通 － 溝通、娛樂、生活、工作一次搞定！ http://messenger.yahoo.com.tw/
Stephen Harris wrote:
Any process started before you update /etc/localtime (and ensure that got updated correctly; it may not have been) may need to be restarted if it uses zoneinfo information. Two obvious ones are syslog and cron. The safest solution is to reboot.
OK. So let me see if I get this right:
# ls -l /etc/localtime -rw-r--r-- 1 root root 1017 May 5 2006 /etc/localtime # rpm -qf /etc/localtime glibc-2.3.4-2.19
The system also has tzdata-2007c
So /etc/localtime hasn't been touched in a long time, but tzdata has been updated recently. That means, all daemons that haven't been restarted since /etc/localtime has been updated, need a restart. Right?
By the way, the system passes the empirical US DST '07 test (there's a 1 hour difference between the two outputs - if they were identical that would be a problem):
# date --date="Mar 25 15:00:00 UTC 2006" Sat Mar 25 07:00:00 PST 2006 # date --date="Mar 25 15:00:00 UTC 2007" Sun Mar 25 08:00:00 PDT 2007
On Wed, Mar 07, 2007 at 10:22:43AM -0800, Florin Andrei wrote:
Stephen Harris wrote:
Any process started before you update /etc/localtime (and ensure that got updated correctly; it may not have been) may need to be restarted if it uses zoneinfo information. Two obvious ones are syslog and cron. The safest solution is to reboot.
OK. So let me see if I get this right:
# ls -l /etc/localtime -rw-r--r-- 1 root root 1017 May 5 2006 /etc/localtime # rpm -qf /etc/localtime glibc-2.3.4-2.19
The system also has tzdata-2007c
So /etc/localtime hasn't been touched in a long time, but tzdata has been updated recently. That means, all daemons that haven't been
You should compare it to your real zone file. It's possible that it may be correct if the later zone files didn't change anything.
On my machine (a real RH4.4 machine at work) localtime is older than the zone file but the contents are correct:
$ ls -l /etc/localtime /usr/share/zoneinfo/US/Eastern -rw-r--r-- 1 root root 1267 Feb 16 13:18 /etc/localtime -rw-r--r-- 3 root root 1267 Feb 27 10:22 /usr/share/zoneinfo/US/Eastern $ cmp /etc/localtime /usr/share/zoneinfo/US/Eastern $
restarted since /etc/localtime has been updated, need a restart. Right?
Right. If your box hasn't been rebooted since May 5th 2006 then there's a good chance that syslog and cron and maybe others need restarting. If your localtime file is out of date (check it!) then update it and restart the affected processes.
By the way, the system passes the empirical US DST '07 test (there's a 1 hour difference between the two outputs - if they were identical that would be a problem):
# date --date="Mar 25 15:00:00 UTC 2006" Sat Mar 25 07:00:00 PST 2006 # date --date="Mar 25 15:00:00 UTC 2007" Sun Mar 25 08:00:00 PDT 2007
Also note it says PDT rather than PST; a give away :-)
However, that's a new process and so read /etc/localtime as you ran it. Processes started _before_ the localtime update may have read an older version and so have old data.
The main America DST fix was done a long time ago and so it's very likely that you have a DST compliant system for your machine already in place. Later tzdata updates have been due to Indiana, Australia, Brazil and so on and so may not have any impact on you.
If your machine has not rebooted sunce May 2006 then I recommend you do so. Otherwise it's likely you will be OK.
Florin Andrei wrote:
Stephen Harris wrote:
Any process started before you update /etc/localtime (and ensure that got updated correctly; it may not have been) may need to be restarted if it uses zoneinfo information. Two obvious ones are syslog and cron. The safest solution is to reboot.
OK. So let me see if I get this right:
# ls -l /etc/localtime -rw-r--r-- 1 root root 1017 May 5 2006 /etc/localtime # rpm -qf /etc/localtime glibc-2.3.4-2.19
I've found the rpm updates for tzdata don't always update localtime. safest is to
cp /usr/zoneinfo/YOURTIMEZONE /etc/localtime
then reboot
The system also has tzdata-2007c So /etc/localtime hasn't been touched in a long time, but tzdata has been updated recently. That means, all daemons that haven't been restarted since /etc/localtime has been updated, need a restart. Right?
By the way, the system passes the empirical US DST '07 test (there's a 1 hour difference between the two outputs - if they were identical that would be a problem):
# date --date="Mar 25 15:00:00 UTC 2006" Sat Mar 25 07:00:00 PST 2006 # date --date="Mar 25 15:00:00 UTC 2007" Sun Mar 25 08:00:00 PDT 2007
the US timezone changes triggered by the Energy Plunder Act of 2005 have been in every tzdata since 2006a (and maybe earlier)
On Wed, Mar 07, 2007 at 01:07:11PM -0500, Stephen Harris wrote:
Any process started before you update /etc/localtime (and ensure that got updated correctly; it may not have been) may need to be restarted if it uses zoneinfo information. Two obvious ones are syslog and cron.
For what it's worth, I'm not sure syslog really cares. It seems to log based on the timezone of the logging process.
On Wed, Mar 07, 2007 at 01:44:25PM -0500, Matthew Miller wrote:
On Wed, Mar 07, 2007 at 01:07:11PM -0500, Stephen Harris wrote:
Any process started before you update /etc/localtime (and ensure that got updated correctly; it may not have been) may need to be restarted if it uses zoneinfo information. Two obvious ones are syslog and cron.
For what it's worth, I'm not sure syslog really cares. It seems to log based on the timezone of the logging process.
I think the kernel logging side (klogd) may care. They're started as part of the same init script.
On Wed, Mar 07, 2007 at 01:47:12PM -0500, Stephen Harris wrote:
Any process started before you update /etc/localtime (and ensure that got updated correctly; it may not have been) may need to be restarted if it uses zoneinfo information. Two obvious ones are syslog and cron.
For what it's worth, I'm not sure syslog really cares. It seems to log based on the timezone of the logging process.
I think the kernel logging side (klogd) may care. They're started as part of the same init script.
Sidetrack: hey, look, from the changelog of the (unreleased upstream, several years old) 1.4.2 version of syslog:
- Always log with syslogd's timezone and locale
wouldn't that be nice!
Forget for a moment the fact that one should not override an RPM package with files from a tarball :-) but look at this article:
http://www.linux-watch.com/news/NS6300294422.html
It seems like the author assumes that /etc/localtime is already a symlink. Otherwise what would be the point in recommending to update tzdata but don't do anything about /etc/localtime?
So probably the article (posted on Slashdot, no less) is wrong from the perspective of a Red Hat / CentOS user on two counts: - the tzdata update method is bad - /etc/localtime is not a symlink on RHEL/CentOS so the method is incomplete
Florin Andrei wrote:
Forget for a moment the fact that one should not override an RPM package with files from a tarball :-) but look at this article:
http://www.linux-watch.com/news/NS6300294422.html
It seems like the author assumes that /etc/localtime is already a symlink. Otherwise what would be the point in recommending to update tzdata but don't do anything about /etc/localtime?
So probably the article (posted on Slashdot, no less) is wrong from the perspective of a Red Hat / CentOS user on two counts:
- the tzdata update method is bad
- /etc/localtime is not a symlink on RHEL/CentOS so the method is
incomplete
A quick check for your default setting should be: date -d "March 12" and see if the time zone displayed is the dst version. Of course if you have a TZ= setting in your invironment, that zone file will be used instead of the default localtime.
Florin Andrei wrote:
Forget for a moment the fact that one should not override an RPM package with files from a tarball :-) but look at this article:
http://www.linux-watch.com/news/NS6300294422.html
It seems like the author assumes that /etc/localtime is already a symlink. Otherwise what would be the point in recommending to update tzdata but don't do anything about /etc/localtime?
So probably the article (posted on Slashdot, no less) is wrong from the perspective of a Red Hat / CentOS user on two counts:
- the tzdata update method is bad
- /etc/localtime is not a symlink on RHEL/CentOS so the method is
incomplete
if you read back through the release notes of glibc and tzdata, it was determined ages ago that using a symlink from /etc/localtime to /usr/share/zoneinfo/<whatever> wasn't a good idea, /usr or /usr/share may be a seperate file system and not initially mounted
Myself, I'm wishing our global operations all ran in UTC and -screw- localtime.
of course, I'm also wishing DST would go the way of the steamtrain.
-
Florin Andrei -
Jim Perrin -
John R Pierce -
Karl R. Balsmeier -
Les Mikesell -
Matthew Miller -
mcclnx mcc -
R P Herrold -
Stephen Harris