| View previous topic :: View next topic |
| Author |
Message |
xoJIog
n00b
Joined: 10 Jan 2014
Posts: 7
|
 Posted: Fri Jul 31, 2015 12:55 pm Post subject: hwclock and localtime problem |
 |
|
The problem is that system will modify system time based on /etc/localtime, even if hwlock is set to local time:
Setting hwclock to local true time:
| Code: | cat /etc/conf.d/hwclock
clock="local"
clock_hctosys="YES"
clock_systohc="YES"
clock_args=""
|
| Code: | cp /usr/share/zoneinfo/Europe/Riga /etc/localtime
date
Fri Jul 31 15:38:26 EEST 2015
hwclock -w --localtime
hwclock -r --localtime
Fri Jul 31 15:38:30 2015 -0.911500 seconds
|
System reboot:
| Code: | reboot
date
Fri Jul 31 18:41:42 EEST 2015
hwclock --localtime
Fri Jul 31 15:41:57 2015 -0.193070 seconds
rm /etc/localtime
date
Fri Jul 31 15:42:09 UTC 2015
|
What am I doing wrong? |
|
| Back to top |
|
 |
charles17
Advocate
Joined: 02 Mar 2008
Posts: 2799
|
| Posted: Fri Jul 31, 2015 4:16 pm Post subject: Re: hwclock and localtime problem |
|
|
| xoJIog wrote: | The problem is that system will modify system time based on /etc/localtime, even if hwlock is set to local time:
Setting hwclock to local true time:
| Code: | cat /etc/conf.d/hwclock
clock="local"
clock_hctosys="YES"
clock_systohc="YES"
clock_args=""
|
|
Be sure to not conflict with the In-kernel method. |
|
| Back to top |
|
|
xoJIog
n00b
Joined: 10 Jan 2014
Posts: 7
|
| Posted: Mon Aug 03, 2015 4:17 pm Post subject: |
|
|
yes, you are right. in-kernel method was enabled, I disabled it:
| Code: |
zgrep CONFIG_RTC_HCTOSYS /proc/config.gz
# CONFIG_RTC_HCTOSYS is not set
zgrep RTC_SYSTOHC /proc/config.gz
# CONFIG_RTC_SYSTOHC is not set
|
But I still see the same problem, after reboot system time is off by value of timezone:
| Code: |
hwclock -r --localtime ; date
Mon Aug 3 19:13:01 2015 -0.958791 seconds
Mon Aug 3 22:13:02 EEST 2015
rm /etc/localtime ; date
Mon Aug 3 19:13:22 UTC 2015
|
|
|
| Back to top |
|
|
charles17
Advocate
Joined: 02 Mar 2008
Posts: 2799
|
| Posted: Tue Aug 04, 2015 4:39 am Post subject: |
|
|
| xoJIog wrote: | But I still see the same problem, after reboot system time is off by value of timezone:
| Code: |
hwclock -r --localtime ; date
Mon Aug 3 19:13:01 2015 -0.958791 seconds
Mon Aug 3 22:13:02 EEST 2015
rm /etc/localtime ; date
Mon Aug 3 19:13:22 UTC 2015
|
|
What do you expect the --localtime option to do? Reading man hwclock might give you more information. |
|
| Back to top |
|
|
xoJIog
n00b
Joined: 10 Jan 2014
Posts: 7
|
| Posted: Tue Aug 04, 2015 7:19 am Post subject: |
|
|
I expect --localtime option to tell hwclock that I wish to keep hardware time in localtime.
After I execute command hwclock with --localtime or --utc option, hwclock writes to /etc/adjtime value that defines if hardware clock is kept in localtime or in utc.
As is written in man:
| Code: |
--localtime
-u, --utc
Indicate which timescale the Hardware Clock is set to.
The Hardware Clock may be configured to use either the UTC or
the local timescale, but nothing in the clock itself says
which alternative is being used. The --localtime or --utc
options give this information to the hwclock command. If you
specify the wrong one (or specify neither and take a wrong
default), both setting and reading the Hardware Clock will be
incorrect.
If you specify neither --utc nor --localtime then the one last
given with a set function (--set, --systohc, or --adjust), as
recorded in /etc/adjtime, will be used. If the adjtime file
doesn't exist, the default is UTC.
|
This problem is really frustrating because I have it on multiple servers, but I cannot find anyone who has the same problem which leads me to think that I am doing something wrong. 
FYI: I have tried various combinations of hw clock setting using utc/localtime and none of them worked properly. |
|
| Back to top |
|
|
charles17
Advocate
Joined: 02 Mar 2008
Posts: 2799
|
| Posted: Tue Aug 04, 2015 7:33 am Post subject: |
|
|
Doing without the options shows me | Quote: | $ su -c "hwclock && date"
Password:
Tue 04 Aug 2015 09:22:21 AM CEST -0.672506 seconds
Tue Aug 4 09:22:21 CEST 2015 |
While /etc/adjtime is | /etc/adjtime wrote: | $ cat /etc/adjtime
-146.665737 1428911787 0.000000
1428911787
UTC |
Using -r --localtime gives indeed very confusing output: | Quote: | $ su -c "hwclock -r --localtime && hwclock"
Password:
Tue 04 Aug 2015 07:28:18 AM CEST -0.047371 seconds
Tue 04 Aug 2015 09:28:19 AM CEST -1.000631 seconds |
|
|
| Back to top |
|
|
xoJIog
n00b
Joined: 10 Jan 2014
Posts: 7
|
| Posted: Tue Aug 04, 2015 8:45 am Post subject: |
|
|
It seems you have your hardware clock set to UTC, I've done the same:
| Code: | cat /etc/adjtime
-64.430050 1438677666 0.000000
1438677666
UTC
hwclock ; date
Tue Aug 4 11:42:52 2015 -0.443304 seconds
Tue Aug 4 11:42:51 EEST 2015
|
and I've modified /etc/conf.d/hwclock
| Code: | cat /etc/conf.d/hwclock | grep -v "#"
clock="UTC"
clock_hctosys="YES"
clock_systohc="YES"
clock_args=""
|
all is well, until system is restarted
| Code: | reboot
hwclock ; date
Tue Aug 4 11:48:03 2015 -0.914540 seconds
Tue Aug 4 14:48:04 EEST 2015
|
|
|
| Back to top |
|
|
xoJIog
n00b
Joined: 10 Jan 2014
Posts: 7
|
| Posted: Tue Aug 04, 2015 9:03 am Post subject: |
|
|
Ok, the problem is that I was using a machine in virtual environment for tests, it seems that vmware is doing some magic with hardware clock on system restart. I am unable to reproduce this issue on a real server.
Sorry to waste your time with this. |
|
| Back to top |
|
|
Goverp
l33t
Joined: 07 Mar 2007
Posts: 729
|
| Posted: Tue Aug 04, 2015 9:10 am Post subject: |
|
|
Out of interest, why do you want to run the hardware clock in local time? That doesn't make much sense, and can cause real problems if your time zone does daylight saving time shifts.
Using local time used to make sense on boxes that dual-boot with Windows, but AFAIK all versions later than XP can be set to handle a UTC hardware clock.
_________________
Greybeard |
|
| Back to top |
|
|
charles17
Advocate
Joined: 02 Mar 2008
Posts: 2799
|
| Posted: Tue Aug 04, 2015 10:45 am Post subject: |
|
|
| Goverp wrote: | | Using local time used to make sense on boxes that dual-boot with Windows, but AFAIK all versions later than XP can be set to handle a UTC hardware clock. |
and that also wfm with windows 10. |
|
| Back to top |
|
|
xoJIog
n00b
Joined: 10 Jan 2014
Posts: 7
|
| Posted: Tue Aug 04, 2015 1:28 pm Post subject: |
|
|
We use HW clock in local time only because it is more convenient for people that initially configure bios for the new hardware.
We experienced no problems with daylight savings time shifts even if HW clock is set to local time. Of course this may be due to the face that ntp will run on system startup and correct any errors ( > than 180 seconds ).
However as it was in my initial problem sometimes due to openrc misconfiguration and/or network problem ntp may start before network is available, and that can cause problems. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6296
|
| Posted: Tue Aug 04, 2015 3:46 pm Post subject: |
|
|
| charles17 wrote: | Using -r --localtime gives indeed very confusing output: | Quote: | $ su -c "hwclock -r --localtime && hwclock"
Password:
Tue 04 Aug 2015 07:28:18 AM CEST -0.047371 seconds
Tue 04 Aug 2015 09:28:19 AM CEST -1.000631 seconds |
|
According to your commands, the hardware clock data is fetched twice, first interpreting it as local time, and then interpreting it as UTC. What is confusing here, in your opinion?
Concerning your original problem, it seems that something besides openrc is fetching or storing the hardware clock data in UTC. If it is not the kernel itself, I do not know what it is. You should try to configure a very first and a very last process which shows the hardware clock to see whether it is "still" correct. (I am still not sure that it is not the kernel - there are several kernel options concerning various timers which I do not understand and which are perhaps still involved; of course, the kernel has no idea about timezones.)
Just to be sure, please confirm that you are using openrc (and not e.g. systemd), because this would explain the ignoring of /etc/conf.d/* |
|
| Back to top |
|
|
|
Kernel & Hardware
