2

My computer runs 24/7 and does an automatic reboot at night after each kernel/systemd/glibc upgrade. On Fedora this happens every few days.

The system clock is synchronized with NTP protocol using the chrony. The HW clock is synchronized:

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

and normally I see no difference between system time and HW clock.

But after a reboot:

28.02.2021 00:34:08.657 chronyd: System clock wrong by -4.021024 seconds

or this night:

mar 02 01:48:18 chronyd[990]: chronyd exiting
mar 02 01:48:18 systemd[1]: Stopped NTP client/server.
-- Reboot --
mar 02 01:49:37 systemd[1]: Starting NTP client/server...
mar 02 01:49:37 chronyd[989]: chronyd version 4.0 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
mar 02 01:49:37 chronyd[989]: Frequency -13.026 +/- 0.008 ppm read from /var/lib/chrony/drift
mar 02 01:49:37 chronyd[989]: Using right/UTC timezone to obtain leap second data
mar 02 01:49:37 systemd[1]: Started NTP client/server.
mar 02 01:49:51 chronyd[989]: Selected source 162.159.200.123 (hu.pool.ntp.org)
mar 02 01:49:51 chronyd[989]: Time smoothing activated (leap seconds only)
mar 02 01:49:51 chronyd[989]: System clock wrong by -9.232765 seconds
mar 02 01:49:42 chronyd[989]: System clock was stepped by -9.232765 seconds

If I manually stop the chrony, wait 2 minutes and restart it, nothing bad happens (as expected).

I searched the net a lot and read many posts, but still cannot understand what I'm doing wrong.

UPDATE, output of timedatectl:

               Local time: St 2021-03-03 14:11:27 CET    
           Universal time: St 2021-03-03 13:11:27 UTC    
                 RTC time: St 2021-03-03 13:11:27        
                Time zone: Europe/Bratislava (CET, +0100)
System clock synchronized: yes                           
              NTP service: active                        
          RTC in local TZ: no  

Output of hwclock --verbose:

hwclock from util-linux 2.36.1
System Time: 1614784382.362288
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2021/03/03 15:13:03
Hw clock time : 2021/03/03 15:13:03 = 1614784383 seconds since 1969
Time since last adjustment is 1614784383 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2021-03-03 16:13:02.344795+01:00

systemd-timesyncd is disabled and inactive.

8
  • Wild guess: The battery of the computer's hardware clock is tired or empty. The clock gets no power for a short while when the computer reboots, thus the delay. If you can afford a few minutes down time, switch the box off for the time of a coffee and see if the delay is several minutes. CAVEAT: I have no idea if my musings have any resemblance with reality. – berndbausch Mar 3 at 8:44
  • And I don't think you are doing anything wrong. NTP was created precisely to compensate for such problems. Reliable hardware clocks are not necessarily a huge priority for hardware designers. – berndbausch Mar 3 at 8:46
  • @Philip Couling Is says that Fedora is used. So, there is no dpkg, but rpm or yum or dnf. However, systemd-timesyncd RPM package is available for Fedora, too. – nobody Mar 3 at 11:02
  • @berndbausch I don't suspect a battery problem. It is a backup battery, the computer is powered all the time and BIOS settings in the CMOS are not lost. – VPfB Mar 3 at 13:01
  • 1
    @PhilipCouling I checked, It is installed, but disabled. I have even checked that the file /var/lib/systemd/timesync/clock does not exsit, not even the directory. – VPfB Mar 3 at 15:21
0

Try command

timedatectl

to see if RTC clock is ever adjusted, or is off the whole time. You can also use hwclock or similar commands.

For the ntpd service, which is now being deprecated and replaced in many newer distributions, I know that it wrote a drift file on the disk on shutdown, and set the HW clock to the correct time. In the drift file, there were information about system clock accuracy, shutdown time, etc. When you switched on the computer ntpd would check the drift file, and adjusted the system clock according to recorded drift to synchronize quicker.

chrony synchronizes much quicker than ntpd, as that is a need for more and more virtual machines, that do now have a hardware clock. I wonder if chrony adjusts the HW clock on shutdown. Maybe you should check if the discrepancy is only growing. In that case it would be sensible to set HW clock at least on shutdown or see why the system does not adjust HW clock.

Maybe there is some HW problem. I had the strangest case some years ago, when a computer's time was off for about 17 seconds in one minute. The problem was to many HW interrupts, for which I first suspected some special PCI card. It turned out that KVM switch supported some kind of sound via USB, where keyboard and mouse were transferred, too. Without that KVM switch everything worked fine.

2
  • Thank you for you answer, I will go throug your suggestions. So far I checked that /var/lib/chrony/drift exists and is less than an hour old. I deleted /etc/adjtime some time ago. it was not updated for months. It did not help. – VPfB Mar 3 at 13:05
  • 1
    @Philip Couling You are right. System clock drift is recorded in drift file in order to perform quicker snychronization after reboot. I have corrected the answer. Thanks for the correction. – nobody Mar 3 at 16:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.