RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1929157 - Chronyd tries to use IPv4 address for NTP server in IPv6-only environment
Summary: Chronyd tries to use IPv4 address for NTP server in IPv6-only environment
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: chrony
Version: 8.3
Hardware: x86_64
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: Miroslav Lichvar
QA Contact: Ondrej Mejzlik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-16 10:21 UTC by Robert Scheck
Modified: 2021-11-10 09:30 UTC (History)
2 users (show)

Fixed In Version: chrony-4.1-1.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-11-09 19:51:57 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2021:4462 0 None None None 2021-11-09 19:52:05 UTC

Description Robert Scheck 2021-02-16 10:21:02 UTC
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.

Comment 1 Robert Scheck 2021-02-16 10:24:06 UTC
Cross-filed case 02870683 at the Red Hat customer portal.

Comment 2 Miroslav Lichvar 2021-02-16 12:47:31 UTC
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.

Comment 3 Miroslav Lichvar 2021-02-16 12:49:14 UTC
A correction. The workaround is to add -6 to /etc/sysconfig/chronyd, so IPv4 addresses are disabled.

Comment 4 Robert Scheck 2021-02-16 13:14:52 UTC
> 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.

Comment 5 Miroslav Lichvar 2021-02-16 14:08:51 UTC
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

Comment 6 Robert Scheck 2021-02-16 17:56:11 UTC
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?

Comment 7 Miroslav Lichvar 2021-02-17 08:46:24 UTC
It might be in 8.5. It is not certain yet.

Comment 8 Robert Scheck 2021-02-19 19:29:40 UTC
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.

Comment 9 Miroslav Lichvar 2021-02-22 11:28:33 UTC
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/

Comment 18 errata-xmlrpc 2021-11-09 19:51:57 UTC
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


Note You need to log in before you can comment on or make changes to this bug.