Time synchronization is slow when system starts up every time
Hello, This little weird problem has confused me for some time, but I can't find any related situation from Google. Since quite some time ago when I boot up, the system time is never correct at first. It shows the date which is a month or two before, and the time is always 8am. But after 3-4 mins the system time becomes normal and accurate again. So every time when I logged into the system and opened a browser window immediately, the browsers would give a NET::ERR_CERT_DATE_INVALID complaint. It looks like it's something related to the NTP daemon. I am using Network manager under Plasma desktop with WiFi enabled. I'm not sure if only after Network Manager starts up my wifi then the NTP daemon begins to sync time, which in turn causes this problem? But this set up is quite common and I couldn't find any similar cases from other users, so maybe there's another reason? Thanks in advance. Regards, Charlie
On 20.08.22 06:28, Charlie Chan wrote:
Hello,
Since quite some time ago when I boot up, the system time is never correct at first.
Did you check/replace that systems BIOS battery allready ? The system will use the time from its battery backed up clock until it is syncronized by NTP. And if this time is far off, syncronizing will last longer .
On 2022-08-20 06:28, Charlie Chan wrote:
Hello,
This little weird problem has confused me for some time, but I can't find any related situation from Google.
Since quite some time ago when I boot up, the system time is never correct at first. It shows the date which is a month or two before, and the time is always 8am. But after 3-4 mins the system time becomes normal and accurate again. So every time when I logged into the system and opened a browser window immediately, the browsers would give a NET::ERR_CERT_DATE_INVALID complaint.
It looks like it's something related to the NTP daemon. I am using Network manager under Plasma desktop with WiFi enabled. I'm not sure if only after Network Manager starts up my wifi then the NTP daemon begins to sync time, which in turn causes this problem? But this set up is quite common and I couldn't find any similar cases from other users, so maybe there's another reason?
Thanks in advance.
The problem is the CMOS clock that keeps the time while the machine is switched off; yours must be a month off. Now this is a bit strange, because with a dead battery it would be years off. And if the battery is OK, it should be adjusted to the correct time when ntp syncs. So check the battery with a meter if you have it. Or: sensors | grep -i bat (if that doesn't work, run first "sensors-detect") On my desktop machine: cer@Telcontar:~> sensors | grep -i bat Vbat: +3.31 V (min = +2.70 V, max = +3.63 V) cer@Telcontar:~> Then try these commands in sequence to reset the cmos clock: rm /etc/adjtime (or rename) hwclock --utc --systohc hwclock date On next reboot, time should be Ok. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
I had a similar issue running Tumbleweed on a Raspberry Pi, which has no battery-backed time of day clock. After reading the systemd.special man page, I found that enabling the systemd-timesyncd service resolved my problem. David On 8/20/22 6:40 AM, Carlos E. R. wrote:
On 2022-08-20 06:28, Charlie Chan wrote:
Hello,
This little weird problem has confused me for some time, but I can't find any related situation from Google.
Since quite some time ago when I boot up, the system time is never correct at first. It shows the date which is a month or two before, and the time is always 8am. But after 3-4 mins the system time becomes normal and accurate again. So every time when I logged into the system and opened a browser window immediately, the browsers would give a NET::ERR_CERT_DATE_INVALID complaint.
It looks like it's something related to the NTP daemon. I am using Network manager under Plasma desktop with WiFi enabled. I'm not sure if only after Network Manager starts up my wifi then the NTP daemon begins to sync time, which in turn causes this problem? But this set up is quite common and I couldn't find any similar cases from other users, so maybe there's another reason?
Thanks in advance.
The problem is the CMOS clock that keeps the time while the machine is switched off; yours must be a month off.
Now this is a bit strange, because with a dead battery it would be years off. And if the battery is OK, it should be adjusted to the correct time when ntp syncs.
So check the battery with a meter if you have it. Or:
sensors | grep -i bat
(if that doesn't work, run first "sensors-detect")
On my desktop machine:
cer@Telcontar:~> sensors | grep -i bat Vbat: +3.31 V (min = +2.70 V, max = +3.63 V) cer@Telcontar:~>
Then try these commands in sequence to reset the cmos clock:
rm /etc/adjtime (or rename) hwclock --utc --systohc hwclock date
On next reboot, time should be Ok.
On 2022-08-20 19:19, David Walker wrote:
I had a similar issue running Tumbleweed on a Raspberry Pi, which has no battery-backed time of day clock. After reading the systemd.special man page, I found that enabling the systemd-timesyncd service resolved my problem.
I'm not sure if having both ntpd and systemd-timesyncd is a good idea. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Sat, Aug 20, 2022 at 12:28 AM Charlie Chan
Hello,
This little weird problem has confused me for some time, but I can't find any related situation from Google.
The battery that powers your RTC is defective. replace it. Then either install and start chrony or start a simple sntp client by starting the systemd-timesyncd service. The initial time of the system when your clock is hosed is initially set to systemd's epoch which is the value that SOURCE_DATE_EPOCH had at the time systemd was built.
Charlie, Am 20.08.22 um 06:28 schrieb Charlie Chan:
Hello,
This little weird problem has confused me for some time, but I can't find any related situation from Google.
Since quite some time ago when I boot up, the system time is never correct at first. It shows the date which is a month or two before, and the time is always 8am. But after 3-4 mins the system time becomes normal and accurate again. So every time when I logged into the system and opened a browser window immediately, the browsers would give a NET::ERR_CERT_DATE_INVALID complaint.
This sounds a little strange, I would go for the responses of Markus and Carlos first. I had a very similar issue with a new mainboard, the RTC was way off. I did quite some research to fix it, see below. But in the end, I did a BIOS update, and all was fine... The RTC can be adjusted by tick (coarse tuning) and frequency (fine tuning). The thing is, NTP is quite deficient, in that it can only adjust the frequency. So if your RTC is way off, NTP has problems. You then have to set the tick manually at startup (e.g. in /etc/init.d/boot.local) with adjtimex --tick xxxxx --frequency 0 With a correct tick set, NTP then is able to do its work. To find out the correct tick, you can run adjtimex --compare=50 -i 10 --host 0.pool.ntp.org and let it run for a while. If the suggested tick (second last column) is outside of a range of 9995..10005 or so you should consider setting the tick at startup, to help NTP to do its work. Cheers, Manfred
It looks like it's something related to the NTP daemon. I am using Network manager under Plasma desktop with WiFi enabled. I'm not sure if only after Network Manager starts up my wifi then the NTP daemon begins to sync time, which in turn causes this problem? But this set up is quite common and I couldn't find any similar cases from other users, so maybe there's another reason?
Thanks in advance.
Regards,
Charlie
Thank you for all the answers.
Actually Markus has pointed to the right direction, the CMOS battery is out of power. That’s also why I have to switch on secure boot every time even I set it on before.
Just can’t think of this since it’s a relatively new machine (2 years), but it’s been off for some time so that’s why the battery drains so quickly.
Anyway thank you again for all the help.
________________________________
From: Manfred Schwarb
Hello,
This little weird problem has confused me for some time, but I can't find any related situation from Google.
Since quite some time ago when I boot up, the system time is never correct at first. It shows the date which is a month or two before, and the time is always 8am. But after 3-4 mins the system time becomes normal and accurate again. So every time when I logged into the system and opened a browser window immediately, the browsers would give a NET::ERR_CERT_DATE_INVALID complaint.
This sounds a little strange, I would go for the responses of Markus and Carlos first. I had a very similar issue with a new mainboard, the RTC was way off. I did quite some research to fix it, see below. But in the end, I did a BIOS update, and all was fine... The RTC can be adjusted by tick (coarse tuning) and frequency (fine tuning). The thing is, NTP is quite deficient, in that it can only adjust the frequency. So if your RTC is way off, NTP has problems. You then have to set the tick manually at startup (e.g. in /etc/init.d/boot.local) with adjtimex --tick xxxxx --frequency 0 With a correct tick set, NTP then is able to do its work. To find out the correct tick, you can run adjtimex --compare=50 -i 10 --host 0.pool.ntp.org and let it run for a while. If the suggested tick (second last column) is outside of a range of 9995..10005 or so you should consider setting the tick at startup, to help NTP to do its work. Cheers, Manfred
It looks like it's something related to the NTP daemon. I am using Network manager under Plasma desktop with WiFi enabled. I'm not sure if only after Network Manager starts up my wifi then the NTP daemon begins to sync time, which in turn causes this problem? But this set up is quite common and I couldn't find any similar cases from other users, so maybe there's another reason?
Thanks in advance.
Regards,
Charlie
On Sunday 2022-08-21 16:15, Manfred Schwarb wrote:
So if your RTC is way off, NTP has problems.
Yes but also no. If it's too far off, time synchronization mechanisms usually will just hard-step it within 2-3 minutes after knowing the reference time (because people want to move on and not wait for time smearing to complete). And if you have long running machines, a weak NVRAM battery won't be an issue until you power off the system and (depending on model) also make standby impossible.
participants (7)
-
Carlos E. R. -
Charlie Chan -
Cristian Rodríguez -
David Walker -
Jan Engelhardt -
Manfred Schwarb -
Markus Koßmann