Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Strange with hardware clock
Strange with hardware clock
Hi
I just install Debian squeeze/sid on my desktop with KDE.
On each reboot system time adds 3 hours.
My timezone is GMT+3 and hardware clock is set to local time because I use multiboot with Windows.
As I search, in /etc/default/rcS must be UTC=no. But it was and didn't work.
Then I looked in my debian netbook settings and there was UTC=yes. On netbook debian runs about a year without such problems and I never look at these parameters.
After I set UTC=yes on my desktop everything works ok.
But why?
I have two machines with correctly working wrong settings?
I just install Debian squeeze/sid on my desktop with KDE.
On each reboot system time adds 3 hours.
My timezone is GMT+3 and hardware clock is set to local time because I use multiboot with Windows.
As I search, in /etc/default/rcS must be UTC=no. But it was and didn't work.
Then I looked in my debian netbook settings and there was UTC=yes. On netbook debian runs about a year without such problems and I never look at these parameters.
After I set UTC=yes on my desktop everything works ok.
But why?
I have two machines with correctly working wrong settings?
Re: Strange with hardware clock
I did dpkg-reconfigure tzdata. It's ok.refracta wrote:is your timezone set correctly?
dpkg-reconfigure tzdata
Output of commands:
Code: Select all
# env LANG=en_EN date
Tue Jan 12 00:20:14 MSK 2010
# env LANG=en_EN date -u
Mon Jan 11 21:20:17 UTC 2010
# env LANG=en_EN hwclock -r
Tue Jan 12 00:20:23 2010 -0.128220 seconds
- TristanDee
- Posts: 64
- Joined: 2007-12-11 10:43
- Location: Dhaka, Bangladesh
- Contact:
Re: Strange with hardware clock
I also faced a similar situation except for in my case the clock used to go back by six hours to set UTC. I'm in UTC+6 timezone. Occasionally, especially if aptitude upgrade had anything to do with time settings, the clock would go back by six hours.
I don't know if this will work for you--it worked for me. Set the correct time while you are in Debian. Then type in terminal as root
This is supposed to set system time to the hardware clock. And this should not affect Windows.
After such upgrades I just told about, I get an error during boot-up, saying the last booting time WAS IN THE FUTURE. So I have to login as root and run fsck, which fixes the conflicts.
I don't know if this will work for you--it worked for me. Set the correct time while you are in Debian. Then type in terminal as root
Code: Select all
hwclock --systohc
After such upgrades I just told about, I get an error during boot-up, saying the last booting time WAS IN THE FUTURE. So I have to login as root and run fsck, which fixes the conflicts.
...Our lives are mostly a constant evasion of ourselves. --TS Eliot
Linux User #501018
Linux User #501018
Re: Strange with hardware clock
It's worth checking what time your hardware clock is actually using. You don't always get the correct result from hwclock --show because the system gives you a "corrected" time if it thinks you are running UTC. hwclock --show --debug will give you more information.
Re: Strange with hardware clock
Your UTC and MSK are showing the same time as per your second post.
Try "date -R"
Also you could use "ntpdate" to set time automatically using ntp protocol.
Try "date -R"
Also you could use "ntpdate" to set time automatically using ntp protocol.
Compressed Air Energy Storage, Entropy and Efficiency
http://saurorja.org/2012/06/18/compress ... fficiency/
http://saurorja.org/2012/06/18/compress ... fficiency/
Re: Strange with hardware clock
You were right. hwclock --debug shows that my real hardware clock was UTC. Thankshazel wrote:It's worth checking what time your hardware clock is actually using. You don't always get the correct result from hwclock --show because the system gives you a "corrected" time if it thinks you are running UTC. hwclock --show --debug will give you more information.
Than I go to /etc/default/rcS and set UTC=no. After it I have another bug.
Here is the output. My system time is always hardware clock+3. And hardware clock shows right time. Date shows wrong.
When setting hwclock --hctosys date becomes right but after reboot it's again hwclock+3.
Code: Select all
$ env LANG=en_EN date
Mon Jan 18 04:22:08 MSK 2010
$ env LANG=en_EN hwclock --debug
hwclock from util-linux-ng 2.16.2
Using /dev interface to clock.
Last drift adjustment done at 1263766366 seconds after 1969
Last calibration done at 1263766366 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2010/01/18 01:22:12
Hw clock time : 2010/01/18 01:22:12 = 1263766932 seconds since 1969
Mon Jan 18 01:22:12 2010 -0.606672 seconds
Code: Select all
$ dmesg | grep -i utc
[ 0.000000] Linux version 2.6.30-2-amd64 (Debian 2.6.30-8squeeze1) (dannf@debian.org) (gcc version 4.3.4 (Debian 4.3.4-5) ) #1 SMP Mon Dec 7 05:21:45 UTC 2009
[ 0.421717] rtc_cmos 00:05: setting system clock to 2010-01-18 01:13:16 UTC (1263777196)
Looks similar to debian bug 534308 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534308 but I have util-linux 2.16-2.0
I don't want to use ntp just now. I want not to simply see correct time but also understand what the problem isaspnair wrote:Your UTC and MSK are showing the same time as per your second post.
Try "date -R"
Also you could use "ntpdate" to set time automatically using ntp protocol.
Re: Strange with hardware clock
As I understand the problem is kernel option RTC_HCTOSYS=yes. It sets system clock directly from hardware clock on boot.
I also checked that script /etc/init.d/hwclock.sh does nothing because there is no udev
This means that if I recompile kernel with RTC_HCTOSYS=no the system will not update system clock at all?
May be really better to use ntp. I will try later
I also checked that script /etc/init.d/hwclock.sh does nothing because there is no udev
This means that if I recompile kernel with RTC_HCTOSYS=no the system will not update system clock at all?
May be really better to use ntp. I will try later
Re: Strange with hardware clock
[quote="mertress"]You were right. hwclock --debug shows that my real hardware clock was UTC. Thanks
Than I go to /etc/default/rcS and set UTC=no. After it I have another bug.
Here is the output. My system time is always hardware clock+3. And hardware clock shows right time. Date shows wrong.
When setting hwclock --hctosys date becomes right but after reboot it's again hwclock+3.
Than I go to /etc/default/rcS and set UTC=no. After it I have another bug.
Here is the output. My system time is always hardware clock+3. And hardware clock shows right time. Date shows wrong.
When setting hwclock --hctosys date becomes right but after reboot it's again hwclock+3.
Code: Select all
$ env LANG=en_EN date
Mon Jan 18 04:22:08 MSK 2010[/quote]
No, you're still confused. Setting UTC=yes or UTC=no doesn't tell your hardware clock what kind of time to use. It just tells the hwclock program how to interpret the figures it finds on the clock. If you want your hardware clock to show local time, you need to do two things:
1) Write UTC=no in rcS so that the system will know that your clock is meant to be using local time, not UTC.
2) Reboot and go into the BIOS. Now physically set the hardware clock to show the same time as your local clocks.
When Debian boots, it should set the system time to the actual time on your hardware clock without making any corrections for locale.
Re: Strange with hardware clock
hazel, thank for your answer
Now let's clear some moments
If I right, hardware clock = bios clock. I can set it in bios directly or throuh hwclock tool.
What happens on my machine. I set UTC=no, reboot many times
Hwclock tool shows for example that local_time=hw_time=x hours. And date command shows x+3 hours. Moreover each reboot adds 3 hours to both.
The question is: which scripts make correction? I found these answer (correct me if I wrong)
1. When system boots it runs scripts from /etc/rcS. There is hwclock.sh which shoud set system time from hardware clock with correction (depends on UTC=no or UTC=yes). But on my machine it does nothing, I checked.
2. With kernel option RTC_HCTOSYS=yes. Something (I don't know what) sets system clock to hardware clock during boot, because kernel doesn't know about time zone.
3. When shutdown, hwclock.sh runs and sets hardware clock from system time (with or without correction, depends on UTC option).
On my system on boot kernel sets system time to hardware_time+3.
I found this description:
"config RTC_HCTOSYS
If you say yes here, the specified RTC device will be used as a reference to the system time (wall clock). The device will be used to set the system time as required during startup, suspend and, for platforms that support such usage, for NTP timekeeping.
config RTC_HCTOSYS_DEVICE
The RTC device that will be used as a reference for the system clock, usually rtc0. Initialization is done when the system if supported by the platform, NTP timekeeping uses this device to record the system time periodically. This device should record time in UTC, since the kernel won't do timezone correction. "
When I shutdown hwclock.sh records actual system time to hardware (it sees that hardware use local time). Due to system time was previously set to hardware_time+3, hwclock.sh really increments hardware clock for 3 hours. And so each reboot.
P.S. now I installed ntp and happy
Now let's clear some moments
If I right, hardware clock = bios clock. I can set it in bios directly or throuh hwclock tool.
What happens on my machine. I set UTC=no, reboot many times
Hwclock tool shows for example that local_time=hw_time=x hours. And date command shows x+3 hours. Moreover each reboot adds 3 hours to both.
The question is: which scripts make correction? I found these answer (correct me if I wrong)
1. When system boots it runs scripts from /etc/rcS. There is hwclock.sh which shoud set system time from hardware clock with correction (depends on UTC=no or UTC=yes). But on my machine it does nothing, I checked.
2. With kernel option RTC_HCTOSYS=yes. Something (I don't know what) sets system clock to hardware clock during boot, because kernel doesn't know about time zone.
3. When shutdown, hwclock.sh runs and sets hardware clock from system time (with or without correction, depends on UTC option).
On my system on boot kernel sets system time to hardware_time+3.
I found this description:
"config RTC_HCTOSYS
If you say yes here, the specified RTC device will be used as a reference to the system time (wall clock). The device will be used to set the system time as required during startup, suspend and, for platforms that support such usage, for NTP timekeeping.
config RTC_HCTOSYS_DEVICE
The RTC device that will be used as a reference for the system clock, usually rtc0. Initialization is done when the system if supported by the platform, NTP timekeeping uses this device to record the system time periodically. This device should record time in UTC, since the kernel won't do timezone correction. "
When I shutdown hwclock.sh records actual system time to hardware (it sees that hardware use local time). Due to system time was previously set to hardware_time+3, hwclock.sh really increments hardware clock for 3 hours. And so each reboot.
P.S. now I installed ntp and happy
Re: Strange with hardware clock
Correct. I prefer to do this sort of correction in the BIOS. That way I can better see what I'm doing.mertress wrote:If I right, hardware clock = bios clock. I can set it in bios directly or throuh hwclock tool.
date always shows the system time. If this is really three hours ahead of the hardware clock, then for some reason your kernel is convinced that your clock is keeping UTC even though you have told it the opposite. I find this rather weird. The three hour shift gets frozen in by the shutdown script as you have surmised in section 3. Hence the ratchet effect that occurs with every reboot.What happens on my machine. I set UTC=no, reboot many times
Hwclock tool shows for example that local_time=hw_time=x hours. And date command shows x+3 hours. Moreover each reboot adds 3 hours to both.
What do you mean, it does nothing? What did you check?1. When system boots it runs scripts from /etc/rcS. There is hwclock.sh which shoud set system time from hardware clock with correction (depends on UTC=no or UTC=yes). But on my machine it does nothing, I checked.
I think this applies to the kernel being able to know the time during boot when it is checking the filesystems. Whatever system time is set by this option should get over-ridden by hwclock.sh. The kernel help notes say that you should only have this option checked if you have an rtc device that uses UTC - which yours doesn't. I wonder if this is the source of all your trouble.2. With kernel option RTC_HCTOSYS=yes. Something (I don't know what) sets system clock to hardware clock during boot, because kernel doesn't know about time zone.
Re: Strange with hardware clock
hazel, yes, it seems that the problem is in kernel option.
And some words about hwclock.sh. I added several debugging strings to test, where it exits.
A piece of code for option "start" from hwclock.sh
So, it does nothing when udev is present. There are udev rules about hwclock.
And some words about hwclock.sh. I added several debugging strings to test, where it exits.
A piece of code for option "start" from hwclock.sh
Code: Select all
case "$1" in
start)
if [ -d /dev/.udev ]; then
return 0 -- EXITS HERE
fi
So, it does nothing when udev is present. There are udev rules about hwclock.