| View previous topic :: View next topic |
| Author |
Message |
greyspoke
Apprentice
Joined: 08 Jan 2010
Posts: 171
|
 Posted: Mon Sep 10, 2012 7:13 pm Post subject: Clock and timezone problem |
 |
|
Unti quite recently my computer got on well with its clock. CONFIG_RTC_HCTOSYS is set in the kernel, my timezone (Europe/ London) is in etc/localtime, my /etc/init.d/hwclock has:
| Quote: | # Set CLOCK to "UTC" if your Hardware Clock is set to UTC (also known as
# Greenwich Mean Time). If that clock is set to the local time, then
# set CLOCK to "local". Note that if you dual boot with Windows, then
# you should set it to "local".
clock="UTC"
# If you want the hwclock script to set the system time (software clock)
# to match the current hardware clock during bootup, leave this
# commented out.
# However, you can set this to "NO" ifyou are running a modern kernel
# with CONFIG_RTC_HCTOSYS set to y and your hardware clock set to UTC.
clock_hctosys="NO"
# If you do not want to set the hardware clock to the current system
# time (software clock) during shutdown, set this to no.
clock_systohc="YES"
# If you wish to pass any other arguments to hwclock during bootup,
# you may do so here. Alpha users may wish to use --arc or --srm here.
clock_args=""
|
hwclock is in the boot runlevel.
After a recent upgrade the system clock is no longer getting set correctly, as can be seen from this extract from rc.log (with some added comments) - this was a restart immediately after shutdown:
| Quote: |
...stuff
* Setting hardware clock using the system clock [UTC] ...
[ ok ]
rc shutdown logging stopped at Mon Sep 10 18:54:05 2012
rc boot logging started at Mon Sep 10 18:54:59 2012 ####the correct BST time
* Setting system clock using the hardware clock [UTC] ... ####that's right the hardware clock should be in UTC
[ ok ]
* Checking local filesystems ...
/dev/md123: clean, 12271/122160 files, 64994/487936 blocks
/dev/md122: clean, 69/32128 files, 109222/128384 blocks
/dev/mapper/vg-vartmp: Superblock last write time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set). FIXED.
/dev/mapper/vg-vartmp: clean, 171046/1048576 files, 520700/4194304 blocks
/dev/mapper/vg-tmp: Superblock last write time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set). FIXED.
/dev/mapper/vg-tmp: clean, 17/131072 files, 9009/524288 blocks
/dev/mapper/vg-opt: Superblock last write time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set). FIXED.
/dev/mapper/vg-opt: clean, 3154/262144 files, 100903/1048576 blocks (check in 4 mounts)
/sbin/fsck.xfs: XFS file system.
[ ok ]
* Remounting root filesystem read/write ...
[ ok ]
... stuff
rc boot logging stopped at Mon Sep 10 17:55:02 2012 ###so before fsck was run the clock went wrong
rc default logging started at Mon Sep 10 17:55:02 2012
... stuff
rc default logging stopped at Mon Sep 10 17:55:24 2012
|
ntpd then corrects the clock back to BST. Before I changed it to use the -g option (after this first happened) it wouldn't set the time at all as it was too far (1 hour) out. So it looks like the system clock is getting set wrongly, rather than simply ignoring the daylight saving hour. Anyhow an hour or so after the above here is what we get:
| Quote: | timothy@tims_pc ~ $ sudo hwclock
Password:
Mon 10 Sep 2012 19:51:40 BST -0.812841 seconds
timothy@tims_pc ~ $ date
Mon Sep 10 19:51:44 BST 2012
timothy@tims_pc ~ $
|
So now both the hwclock and the system clock thought it was 19:51 -ish BST, (presumably they thought it was 18:51 -ish UTC) which was correct.
The system clock appears to be setting itself from the hardware clock wrongly - perhaps reading it and thinking it is saying BST (which it isn't) an so subtracting an hour from it when it shouldn't. Or something, there are a lot of things about how it ought to work that I don't understand.
Any ideas?
ETA I am running ~amd64 and 3.2.21 kernel |
|
| Back to top |
|
 |
BillWho
Veteran
Joined: 03 Mar 2012
Posts: 1600
Location: US
|
| Posted: Tue Sep 11, 2012 7:46 pm Post subject: |
|
|
greyspoke,
Check if /etc/localtime was overwritten - this happened to me a couple of times. I symlinked it to my timezone so I can tell if it gets clobbered.
I also have windows installed on this machine so I have clock="local" set in /etc/conf.d/hwclock. The other three computers that are linux-only are set at "UTC.
_________________
Good luck 
Since installing gentoo, my life has become one long emerge  |
|
| Back to top |
|
|
greyspoke
Apprentice
Joined: 08 Jan 2010
Posts: 171
|
| Posted: Wed Sep 12, 2012 7:37 pm Post subject: |
|
|
Thanks BillWho
Before your post I set clock_hctosys="YES" in /etc/.conf.d/hwclock and now it boots up fine with the correct time showing all through. Also, my little home server (running x86) is behaving itself time-wise with the same time settings as I had originally, and I have checked that its /etc/localtime and /usr/share/zoneinfo/localtime are identical to those on my computer. Strangely, the two files are not the same, /usr/share/zoneinfo/localtime is shorter than the one in /etc, the latter is the same as /usr/share/zoneinfo/Europe/London. But as they are binary I cannot fathom what the differences mean, I have just been comparing the hexdumps.
/etc/init.d/hwclock doesn't seem to have changed in a relevant way between the two computers either, and /usr is mounted in the initramfs so the absence of that can't be the problem.
So it is looking like the problem arises from a kernel upgrade, though that happened a few weeks ago and I must have not noticed the problem??? According to /etc/init.d/hwclock that updates the system clock with timezone info even if it doesn't actually set the system clock, so the cause must be the kernel not setting the system clock to the correct UTC time for some reason. The kernel appears to be applying a correction as if the hwclock was reading BST - but how does it know any timezone data?
Well that's me stumped. |
|
| Back to top |
|
|
Bones McCracker
Veteran
Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.
|
| Posted: Sat Sep 22, 2012 3:52 am Post subject: |
|
|
I have been having this same issue.
I have the same clock configuration (different time zone). Kernel CONFIG_RTC_HCTOSYS is enabled, and I have the same /etc/init.d/hwclock as the original post.
I have /etc/timezone containing the correct value for me (US/Eastern), and have verified that /etc/localtime is a copy of the correct zoneinfo file for that timezone (/usr/share/zoneinfo/US/Eastern).
Observe:
According to its man page, 'hwclock' always displays local time, and must be set using the local time. But I want to confirm that hwclock is actually running UTC time, so I manually set it, specifying the '--utc' option: | Code: | | ~ # hwclock --set --utc --date "22 Sep 2012 22:58" |
hwclock displays the correct time | Code: | ~ # hwclock
Sat 22 Sep 2012 10:58:05 PM EDT -0.685798 seconds |
I set the system clock from the Hardware Clock. The system clock displays the correct local and UTC time: | Code: | ~ # hwclock -s
~ # date
Sat Sep 22 22:58:29 EDT 2012
~ # date -u
Sun Sep 23 02:58:31 UTC 2012 |
Everything appears to be in order, so I reboot.
I get a proper message during boot that the system clock is being set from the hardware clock, including the correct UTC time. | Code: | | rtc_cmos 00:05: setting system clock to 2012-09-22 02:59:38 UTC |
When the system is fully up, I notice my system clock is wrong, displaying the UTC time, labeled as local time (with the system clock's UTC time different by the same offset, of course): | Code: | ~ # date
Sat Sep 23 03:01:29 EDT 2012
~ # date -u
Sat Sep 23 07:01:31 UTC 2012 |
But, the hardware clock is still correct: | Code: | ~ # hwclock
Sat 22 Sep 2012 11:01:52 PM EDT |
So, it looks to me like the kernel RTC_HCTOSYS is ignoring timezones and assuming the Hardware Clock is running local time. But, I assume this to be some kind of user configuration error on my part, since this is the only other reference I can find to anyone having such a problem.
_________________
| patrix_neo wrote: | The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it. |
|
|
| Back to top |
|
|
Dr. Strangelove
Tux's lil' helper
Joined: 01 May 2006
Posts: 104
Location: Germania
|
| Posted: Sat Sep 22, 2012 7:07 am Post subject: |
|
|
The misfunctional clock / timezone settings comes from the update to sys-apps/util-linux-2.22.
I opened this bug some days ago.
Here is the link to the same bug in Arch Linux.
My temporary solution was to keep sys-apps/util-linux-2.21.2 until there is a real fix. |
|
| Back to top |
|
|
Bones McCracker
Veteran
Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.
|
| Posted: Sat Sep 22, 2012 7:27 am Post subject: |
|
|
| Dr. Strangelove wrote: | The misfunctional clock / timezone settings comes from the update to sys-apps/util-linux-2.22.
I opened this bug some days ago.
Here is the link to the same bug in Arch Linux.
My temporary solution was to keep sys-apps/util-linux-2.21.2 until there is a real fix. |
Thank you.
_________________
| patrix_neo wrote: | The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it. |
|
|
| Back to top |
|
|
Bones McCracker
Veteran
Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.
|
| Posted: Sat Sep 22, 2012 8:53 pm Post subject: |
|
|
I have commented on your bug. I think the problem may lie elsewhere than hwclock.
Read the entire Description section of the man page for settimeofday() and tell me if the problem described in the last paragraph doesn't sound familiar.
_________________
| patrix_neo wrote: | The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it. |
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
