Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] hwclock out of sync with ntpd
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
ixuz
n00b
n00b


Joined: 01 Jun 2009
Posts: 41

PostPosted: Tue Apr 06, 2021 7:14 pm    Post subject: [SOLVED] hwclock out of sync with ntpd Reply with quote

Hello,

my timezone is Europe/Berlin (for today this means UTC+2).

Whenever I set "hwclock --systohc --utc" my hwclock gets 2 hours added within 11 minutes after that change due to NTP daemon.

If I use "hwclock --systohc --local" the hwclock stays correct (but local, not UTC). But why is NTPD adding these two hours when using UTC?

I want to use UTC since after every boot I get an error message

Code:

Superblock last mount time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set) FIXED.


while using local time.


Last edited by ixuz on Sat Apr 10, 2021 7:02 pm; edited 1 time in total
Back to top
View user's profile Send private message
pietinger
l33t
l33t


Joined: 17 Oct 2006
Posts: 652
Location: Bavaria

PostPosted: Tue Apr 06, 2021 7:57 pm    Post subject: Reply with quote

Maybe this can help:
https://wiki.gentoo.org/wiki/System_time#In-kernel_method
Back to top
View user's profile Send private message
ixuz
n00b
n00b


Joined: 01 Jun 2009
Posts: 41

PostPosted: Tue Apr 06, 2021 8:16 pm    Post subject: Reply with quote

I am using gentoo-kernel-bin. I will not build a new kernel for this. Besides I don't understand, how this will help with NTPd changes hwclock on his own wrongly.

Maybe for a better understanding how the results are:

With synced hwclock <--> sysclock LOCAL I get the following results:

Code:

~ # date
Di 6. Apr 20:08:51 CEST 2021
~ # hwclock
2021-04-06 20:08:58.013928+02:00


With synced hwclock <--> sysclock UTC I get the following results:

Code:

~ # date
Di 6. Apr 20:08:51 CEST 2021
~ # hwclock
2021-04-06 22:08:58.013928+02:00


So hwclock UTC ends up 2 hours in the future...
Back to top
View user's profile Send private message
pietinger
l33t
l33t


Joined: 17 Oct 2006
Posts: 652
Location: Bavaria

PostPosted: Tue Apr 06, 2021 10:29 pm    Post subject: Reply with quote

1. What is your actual time in BIOS ? Is it UTC ? If not: Set it to UTC !
2. You said your timezone is set correct to Berlin; did you also an "emerge --config sys-libs/timezone-data" after this setting ? If not, ... do it.
3. What happens if you do then a "ntpd -q -g" and then "date" ?

(This is step 2, 5 and 6 from here: https://forums.gentoo.org/viewtopic-t-1112800.html )

If you have now the correct time, set all to UTC for your ntpd (I am using ntp-client).
Back to top
View user's profile Send private message
ixuz
n00b
n00b


Joined: 01 Jun 2009
Posts: 41

PostPosted: Wed Apr 07, 2021 9:19 am    Post subject: Reply with quote

I did this already. I can write UTC time to RTC but the NTP daemon writes after a couple of minutes everytime the LOCAL time back to RTC while it should write UTC time to RTC. I just don't know how to tell NTPd to write the UTC time to RTC and NOT the LOCAL time...
Back to top
View user's profile Send private message
trilithium
n00b
n00b


Joined: 18 Nov 2019
Posts: 12

PostPosted: Wed Apr 07, 2021 11:02 am    Post subject: Reply with quote

It is the kernel that is setting the RTC, not ntpd. Your kernel is compiled with CONFIG_RTC_SYSTOHC=y and will therefore set the RTC to the system time every 11 minutes if the system clock is marked as synchronized. The synchronization flag is set by ntpd once it feels confident that the clock is actually synchronized via NTP.

Be careful how you interpret the output of hwclock. It always prints local time but does not know whether your RTC is set to local time or UTC. You can use the --utc command line option to ensure that hwclock interprets RTC time as UTC.
Back to top
View user's profile Send private message
ixuz
n00b
n00b


Joined: 01 Jun 2009
Posts: 41

PostPosted: Wed Apr 07, 2021 11:11 am    Post subject: Reply with quote

Yeah thanks, in the meantime I read too that the kernel makes this "11 minute mode".

So if local time is copied to RTC it should copy my local time-2hours. But this is not happening.

hwclock should show localtime-2hours (which is UTC) OR localtime (include timezone) but NOT UTC+2hours+2hours...
Back to top
View user's profile Send private message
Fitzcarraldo
Veteran
Veteran


Joined: 30 Aug 2008
Posts: 1916
Location: United Kingdom

PostPosted: Wed Apr 07, 2021 1:03 pm    Post subject: Reply with quote

Just to check, when configuring your installation did you do either of the following?

Either:
Code:
# ln -s /usr/share/zoneinfo/Europe/Berlin /etc/localtime

or (my preference):
Code:
# cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime

The clock configuration steps I use (first section covers OpenRC, the second section covers systemd): Configuring the Linux clock.
_________________
Clevo W230SS: amd64 nvidia-drivers & xf86-video-intel.
Compal NBLB2: ~amd64 xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC eudev elogind & KDE on both.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
ixuz
n00b
n00b


Joined: 01 Jun 2009
Posts: 41

PostPosted: Wed Apr 07, 2021 1:22 pm    Post subject: Reply with quote

I did copy it.

One interesting thing: Since this is a (home)server I did never reboot after changing from local time to UTC. Is this mandatory?
Back to top
View user's profile Send private message
pietinger
l33t
l33t


Joined: 17 Oct 2006
Posts: 652
Location: Bavaria

PostPosted: Wed Apr 07, 2021 6:17 pm    Post subject: Reply with quote

ixuz wrote:
One interesting thing: Since this is a (home)server I did never reboot [...]

So, you have not been in your BIOS as I told you ...

ixuz wrote:
Is this mandatory?

No.


If you really want a correct time you should remove "hwclock" AND "ntpd" from your runlevel (rc-update del ...) and then do what I have told you. Then the first thing is to check your time with "date". If it is wrong then you missed ONE of three points:

1. BIOS time is UTC
2. missing: "cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime"
3. missing: "emerge --config sys-libs/timezone-data"

If your time is correct then check your /etc/conf.d/ntpd before your start your ntpd again.
Back to top
View user's profile Send private message
ixuz
n00b
n00b


Joined: 01 Jun 2009
Posts: 41

PostPosted: Wed Apr 07, 2021 7:06 pm    Post subject: Reply with quote

Sorry but this is nonsense. No other distro needs to set the time in the UEFI/BIOS. (eg. Arch, Manjaro, Ubuntu - all systemd btw and not OpenRC).

Setting the hwclock in non-systemd distros is normally done via "hwclock --systohc", that is the same as setting the clock in Bios. If you attach --utc or --local to that command, the RTC is set appropriate and creates the /etc/adjtime file.

Step 2 and 3 are already done.
Back to top
View user's profile Send private message
pietinger
l33t
l33t


Joined: 17 Oct 2006
Posts: 652
Location: Bavaria

PostPosted: Wed Apr 07, 2021 7:58 pm    Post subject: Reply with quote

ixuz wrote:
[...] done via "hwclock --systohc", that is the same as setting the clock in Bios. If you attach --utc or --local to that command, the RTC is set appropriate and creates the /etc/adjtime file.

So you have done "hwclock --systohc --utc --noadjfile" after reading the manpage from hwclock ?
Back to top
View user's profile Send private message
ixuz
n00b
n00b


Joined: 01 Jun 2009
Posts: 41

PostPosted: Thu Apr 08, 2021 8:29 am    Post subject: Reply with quote

I tried both:

hwclock --systohc --utc --noadjfile

hwclock --systohc --utc

It made no difference. Without the adjust file UTC is default.
Back to top
View user's profile Send private message
pietinger
l33t
l33t


Joined: 17 Oct 2006
Posts: 652
Location: Bavaria

PostPosted: Thu Apr 08, 2021 11:38 am    Post subject: Reply with quote

The reason why I recommended to set in BIOS is: You will see what you HAVE in it BEFORE you set a new time ... (I think it is UTC+2h).
Back to top
View user's profile Send private message
freke
l33t
l33t


Joined: 23 Jan 2003
Posts: 624
Location: Somewhere in Denmark

PostPosted: Thu Apr 08, 2021 6:06 pm    Post subject: Reply with quote

Doesn't
Code:
hwclock --systohc --utc
mean: Take the current system time (ie. Di 6. Apr 20:08:51 2021) save it to the RTC assuming the time given is UTC (the hwclock/RTC it self doesn't know anything of timezones).
Then when you load the hwclock to system again - assuming the time stored in RTC is in UTC you will be two hours ahead?

Do you have hwclock enabled in any runlevels? (the guide says not to, when having CONFIG_RTC_SYSTOHC=y in kernel)

I'm using the CONFIG_RTC_SYSTOHC=y to synchronize my hwclock and works without issues for me with NTPd.
Back to top
View user's profile Send private message
ixuz
n00b
n00b


Joined: 01 Jun 2009
Posts: 41

PostPosted: Sat Apr 10, 2021 9:00 am    Post subject: Reply with quote

Finally I was able to set my hwclock to UTC.

The thing is, if your system is running with RTC set to local and you have these Kernel options set:

Code:

# CONFIG_RTC_SYSTOHC is not set
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"


you need to restart your system, to make the Kernel aware of the new time mode.

The man page from hwclock gives a hint:

Quote:

--systz
This is an alternate to the --hctosys function that does not read the Hardware Clock nor set the System Clock; consequently there is not any drift correction. It is intended to be used in a startup script on systems with kernels above version 2.6 where you
know the System Clock has been set from the Hardware Clock by the kernel during boot.

It does the following things that are detailed above in the --hctosys function:

o Corrects the System Clock timescale to UTC as needed. Only instead of accomplishing this by setting the System Clock, hwclock simply informs the kernel and it handles the change.

o Sets the kernel's NTP '11 minute mode' timescale.

o Sets the kernel's timezone.

The first two are only available on the first call of settimeofday(2) after boot. Consequently this option only makes sense when used in a startup script. If the Hardware Clocks timescale configuration is changed then a reboot would be required to inform the
kernel.


conf.d/hwclock:

Code:

clock="UTC"
clock_systohc="YES"
clock_hctosys="YES"


OpenRCs rc.log confirms, that the time on boot start is now correct.

Steps to change from local time to UTC for RTC (hwclock):

1. Change hwclock settings to UTC like above.
2. Execute "hwclock --systohc --utc" and immediately reboot to give the Kernel no chance to set the hwclock wrongly again.
Back to top
View user's profile Send private message
trilithium
n00b
n00b


Joined: 18 Nov 2019
Posts: 12

PostPosted: Sat Apr 10, 2021 12:07 pm    Post subject: Reply with quote

Thanks for letting us know what you needed to do to resolve the issue! I've been pondering over it the last few days, trying to figure out what could cause this error. The settimeofday(2) man page offers this interesting nugget:

Quote:
Under Linux, there are some peculiar "warp clock" semantics associated with the settimeofday() system call if on the very first call (after booting) that has a non-NULL tz argument, the tv argument is NULL and the tz_minuteswest field is nonzero. (The tz_dsttime field should be zero for this case.) In such a case it is assumed that the CMOS clock is on local time, and that it has to be incremented by this amount to get UTC system time.
No doubt it is a bad idea to use this feature.


Yikes! Time (and especially time zone) code is full of sharp edges like this.
Back to top
View user's profile Send private message
ixuz
n00b
n00b


Joined: 01 Jun 2009
Posts: 41

PostPosted: Sat Apr 10, 2021 7:00 pm    Post subject: Reply with quote

Well, I think this is the best explanation what was going on since I was always using hwclock script for setting local time from RTC on boot.

From hwclock man page:

Quote:

-s, --hctosys
[...]
When used in a startup script, making the --hctosys
function the first caller of settimeofday(2) from boot, it
will set the NTP '11 minute mode' timescale via the
persistent_clock_is_local kernel variable. If the
Hardware Clock's timescale configuration is changed then a
reboot is required to inform the kernel.
See the
discussion below, under Automatic Hardware Clock
Synchronization by the Kernel.
[...]
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
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