Is Chrony kidding?

English Network/Internet
1

System time was stable here for years. This changed a few days ago. First trouble observed April 2.

**3400G:~ #** journalctl -b -u chronyd.service  
-- Logs begin at Fri 2021-04-02 11:23:29 CEST, end at Thu 2021-04-08 13:46:33 CEST. -- 
Apr 08 13:46:00 3400G systemd[1]: Starting NTP client/server... 
Apr 08 13:46:00 3400G chronyd[767]: chronyd version 3.5.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG) 
Apr 08 13:46:00 3400G chronyd[767]: Frequency -20.385 +/- 2.047 ppm read from /var/lib/chrony/drift 
Apr 08 13:46:00 3400G systemd[1]: Started NTP client/server. 
Apr 08 13:46:33 3400G chronyd[767]: Selected source **2a01:4f8:191:7327::1** 
Apr 08 13:46:33 3400G chronyd[767]: **System clock wrong by -7200.430651 seconds, adjustment started**
Apr 08 11:46:33 3400G chronyd[767]: **System clock was stepped by -7200.430651 seconds**
**3400G:~ #**

On several occasions no source is found at all or dubious servers are selected.

2

The only time I see something like that, is just after an install. The installer gets the time wrong.

In more detail: I do tell the installer to use UTC for the system clock. But, on a system with Windows, it sets the system clock to local time instead of to UTC. Since the installed configuration is good, this is fixed on the first boot. But that can involve a multi-hour time change on the first boot.

3

Hi
Check your CMOS battery… or an issue with RTC. I see this on my local RPi time (GPS/PPS) server I need to replace the battery in the RTC.

4

Battery was indeed bad on one machine. I replaced it 6 years after purchase.

However the errors occurred on the newer machine too. Thus I changed the pool on both machines:

**erlangen:~ #** cat /etc/chrony.d/pool.conf  
#pool 2.opensuse.pool.ntp.org iburst 
pool pool.ntp.org iburst 
**erlangen:~ #**
5

7200s = 2 hours.
Wrong time zone or daylight saving time.

6

Whatever caused the problems switching from 2.opensuse.pool.ntp.org to** pool.ntp.org** fixed the annoyance:

**3400G:~ #** journalctl -u chronyd.service --priority notice          
-- Logs begin at Wed 2021-04-07 08:07:41 CEST, end at Fri 2021-04-09 08:58:53 CEST. -- 
Apr 08 13:46:33 3400G chronyd[767]: **System clock wrong by -7200.430651 seconds, adjustment started**
Apr 08 11:46:33 3400G chronyd[767]: **System clock was stepped by -7200.430651 seconds**
**-- Reboot --**
Apr 08 22:55:54 3400G chronyd[794]: **System clock wrong by -3600.023896 seconds, adjustment started**
Apr 08 21:55:54 3400G chronyd[794]: **System clock was stepped by -3600.023896 seconds**
**-- Reboot --**
Apr 09 07:10:24 3400G chronyd[776]: **System clock wrong by 1.028037 seconds, adjustment started**
Apr 09 07:10:25 3400G chronyd[776]: **System clock was stepped by 1.028037 seconds**
**3400G:~ #**
7

Yes.
Another check is –

 # journalctl | egrep ': Selected source |: System clock wrong by |: System clock was stepped by '

This is sometimes fixed by “hwclock --systohc” to update the timestamps in /etc/adjtime – usually works for a while but, I notice that, this morning “System clock was stepped by 1.971613 seconds” occurred again …

  • My Mainboard was purchased new last year …

And, I use “pool de.pool.ntp.org iburst” …

8

Hi
Use ‘hwclock -vw --update-drift’

9

@karlmistelberger:

Ooops – just noticed that, I still have ‘/etc/chrony.d/pool.conf’ containing “pool 2.opensuse.pool.ntp.org iburst” – installed by the “chrony-pool-openSUSE” package – which requires the “chrony” package …

  • I’ll try to remove that package and then, black-list it …

[HR][/HR]Need to use YaST to remove the “chrony-pool-openSUSE” package – the next offering is the “chrony-pool-suse” – choose “chrony-pool-empty” …

  • When the removal and substitution completes, blacklist the openSUSE and SUSE chrony pool packages …
10

Hi
Just add a not… eg;


! pool 2.suse.pool.ntp.org iburst
11

Until the next time the “chrony-pool-openSUSE” package is updated – if the maintainer makes the “overwrite” decision, the change will be lost …

12

Hi
It should not, that’s why rpmconfigcheck should be run.