systemctl start chronyd.service fails to start when the NTP-Server from /var/lib/dhclient/chrony.servers.* is already present in /etc/chrony.conf So in the moment the same NTP-Server can't be part of /etc/chrony.conf and /var/lib/dhclient/chrony.servers.* I guess a better behavior would be to ignore that the NTP-Server is already present and then start chronyd.
A workaround is to set PEERNTP=no in /etc/sysconfig/network to ignore the NTP servers from DHCP. Proper fix will need to check and remember which servers were successfully added, so the server from chrony.conf is not removed on dhclient down event with others.
*** Bug 788935 has been marked as a duplicate of this bug. ***
chrony-1.26-4.20110831gitb088b7.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/chrony-1.26-4.20110831gitb088b7.fc16
Package chrony-1.26-4.20110831gitb088b7.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing chrony-1.26-4.20110831gitb088b7.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-1531/chrony-1.26-4.20110831gitb088b7.fc16 then log in and leave karma (feedback).
The patch fixed the problem but creates a new one :-), the file /var/lib/dhclient/chrony.added_servers grows, which means during startup even old NTP servers are added to chrony. I tried it, I switched the NTP-Servers which the DHCP-Server offers and chrony is now using the old and the new NTP-Servers side by side that's actually not what I want, the NTP-Servers which the DHCP-Server offers and the NTP-Servers from /etc/chrony.conf should be the only time source for the client. I guess it would be better to clear /var/lib/dhclient/chrony.added_servers with every startup of chrony? In the moment it's not a big problem, because I don't switch NTP-Servers daily :-).
Ignore my last comment, the file /var/lib/dhclient/chrony.added_servers grows (that's correct) but chrony is using only the NTP-Servers which the DHCP-Server offers and the NTP-Servers from /etc/chrony.conf. The problem was that I changed the NTP-Server in the DHCP-Server and then I simply restarted the NetworkManager on the client with service NetworkManager restart which in the end calls (I guess?) /etc/dhcp/dhclient.d/chrony.sh and the script just adds the new NTP-Server to chrony but service chronyd restart fixed the problem. Hmm… but what happens when the Client requests a new IP (without reboot) and the DHCP-Servers offers the same IP but a new NTP-Server? Does the DHCP request restarts chrony as well?
The chrony daemon is not restarted on DHCP changes, the NTP servers are added and removed by chronyc. There is a bug in NM that it sometimes doesn't call the dispatcher script on service restart, you might be hitting that (bug #517082). The case when the same DHCP starts advertising different NTP servers might not be handled correctly though. Can you try changing the following in /etc/dhcp/dhclient.d/chrony.sh /usr/libexec/chrony-helper is-running && /usr/libexec/chrony-helper add-dhclient-servers || : to /usr/libexec/chrony-helper is-running && /usr/libexec/chrony-helper add-dhclient-servers && /usr/libexec/chrony-helper remove-dhclient-servers || : and see if that fixes the problem?
Yes, the modification from comment #7 fixed the problem.
chrony-1.26-5.20110831gitb088b7.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/chrony-1.26-5.20110831gitb088b7.fc16
chrony-1.26-5.20110831gitb088b7.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
There is actually a bit more subtle problem that is still present. If one configures chrony with the same time server as the one that comes from DHCP, but with iburst option, the one from DHCP (that always comes without iburst) will win. This then usually means that for a while, the system will have incorrect time after boot. So, if one uses Kerberos, for instance, the ticket issued upon login will be wrong and it actually won't work, due to clock skew that is too great. Ditto building something using make - it may produce warnings about things being from the future (if you live in UTC+ zone and your hardware clock is set to UTC). Is it possible to always use the configured config (i.e. from /etc/chrony.conf) in place of DHCP, if the servers happen to be the same? It seems to me that if someone went to the trouble of configuring something by hand, they probably want exactly that.
Hm, I don't see that. The chronyc command adding the server from DHCP should fail as chronyd won't allow to add the same server for second time. How much time there was between chronyd start and dhclient getting a lease? Also, options for the DHCP servers can be set in /etc/sysconfig/network, e.g. NTPSERVERARGS=iburst
(In reply to comment #12) > Hm, I don't see that. The chronyc command adding the server from DHCP should > fail as chronyd won't allow to add the same server for second time. OK, to me it looks as if the dhcp version, without iburst, is winning, which is causing sync delay. But maybe I am confused. > How much > time there was between chronyd start and dhclient getting a lease? Many minutes. Enough to login into Gnome, open Evo (which uses krb5 auth) and several shells, and start a new build, for instance. > Also, options for the DHCP servers can be set in /etc/sysconfig/network, e.g. > NTPSERVERARGS=iburst OK, thanks for the tip. I worked around for now by using PEERNTP=no.
(In reply to comment #13) > (In reply to comment #12) > > How much > > time there was between chronyd start and dhclient getting a lease? > > Many minutes. Enough to login into Gnome, open Evo (which uses krb5 auth) and > several shells, and start a new build, for instance. If there are several minutes when chronyd configured with an iburst server is without network, there will be only 8 packets sent quickly (to nowhere) and then the polling interval will be 64 seconds and will increase slowly. I.e. the iburst options is useful only when network is available soon after chronyd was started, perhaps up to 40 seconds.
(In reply to comment #14) > If there are several minutes when chronyd configured with an iburst server is > without network, there will be only 8 packets sent quickly (to nowhere) and > then the polling interval will be 64 seconds and will increase slowly. I.e. the > iburst options is useful only when network is available soon after chronyd was > started, perhaps up to 40 seconds. Sorry, I think I misunderstood your previous question. Dhclient gets a lease within seconds. Long time after that chronyd reports that it had to step up the clock by a large amount: ----------------- Apr 11 13:04:21 shrek chronyd[1172]: Selected source <IP> Apr 11 13:04:21 shrek chronyd[1172]: System clock wrong by -39601.012002 seconds , adjustment started Apr 11 13:04:21 shrek chronyd[1172]: System clock was stepped by -39601.012 seco nds ----------------- Log entries just before those have "Apr 12 00:04:21", hence the 39,600 seconds difference. Anyhow, with NTPSERVERARGS=iburst in my ifcfg-eth0 file, it all works great. I can see with 'chronyc sources' that sync to my time server happens within seconds.
*** Bug 787477 has been marked as a duplicate of this bug. ***