I rebooted my fedora 37 VM, and 1 application started to dispaly the following error
Warning: Error fetching server time: Detected 50496.27999997139 seconds time difference between your browser and the server.
I discovered that day date was 1 day behind, so today is October 6 and in fedora UI I see October 5th. I tried to chnage it manually but it was not possible even when I log as root.
When I issue timedatectl status
> Local time: Thu 2023-10-05 20:58:11 CEST
Universal time: Thu 2023-10-05 18:58:11 UTC
RTC time: Thu 2023-10-05 18:55:04
Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
I tried timedatectl set-local-rtc 0
but it did not help.
As indicated this happened suddenly and datetime was Ok for more than 2 years. So what might changed or lead to this behavior and how can I fix it?
Thanks in advance
Many systems have a hardware clock powered by a small battery when the system is off. Check the user manual to see if your system uses such a battery and find out how to replace it. If you can remove the battery and have access to a voltmeter you can check that it provides the correct voltage. In my experience, clock problems occur when the voltage is substantially lower than the rated value. You also find that replacing the battery resets BIOS options if you are not using defaults.
Oct 05 14:33:39 fedora chronyd: chronyd version 4.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS >
Oct 05 14:33:39 fedora chronyd: Frequency 12.258 +/- 1.217 ppm read from /var/lib/chrony/drift
Oct 05 14:33:39 fedora chronyd: Using right/UTC timezone to obtain leap second data
Oct 05 14:33:39 fedora chronyd: Loaded seccomp filter (level 2)
Oct 05 14:33:40 fedora systemd: Started chronyd.service - NTP client/server.
Oct 05 14:33:53 fedora.salam.net chronyd: Selected source 18.104.22.168 (mafreebox.free.fr)
Oct 05 14:33:53 fedora.salam.net chronyd: System clock TAI offset set to 37 seconds
Oct 05 20:12:22 fedora.salam.net chronyd: Can’t synchronise: no selectable sources
Oct 05 20:17:45 fedora.salam.net chronyd: Selected source 22.214.171.124 (mafreebox.free.fr)
Oct 05 20:17:45 fedora.salam.net chronyd: System clock wrong by 50593.841437 seconds
Looks like the journal message showing right/UTC comes from chrony.conf
# Get TAI-UTC offset and leap seconds from the system tz database.
which means leap second days have more that 24hr worth of seconds. I guess everything in fedora can handle it which is great.
Is this a qemu-kvm guest? Do you run qemu-guest-agent services in your guests? What I’ve read recommends runing ntp in guests but the clock sync that happens with qemu-ga may solve this issue.
Otherwise installing/configuring ntpdate.service may help in your case. Since ntpdate sets the clock imediately and chronyd.service does not start until after ntpdate, if there is a skew on boot it will be reset during boot. It seems logical to me that the same could be done with chrony but I did not find any examples. Authoring a custom service maybe?
That chrony converged the system to the correct time even with a large initial skew is pretty amazing. I don’t know if systemd-timesyncd or ntpd or any other ntp client does any differently. The chrony project claims they do it better in that 2015 FAQ.
From the log it looks like something has stepped the VM’s clock while it was running. chronyd in the default configuration is allowed to correct the clock by step only on start. If something disturbs the clock later, chronyd would try to correct it slowly be slewing, but with such a large offset it would take few weeks to correct. If you cannot find and fix the problem that caused the clock step, you might need to allow chronyd to correct by step at any time by changing makestep in chrony.conf to 1 -1.