| View previous topic :: View next topic |
| Author |
Message |
mgwolff
n00b
Joined: 18 Dec 2017
Posts: 33
|
 Posted: Mon Dec 18, 2017 6:17 pm Post subject: Persistent clock skew warnings but no clock skew |
 |
|
On my freshly installed Gentoo/Win10 dual boot system, I am experiencing persistent clock skew warnings on boot. However, neither my OS clock nor my hardware clock are actually skewed, but I still get warnings such as this one at every boot:
| Code: |
Clock skew detected with `/etc/init.d'
Adjusting mtime of `/run/openrc/deptree' to Sun Dec 17 12:45:57 2017
|
The problem happens every time I boot Linux, even if I did not boot Windows 10 in the meantime.
I believe I have configured everything according to the instructions:
/etc/conf.d/hwclock
| Code: |
clock="local"
clock_args=""
|
/etc/timezone
| Code: |
$ zdump /etc/localtime
/etc/localtime Mon Dec 18 13:04:02 2017 -05
|
Both the software clock and the hardware clock are set correctly to local time. For example, I ran the following command at 13:05 local time (GMT-5):
| Code: |
# date && date -u && /etc/init.d/hwclock show
Mon Dec 18 13:05:35 -05 2017
Mon Dec 18 18:05:35 UTC 2017
2017-12-18 13:05:35.405061-0500
|
The output of "init.d/hwclock show" matches the time displayed in my UEFI BIOS.
I have tried the following things to fix this problem:
- Re-emerge my whole system with:
# emerge --update --deep --newuse --with-bdeps=y --emptytree world
- Try to find files with a wrong timestamp by executing:
# touch /curtime && find / -cnewer /curtime
No files were found.
- Install and run ntpd and ntp-client.
- Use the "In-kernel" method described in this guide: https://wiki.gentoo.org/wiki/System_time#Syncing_the_hardware_clock_and_system_time
However, that caused additional problems. In IRC, someone stated that the "In kernel" method does not support hardware clock local time, so I disabled that option again.
- Install a basic Gentoo system on a different partition. There, I could observe the same problem.
Does anyone have any other idea what could be the problem? Maybe Gentoo has some bug which prevents it from properly using clock="local"? With my previous laptop, I used clock="local" without problems for many years on Gentoo, but that system was set up in 2012, so I guess many things have changed in the meantime. |
|
| Back to top |
|
 |
mgwolff
n00b
Joined: 18 Dec 2017
Posts: 33
|
| Posted: Mon Dec 18, 2017 6:44 pm Post subject: |
|
|
| As a test, I disabled the /etc/init.d/hwclock script, which sets my OS clock from the hardware clock on boot. Now, my OS clock is set to 5 hours early at every boot. So, I guess that would explain the clock skew warnings, because after the reboot, the system thinks it is 5 hours earlier than it was before the boot. The problem is hidden by the /etc/init.d/hwclock script, which later on sets the OS clock to the correct time. Does anyone have an idea why my OS clock is set to 5 hours early at every boot? It seems like my timezone is applied twice. |
|
| Back to top |
|
|
LIsLinuxIsSogood
Veteran
Joined: 13 Feb 2016
Posts: 1179
|
| Posted: Mon Dec 18, 2017 6:52 pm Post subject: |
|
|
| Quote: | | The problem happens every time I boot Linux, even if I did not boot Windows 10 in the meantime. |
Hi, so just to get clear the same problem and same messages occur in your boot cycle in two consecutive boots of linux, which probably means that you haven't found the solution just yet. Or else why would you be posting here 
Have you tried the configuring of the file in /etc/conf.d/hwclock...here is how mine looks and it seems to work fine with the system clock (and I don't have to use any NTP, which for me is nice).
https://paste.pound-python.org/show/olEe9vPDujqwcf3ycRNU/
I think you can rely on the main board to keep the time (even when power is turned off on it) but the system will need to then sync to that each time, which could be why you have an error going on from launch of your openrc scripts. Just a guess. Get back if this is a situation that you may already have attempted, and we can troubleshoot other methods with or without NTP added. |
|
| Back to top |
|
|
LIsLinuxIsSogood
Veteran
Joined: 13 Feb 2016
Posts: 1179
|
| Posted: Mon Dec 18, 2017 6:57 pm Post subject: |
|
|
| Quote: | | - Install and run ntpd and ntp-client. |
This is another way to do things that would rely on NTP. But if that's not what you want, I think your onto something with the timezone issue as if that is being applied then it shouldn't be applied two times, I agree. Maybe check what happens if you use a different file to update the timezone with. Did you take the recommended approach from wiki for doing this? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Mon Dec 18, 2017 7:23 pm Post subject: |
|
|
mgwolff,
/etc/timezone needs to be set to localtime. Thats /usr/share/zoneinfo/localtime.
Your timezone corrections have already been done by setting your hardware clock to local time.
When you dual boot with Windows, your daylight saving changes (if any) will not be applied until Windows updates your hardware clock.
Using ntp will at best, hide the problew.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
LIsLinuxIsSogood
Veteran
Joined: 13 Feb 2016
Posts: 1179
|
| Posted: Mon Dec 18, 2017 10:57 pm Post subject: |
|
|
| Quote: | | As a test, I disabled the /etc/init.d/hwclock script, which sets my OS clock from the hardware clock on boot. Now, my OS clock is set to 5 hours early at every boot. |
mgwolff,
Keep in mind the way that system time works is sometimes opposite in terms of the it being represented by either +5 or -5 for the earlier time you describe.
Also just my opinion but could be a good idea to update the configuration for future boots, and the openrc hwclock config file has a place to set clock="local", which happens to be the recommended method for systems that are dual booting Windows at other times. |
|
| Back to top |
|
|
mgwolff
n00b
Joined: 18 Dec 2017
Posts: 33
|
| Posted: Mon Dec 18, 2017 11:19 pm Post subject: |
|
|
| LIsLinuxIsSogood wrote: |
Hi, so just to get clear the same problem and same messages occur in your boot cycle in two consecutive boots of linux, which probably means that you haven't found the solution just yet. Or else why would you be posting here
Have you tried the configuring of the file in /etc/conf.d/hwclock...here is how mine looks and it seems to work fine with the system clock (and I don't have to use any NTP, which for me is nice).
|
Yes, correct, the problem happens when booting Linux two times in a row, no Windows boot in between.
Please see the OP for /etc/conf.d/hwclock. The only difference is clock_systohc="YES", which defaults to "YES".
I agree that ntpd and ntp-client only cover up the problem, similar as to how switching Windows to UTC would only cover up the problem. |
|
| Back to top |
|
|
mgwolff
n00b
Joined: 18 Dec 2017
Posts: 33
|
| Posted: Mon Dec 18, 2017 11:21 pm Post subject: |
|
|
| NeddySeagoon wrote: | mgwolff,
/etc/timezone needs to be set to localtime. Thats /usr/share/zoneinfo/localtime.
Your timezone corrections have already been done by setting your hardware clock to local time.
When you dual boot with Windows, your daylight saving changes (if any) will not be applied until Windows updates your hardware clock.
Using ntp will at best, hide the problew. |
I just tried that, but if I do that, then my system time is in GMT:
==
xps:root@/etc# emerge --config sys-libs/timezone-data
Ready to configure sys-libs/timezone-data-2017c? [Yes/No] y
* Updating /etc/localtime with /usr/share/zoneinfo/localtime
xps:root@/etc# date && date -u && /etc/init.d/hwclock show
Mon Dec 18 22:50:43 GMT 2017
Mon Dec 18 22:50:43 UTC 2017
2017-12-18 17:50:42.810935+0000
== |
|
| Back to top |
|
|
mgwolff
n00b
Joined: 18 Dec 2017
Posts: 33
|
| Posted: Mon Dec 18, 2017 11:25 pm Post subject: |
|
|
| LIsLinuxIsSogood wrote: | | Quote: | | As a test, I disabled the /etc/init.d/hwclock script, which sets my OS clock from the hardware clock on boot. Now, my OS clock is set to 5 hours early at every boot. |
mgwolff,
Keep in mind the way that system time works is sometimes opposite in terms of the it being represented by either +5 or -5 for the earlier time you describe.
Also just my opinion but could be a good idea to update the configuration for future boots, and the openrc hwclock config file has a place to set clock="local", which happens to be the recommended method for systems that are dual booting Windows at other times. |
I actually already have clock="local"...
Do you have any links regarding this +5 / -5 problem so I can investigate? |
|
| Back to top |
|
|
mgwolff
n00b
Joined: 18 Dec 2017
Posts: 33
|
| Posted: Tue Dec 19, 2017 2:50 am Post subject: |
|
|
I tried some more things, but without luck:
- Installing an old /usr/share/zoneinfo/America/Bogota file (the reasoning being that previously timezone names, such as "COT", were used)
- Remove /etc/adjtime
- Play with the $TZ environment variable |
|
| Back to top |
|
|
LIsLinuxIsSogood
Veteran
Joined: 13 Feb 2016
Posts: 1179
|
| Posted: Tue Dec 19, 2017 4:27 am Post subject: |
|
|
| Did you check that openrc script? What runlevel in openrc calls it... |
|
| Back to top |
|
|
LIsLinuxIsSogood
Veteran
Joined: 13 Feb 2016
Posts: 1179
|
|
| Back to top |
|
|
LIsLinuxIsSogood
Veteran
Joined: 13 Feb 2016
Posts: 1179
|
| Posted: Tue Dec 19, 2017 7:22 am Post subject: |
|
|
EDIT: Reorganized to move the instructions up in the post a bit higher towards the top of it.
mgwolff, what we are perhaps failing to see is the system output for some of these files which would help immensely in the process of figuring out what's wrong with the configuration or setup. My guess is because you said the clock is only off by a matter of whole number of hours, it is the timezone, which also means you should not be needing to make a whole bunch of changes for that. In the mean time, please take a look in two places where it is well documented in the wiki (handbook, and the system time resource page in the wiki).
The more basic approach covered in the handbook should be the first thing to try.
Just curious, did you try this yet...
| Code: | emerge --config sys-libs/timezone-data
|
It first must be preceded by entering the correct timezone data into /etc/timezone...so please also show the contents of that file. It is very short you can probably just cut and paste.
See...
| Code: | playboy /etc # cat /etc/timezone
America/Los_Angeles
|
If that works then great, but if not remember these things can be tricky to be getting it right with whatever you do. But also you have to try to include some system output, even just a copy of a file or something so that we can see what's happening. You can use a pastebin tool or whatever (like I did for the hwclock configuration file I posted already) to save having to copy paste things and it will look much cleaner for the rest of everyone to have to see. |
|
| Back to top |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Tue Dec 19, 2017 7:37 am Post subject: |
|
|
The problem was identified by NeddySeagon. The clock is already local time so setting a correction (+/-) for the timezone is superfluous.
The reason the problem persists across boots on Linux is because your clock was not set to save its settings across reboots so it doesn't matter how many times you boot. Linux fixes the clock issue and then erases the correction on reboot.
_________________
First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Tue Dec 19, 2017 9:06 am Post subject: |
|
|
Overall procedure...
1. Set the time zone:
1.1 Specify your time zone in the file /etc/timezone. If you are in Colombia the contents of that file would be 'America/Bogota' (without the quotes).
| Code: | | # nano /etc/timezone |
You can check which time zones are available by looking in the directory /usr/share/zoneinfo/ and its sub-directories.
1.2 Provide the information for your time zone. If you are in Colombia you would enter the following command:
| Code: | | # cp /usr/share/zoneinfo/America/Bogota /etc/localtime |
Note: Some people recommend making /etc/localtime a symlink rather than creating it by copying a file from /usr/share/zoneinfo/, however I recommend copying. You should definitely not use a symlink if /usr is on a different partition.
2. Set the system clock's time to your local time now (I'll assume it is 23:54:30 on 21 December 2017 when you press Enter):
| Code: | | # date 122123542017.30 |
3. Specify whether the hardware clock time is UTC:
or local time:
| Code: | | # hwclock --localtime |
It is preferable for the hardware clock time to be in UTC. However, if you dual boot with Windows it is recommended for the hardware clock time to be in local time rather than UTC unless both the following are true: a) the Windows Registry has been configured for hardware clock time in UTC; b) Windows' time synchronisation with an Internet time server is disabled.
4. Set the hardware clock's time by specifying your local time (I'll assume it is 23:54:50 on 21 December 2017 when you press Enter):
| Code: | # rm /etc/adjtime
# hwclock --set --date="2017-12-21 23:54:50" |
Note: You must specify local time in the above command, even if you intend the hardware clock time to be UTC.
Note that the third line in /etc/adjtime should be 'UTC' if the hardware clock time is in UTC, or 'LOCAL' if the hardware clock time is in local time. For example:
| Code: | # cat /etc/adjtime
0.000000 1412038530 0.000000
1412038530
UTC |
5. Tell OpenRC whether the hardware clock uses UTC or local time, and to update the hardware clock time from the system clock time at every shutdown (taking into account any time zone difference between the two clocks):
| Code: | | # nano /etc/conf.d/hwclock |
5.1 Make clock="UTC" (or clock="local" if you dual boot with Windows and the Windows Registry is not configured to use UTC for hardware clock time).
5.2 Make clock_systohc="YES" to adjust the hardware clock time at shutdown based on the software clock time (taking time zone into account). However, you don't need to bother doing this if your kernel configuration has CONFIG_RTC_SYSTOHC=y and your installation is configured to synchronise the system clock with a NTP time server (see my blog post Synchronise your Gentoo Linux clock with an Internet time server). You can check if the hardware clock time is being updated from the software clock time (taking time zone into account) by looking at the kernel messages displayed when in verbose mode during shutdown to see if the following message is displayed:
| Code: | | Setting hardware clock using the system clock [UTC] ... |
5.3 Make clock_hctosys="YES" to adjust the system clock time at start up based on the hardware clock time (taking time zone into account). However, you don't need to bother doing this if your kernel configuration has CONFIG_RTC_HCTOSYS=y. You can check by looking at the kernel messages displayed when in verbose mode during boot to see if the following message is displayed:
| Code: | | Setting system clock using the hardware clock [UTC] ... |
6. Reboot and check everything is working as expected:
| Code: | # date
Thu 30 Dec 01:55:55 COT 2017
# hwclock
Thu 30 Dec 2017 01:55:59 COT -0.031877 seconds |
The hwclock command always shows local time, even if you keep your hardware clock in UTC.
7. Optionally (but I recommend it), configure your installation to synchronise the system clock with an Internet NTP server (see my above-mentioned blog post).
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Dec 19, 2017 12:15 pm Post subject: |
|
|
Look at line 383/384 https://github.com/OpenRC/openrc/blob/master/src/rc/rc-misc.c#L383
Openrc use stat without checking its return value and always assume stat succeed
Then as it assume stat succeed, it then use the c_time value of the struct (that is random and garbage as it is only good if stat succeed) and compare it with time_t t value to detect clock skew.
So it's possible on your system that stat fail, and openrc bug trigger the message.
If you're in mood to filebug... |
|
| Back to top |
|
|
mgwolff
n00b
Joined: 18 Dec 2017
Posts: 33
|
| Posted: Tue Dec 19, 2017 2:19 pm Post subject: |
|
|
Thank you all for your answers. However, I see many suggestions to try things which I already outlined in my OP that I already tried, without success. I will respond briefly to each suggestion.
@LIsLinuxIsSogood
> Did you check that openrc script? What runlevel in openrc calls it...
Do you mean "init.d/hwclock" Yes, that script runs at runlevel "boot".
==
# rc-status -a
[...]
Runlevel: boot
hwclock [ started ]
[...]
==
> Check this part of handbook out it is important. If you followed that, then it mentions the thing about certain issues with GMT-8 versus GMT+8
Yes, I followed the handbook. My timezone is set correctly:
==
# zdump /etc/localtime
/etc/localtime Tue Dec 19 09:05:17 2017 -05
==
> emerge --config sys-libs/timezone-data
Yes, I did that. See above.
> But also you have to try to include some system output
I have included system output throughout all my posts. Did you not see that? Inside the "code" tags? In this post, I have marked system output with: ==
@The Doctor
> The clock is already local time so setting a correction (+/-) for the timezone is superfluous.
I tried NeddySeagon's suggestion, it did not work. If I use /usr/share/zoneinfo/localtime, then my software clock gets set to GMT. My hardware clock remains correct:
==
xps:root@/etc# emerge --config sys-libs/timezone-data
Ready to configure sys-libs/timezone-data-2017c? [Yes/No] y
* Updating /etc/localtime with /usr/share/zoneinfo/localtime
xps:root@/etc# date && date -u && /etc/init.d/hwclock show
Mon Dec 18 22:50:43 GMT 2017
Mon Dec 18 22:50:43 UTC 2017
2017-12-18 17:50:42.810935+0000
==
@Fitzcarraldo
I have followed that procedure already. My hardware clock is configured correctly to local time. My software clock is configured correctly to local time. On boot, it seems like the software clock gets applied the timezone offset twice.
@krinn
Thank you, that is interesting. I will take a look. However, to me, it seems the problem is actually the following:
1. I start with a correctly configured date and time. Say, it is 10:00 AM local time (UTC-5). My software clock and my hardware clock are configured to show 10:00 AM local time.
2. I reboot.
3. On startup, the system sets the software clock. I am not sure who does that, I guess the kernel? The system sees it is 10:00, but fails to see that this is local time already. So, the system applies -5 hours and arrives at 05:00, which is then set as the software clock.
Do you have any information about this step 3? Am I right that this happens in the kernel? Do you know how I could debug this problem? |
|
| Back to top |
|
|
mgwolff
n00b
Joined: 18 Dec 2017
Posts: 33
|
| Posted: Tue Dec 19, 2017 3:48 pm Post subject: |
|
|
| Out of curiosity, I added some "printk" statements to the kernel's time.c file. It seems that do_sys_settimeofday64 function is only called when you use the "hwclock" command. So, where does the initial time setting happen? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Tue Dec 19, 2017 8:40 pm Post subject: |
|
|
mgwolff,
There is a kernel option to do it
| Code: | │ CONFIG_RTC_HCTOSYS: │
│ │
│ If you say yes here, the system time (wall clock) will be set using │
│ the value read from a specified RTC device. This is useful to avoid │
│ unnecessary fsck runs at boot time, and to network better. │
│ │ |
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
mgwolff
n00b
Joined: 18 Dec 2017
Posts: 33
|
| Posted: Tue Dec 19, 2017 10:22 pm Post subject: |
|
|
NeddySeagon, thank you, but unfortunately I have tried hat kernel option and it does not help either  |
|
| Back to top |
|
|
mgwolff
n00b
Joined: 18 Dec 2017
Posts: 33
|
| Posted: Wed Dec 20, 2017 5:43 am Post subject: |
|
|
I just noticed the following in dmesg:
[ 2.146523] rtc_cmos 00:02: setting system clock to 2017-12-19 23:34:44 UTC (1513726484)
The time is not in UTC as stated by the message, but in local time. Is that the case for anyone else? |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Wed Dec 20, 2017 11:28 am Post subject: |
|
|
| mgwolff wrote: | I just noticed the following in dmesg:
[ 2.146523] rtc_cmos 00:02: setting system clock to 2017-12-19 23:34:44 UTC (1513726484)
The time is not in UTC as stated by the message, but in local time. Is that the case for anyone else? |
No, it's UTC for me
| Code: | [ 0.441677] rtc_cmos 00:02: setting system clock to 2017-12-20 11:12:36 UTC (1513768356)
date -u && date
mer. déc. 20 11:31:52 UTC 2017
mer. déc. 20 12:31:52 CET 2017
|
|
|
| Back to top |
|
|
mgwolff
n00b
Joined: 18 Dec 2017
Posts: 33
|
| Posted: Wed Dec 20, 2017 2:19 pm Post subject: |
|
|
| krinn wrote: |
No, it's UTC for me
| Code: | [ 0.441677] rtc_cmos 00:02: setting system clock to 2017-12-20 11:12:36 UTC (1513768356)
date -u && date
mer. déc. 20 11:31:52 UTC 2017
mer. déc. 20 12:31:52 CET 2017
|
|
Interesting! Do you have your BIOS clock set to local time? You can check that in the BIOS or by running:
| Code: |
# hwclock --show --debug | grep Hardware
Hardware clock is on local time
Time read from Hardware Clock: 2017/12/20 09:18:17
Calculated Hardware Clock drift is 0.000000 seconds
|
|
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Wed Dec 20, 2017 4:25 pm Post subject: |
|
|
Can even gave you all
| Code: | LC_ALL=C hwclock --show --debug
hwclock from util-linux 2.30
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1208561590 seconds after 1969
Last calibration done at 1208477788 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: 2017/12/20 16:27:14
Hw clock time : 2017/12/20 16:27:14 = 1513783634 seconds since 1969
Time since last adjustment is 305222044 seconds
Calculated Hardware Clock drift is -4744.665737 seconds
2017-12-20 16:27:13.671556+0100
|
|
|
| Back to top |
|
|
mgwolff
n00b
Joined: 18 Dec 2017
Posts: 33
|
| Posted: Wed Dec 20, 2017 4:41 pm Post subject: |
|
|
| krinn wrote: | Can even gave you all
|
Thanks! I just installed Gentoo again on my old laptop, but same problem now there too. 
Could you also show me your "emerge --info"? How long ago did you set up your Gentoo system? |
|
| Back to top |
|
|
|
Other Things Gentoo
