Description of problem:
Migrating from F31 to F33 using dnf upgrade, I had the clock set wrong times to times.
Never seen that before.
After investigating, the /etc/chrony.conf had two server defined as default one in my company (propagated through DHCP?)
One is never reachable though external network
The second one is working but slow.
# head /etc/chrony.conf
# These servers were defined in the installation:
server bind.int.company.com iburst
server ha-ntp.company.com iburst
Version-Release number of selected component (if applicable):
I don't know the configuration file content before the upgrade but I never get this time glitch before (30 minutes this morning.)
Steps to Reproduce:
1. have a working fedora
2. do a dnf upgrade under a network propagating a default NTP service
3. check is the configuration file has changed
same config file?
I can't see anything related to "default network configuration" on the chrony release notes. Clearly, for a laptop we should probably not use a "local" configuration by default.
here is a log of chrony, where I worked at my company office and then go home (without rebooting)
oct. 11 20:04:01 zeta chronyd: Source 192.168.2.220 online
oct. 11 20:04:01 zeta chronyd: Source 220.127.116.11 online
oct. 11 20:04:05 zeta chronyd: Selected source 18.104.22.168 (REDACTED)
oct. 11 21:02:50 zeta chronyd: Source 192.168.2.220 offline
oct. 11 21:02:50 zeta chronyd: Can't synchronise: no selectable sources
oct. 11 21:02:50 zeta chronyd: Source 22.214.171.124 offline
oct. 12 08:16:45 zeta chronyd: Forward time jump detected!
oct. 12 08:16:45 zeta chronyd: Source 192.168.2.220 online
oct. 12 08:16:45 zeta chronyd: Source 126.96.36.199 online
oct. 12 08:16:49 zeta chronyd: Selected source 188.8.131.52 (REDACTED)
Can we somehow notify the user when "no selectable sources"? I enabled network time usage un gnome settings
In fact the clock was back once I started the VPN (192.168.2.220 online)
The log shows two NTP sources and no large offsets. Are the two sources the sources specified in chrony.conf? Can you please explain what you mean by "local" and how is the clock set wrong?
FWIW, the defaults have not changed. By default, chronyd uses NTP servers provided by DHCP. They should be printed by the "chronyc -n sources" command. Before chrony-4.0, those sources were loaded by chronyc and this could be disabled only by adding PEERNTP=no to /etc/sysconfig/network. With chrony-4.0, these sources are loaded by the sourcedir directive in chrony.conf, and they can be disabled by removing that directive or adding PEERNTP=no to /etc/sysconfig/network.
Ok thank you for your feedback.
I don't have the previous chrony.conf configuration and from your answer I get that it didn't change after an upgrade.
Therefore this ticket is invalid.
Thank you for confirming that chrony takes NTP servers from DHCP answer. That might be why the NTP server are now "local".
By local I mean they are propagated through though my company DHCP server. One is not accessible from outside the company and the other one is but not always reachable.
From what I understand, the configuration might have changed (F31 -> F33 chrony 3.5-> chrony 4.0). I haven't found this information in the (chrony) release notes but I trust this information to be available.
I just found another clue today. Even if the chrony NTP servers configuration changed, my laptop should still have a quite accurate time.
Firstly I though it was because time to times the local network ntp server was reachable once I started the VPN...
But today I found that my system clock was good, "date" command returning good value.
In fact, the gnome-shell clocks was the one being out of date (at least 40 minutes behind). And this clock appear to be updating sometimes to the rigth value.
Now that I have a better ntp server configurations I can pinpoint a bit more the issue.
You can probably close this as not an issue. I'll see to open a ticket against gnome-shell and ask there how to investigate further (I already got this issue years ago.. like BZ#674884)
The chrony configuration changed (it's now using the sourcedir directive as mentioned in the previous comment), but the functionality with respect to the servers provided by DHCP shouldn't change. There is an issue with selinux-policy (bug #1880948), which causes the new chrony to not get the servers from DHCP, but I'm not sure if that would explain the issue you have.
In any case, if you can get more data or a reproducer for chrony, please reopen the bug.