Hi list,
Ever since the change to BST here in the UK (GMT to GMT+1) the clocks on all my Centos 4.4 servers are 1 hour slow.
Timezone is set to Europe/London, and I've tried with and without "System clock uses UTC". If I disable NTP and set the time manually, then restart NTP, the time goes back 1 hour. Running `date` reports "Wed Mar 28 14:59:04 BST" - so it knows about the BST change, but that time is 1 hour slow - it's really 15:59 BST.
All servers are fully patched - tzdata is at 2007d-1.el4
Any ideas anyone?
Cheers, Andy.
Andy Wright wrote:
Hi list,
Ever since the change to BST here in the UK (GMT to GMT+1) the clocks on all my Centos 4.4 servers are 1 hour slow.
Good morning, Andy
Use /sbin/clock to check the time on your system's hardware clock. ntp and date will change the time on your OS but not necessarily on your hardware.
You can change the hardware clock by using the date command to change the time and then typing "/sbin/clock -w" to write the time to hardware.
W.
Good afternoon - see, I told you the time was out ;-)
It's the system time that's an hour out - the hardware clock was set to the correct local time (I'd done this manually earlier).
Here's what I've tried -
stop ntpd and chkconfig it off
used date -s to set correct local time used clock -w to write to hardware clock
reboot (just in case !)
date and clock now both report the correct local time
start ntpd
clock is still correct, but date has gone back an hour
Confused !
Andy.
Good morning, Andy
Use /sbin/clock to check the time on your system's hardware clock. ntp and date will change the time on your OS but not necessarily on your hardware.
You can change the hardware clock by using the date command to change the time and then typing "/sbin/clock -w" to write the time to hardware.
W.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
In article 460A8DB6.2060100@eltofts.homelinux.com, Andy Wright centos@eltofts.homelinux.com wrote:
date and clock now both report the correct local time
start ntpd
clock is still correct, but date has gone back an hour
What ntp server(s) are you syncing to?
What is the output of "ntpq -pn"?
Cheers Tony
Andy Wright wrote:
Good afternoon - see, I told you the time was out ;-)
It's the system time that's an hour out - the hardware clock was set to the correct local time (I'd done this manually earlier).
Here's what I've tried -
stop ntpd and chkconfig it off
used date -s to set correct local time used clock -w to write to hardware clock
reboot (just in case !)
date and clock now both report the correct local time
start ntpd
clock is still correct, but date has gone back an hour
Confused !
Andy.
Good morning, Andy
Use /sbin/clock to check the time on your system's hardware clock. ntp and date will change the time on your OS but not necessarily on your hardware.
You can change the hardware clock by using the date command to change the time and then typing "/sbin/clock -w" to write the time to hardware.
Some, but not all, of my systems (not particularly CentOS) didn't handle comming off DST here at all well.
I fixed them by stopping ntp, running ntpdate pool.net.org hwclock -w then restarting ntp. and finally, by hoping all this is sorted out by next time:-)
On Wed, 2007-03-28 at 10:14 -0400, Winter wrote:
Andy Wright wrote:
Hi list,
Ever since the change to BST here in the UK (GMT to GMT+1) the clocks on all my Centos 4.4 servers are 1 hour slow.
Good morning, Andy
Use /sbin/clock to check the time on your system's hardware clock. ntp and date will change the time on your OS but not necessarily on your hardware.
You can change the hardware clock by using the date command to change the time and then typing "/sbin/clock -w" to write the time to hardware.
W.
<snip sig stuff>
FYI, you can also use /sbin/hwclock (man hwclock) which has a number of options for investigation (I suspect /sbin/clock is a "wrapper" for hwclock, although I've never used /sbin/clock or read its docs/man pages).
Hwclock will allow you to determine wheter it's the hardware clock or OS clock which is error or correct. IIRC, the OS clock is stored in the hardware clock at shutdown, meaning the "new" value is in the HW clock at reboot.
HTH -- Bill
Ralph Angenendt wrote:
Ralph
Does the system clock run on UTC time?
Hi Ralph,
the hardware clock is set to the correct local time - one of the servers uses the rtc to switch itself on at 1am to receive offsite backups so I prefer this not to be UTC time.
I have disabled "System clock uses UTC" and rebooted, but as soon as I run ntpd the system backs jumps back an hour.
Andy.
Andy Wright wrote:
Ralph Angenendt wrote:
Ralph Does the system clock run on UTC time?
Hi Ralph,
the hardware clock is set to the correct local time - one of the servers uses the rtc to switch itself on at 1am to receive offsite backups so I prefer this not to be UTC time.
I have disabled "System clock uses UTC" and rebooted, but as soon as I run ntpd the system backs jumps back an hour.
Andy.
Two really dumb questions: 1. Have you updated the tzdata package? Here's the output of rpm -qi tzdata on my system:
[pag@sempron zoneinfo]$ rpm -qi tzdata Name : tzdata Relocations: (not relocatable) Version : 2007d Vendor: CentOS Release : 1.el4 Build Date: Sat 24 Mar 2007 02:46:37 AM MDT Install Date: Sun 25 Mar 2007 10:17:19 PM MDT Build Host: builder5.centos.org Group : System Environment/Base Source RPM: tzdata-2007d-1.el4.src.rpm Size : 687779 License: GPL Signature : DSA/SHA1, Sat 24 Mar 2007 03:21:46 AM MDT, Key ID a53d0bab443e1821 Summary : Timezone data Description : This package contains data files with rules for various timezones around the world.
2. Is your /etc/localtime the correct one for your timezone? For example, my timezone is MDT. So my /etc/localtime should be copied from /usr/share/zoneinfo/America/Denver.
--peter
Peter Gross wrote:
Two really dumb questions:
- Have you updated the tzdata package? Here's the output of rpm -qi
tzdata on my system:
[pag@sempron zoneinfo]$ rpm -qi tzdata Name : tzdata Relocations: (not relocatable) Version : 2007d Vendor: CentOS Release : 1.el4 Build Date: Sat 24 Mar 2007 02:46:37 AM MDT Install Date: Sun 25 Mar 2007 10:17:19 PM MDT Build Host: builder5.centos.org Group : System Environment/Base Source RPM: tzdata-2007d-1.el4.src.rpm Size : 687779 License: GPL Signature : DSA/SHA1, Sat 24 Mar 2007 03:21:46 AM MDT, Key ID a53d0bab443e1821 Summary : Timezone data Description : This package contains data files with rules for various timezones around the world.
- Is your /etc/localtime the correct one for your timezone? For
example, my timezone is MDT. So my /etc/localtime should be copied from /usr/share/zoneinfo/America/Denver.
--peter
Hi Peter,
just checked and yes, the tzdata is the same as yours, and I re-copied /usr/share/zoneinfo/Europe/London but that has not made any difference.
Andy.
Peter Gross wrote:
Two really dumb questions:
- Have you updated the tzdata package? Here's the output of rpm -qi
tzdata on my system:
[pag@sempron zoneinfo]$ rpm -qi tzdata Name : tzdata Relocations: (not relocatable) Version : 2007d Vendor: CentOS Release : 1.el4 Build Date: Sat 24 Mar 2007 02:46:37 AM MDT Install Date: Sun 25 Mar 2007 10:17:19 PM MDT Build Host: builder5.centos.org Group : System Environment/Base Source RPM: tzdata-2007d-1.el4.src.rpm Size : 687779 License: GPL Signature : DSA/SHA1, Sat 24 Mar 2007 03:21:46 AM MDT, Key ID a53d0bab443e1821 Summary : Timezone data Description : This package contains data files with rules for various timezones around the world.
- Is your /etc/localtime the correct one for your timezone? For
example, my timezone is MDT. So my /etc/localtime should be copied from /usr/share/zoneinfo/America/Denver.
--peter
Hi Peter,
just checked and yes, the tzdata is the same as yours, and I re-copied /usr/share/zoneinfo/Europe/London but that has not made any difference.
Andy. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi
The clocks went forward on the weekend so this hasn't picked up BST.
What clocks are you syncing against? Also have a look at http://kbase.$UPSTREAMPROVIDER.com/faq/FAQ_85_9951 for some possible pointers.
HTH
Richard