Bug 1929157
| Summary: | Chronyd tries to use IPv4 address for NTP server in IPv6-only environment | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Robert Scheck <redhat-bugzilla> |
| Component: | chrony | Assignee: | Miroslav Lichvar <mlichvar> |
| Status: | CLOSED ERRATA | QA Contact: | Ondrej Mejzlik <omejzlik> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.3 | CC: | omejzlik, robert.scheck |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | chrony-4.1-1.el8 | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-11-09 19:51:57 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Cross-filed case 02870683 at the Red Hat customer portal. It seems that two servers stopped agreeing with each other at one point, which triggered a source replacement. The IPv4 address was selected randomly from the resolved addresses and accepted for the replacement, even though there is no IPv4 route configured on the system. The address should be changing repeatedly until it gets responding servers that agree with each other. The issue with accepting an unreachable address in the replacement is fixed in chrony-4.0, which is planned for a rebase (bug #1895003). As a workaround, you can add -4 to /etc/sysconfig/chronyd. Please note that it is not recommended to use only two sources as it easily leads to selection failures. Consider adding a third source, or at least mark one as trusted with the trust option. A correction. The workaround is to add -6 to /etc/sysconfig/chronyd, so IPv4 addresses are disabled. > Please note that it is not recommended to use only two sources as it easily leads to selection failures. Consider adding a third source, or at least mark one as trusted with the trust option.
The same scenario worked reliably with ISC NTP for 15+ years (independent whether it's either two Stratum 2 or two Stratum 1 sources), this hiccup started with Chrony after a few less weeks of usage.
That recommendation is not specific to chrony. ntpd would just complain less (a no_sys_peer message in syslog). If it worked for you, that's great, but it is a common issue, with both ntpd and chronyd. https://access.redhat.com/solutions/58025 Maybe the mentioned knowledgebase article should be updated to cover RHEL 8. Nevertheless, this report is about IPv4 usage by chronyd on an IPv6-only system. Any chances for RHEL 8.4 or 8.5 for the rebase? It might be in 8.5. It is not certain yet. Given GSS caused some uncertainty here: Would rebasing chrony to 4.0 address the issue that it attempts to use IPv4 on an IPv6-only system - or would it address the "Can't synchronise: no majority" thing? This bug report was about the first, not about the second. The former. With chrony-4.0, it should not use any resolved IPv4 addresses if there is no IPv4 route present. The effect is similar to the -6 option. There is an EPEL8 build if you would like to test it: https://copr.fedorainfracloud.org/coprs/mlichvar/chrony/build/1698097/ Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (chrony bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:4462 |
Description of problem: $ journalctl | grep chrony Feb 04 19:57:08 tux.example.net chronyd[1778]: chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 +DEBUG) Feb 04 19:57:08 tux.example.net chronyd[1778]: Frequency 4.206 +/- 0.091 ppm read from /var/lib/chrony/drift Feb 04 19:57:08 tux.example.net chronyd[1778]: Using right/UTC timezone to obtain leap second data Feb 04 19:57:13 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::27 Feb 04 19:57:13 tux.example.net chronyd[1778]: System clock TAI offset set to 37 seconds Feb 04 21:51:27 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::26 Feb 05 18:37:35 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::27 Feb 08 01:56:33 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::26 Feb 09 00:13:52 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::27 Feb 09 02:05:21 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::26 Feb 10 04:56:25 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::27 Feb 12 15:38:36 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::26 Feb 12 19:05:15 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::27 Feb 12 21:51:23 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::26 Feb 12 23:37:37 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::27 Feb 14 09:28:09 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::26 Feb 14 11:44:13 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::27 Feb 15 04:04:57 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::26 Feb 15 23:54:35 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::27 Feb 16 10:53:28 tux.example.net chronyd[1778]: Can't synchronise: no majority Feb 16 10:54:33 tux.example.net chronyd[1778]: Source 2001:db8:1:10::27 replaced with 192.0.2.27 Feb 16 10:54:57 tux.example.net chronyd[1778]: Selected source 2001:db8:1:10::26 $ grep ^server /etc/chrony.conf server ipa1.example.net iburst server ipa2.example.net iburst $ host ipa1.example.net ipa1.example.net has address 192.0.2.26 ipa1.example.net has IPv6 address 2001:db8:1:10::26 $ host ipa2.example.net ipa2.example.net has address 192.0.2.27 ipa2.example.net has IPv6 address 2001:db8:1:10::27 $ chronyc sources 210 Number of sources = 2 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* ipa1.example.net 2 6 377 16 +2473ns[ +10us] +/- 6638us ^? ipa2.example.net 0 6 0 - +0ns[ +0ns] +/- 0ns $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:1a:4a:16:01:cf brd ff:ff:ff:ff:ff:ff inet6 2001:db8:1:10::1337/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fe80::21a:4aff:fe16:1cf/64 scope link noprefixroute valid_lft forever preferred_lft forever All sensitive hostnames, IP addresses etc. have been consistently replaced by ones from RFC 3849, RFC 5737 or RFC 6761. Version-Release number of selected component (if applicable): chrony-3.5-1.el8.x86_64 How reproducible: Not sure, just happened by itself. Actual results: Chronyd tries to use an IPv4 address for the NTP server in an IPv6-only environment. Expected results: Chronyd should never try to use an IPv4 address for the NTP server in an IPv6-only environment. Additional info: Yes, ISC NTP might not be perfect either, but it at least did such basic networking correctly.