Bug 1462081 - /etc/NetworkManager/dispatcher.d/20-chrony is executed result in the source force to offline which is not expected.
/etc/NetworkManager/dispatcher.d/20-chrony is executed result in the source f...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: chrony (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Miroslav Lichvar
Andrej Dzilský
Depends On:
  Show dependency treegraph
Reported: 2017-06-16 02:54 EDT by mezhang
Modified: 2018-04-10 08:06 EDT (History)
2 users (show)

See Also:
Fixed In Version: chrony-3.2-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2018-04-10 08:06:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0753 None None None 2018-04-10 08:06 EDT

  None (edit)
Description mezhang 2017-06-16 02:54:22 EDT

When I set one of NICs down(the other NIC can connect to the chrony source), 
the /etc/NetworkManager/dispatcher.d/20-chrony is executed, result in the source is force to offline.




chrony server:

two NICs with different network.

inet brd scope global eth0
   inet brd scope global bond2

# ip r dev bond2  proto kernel  scope link  src  metric 300 dev eth0  proto kernel  scope link  src  metric 100

chrony source's IP:

eth0's network is the same as source's network, so the default is unnecessary. 

How reproducible:

Steps to Reproduce:

1. check the status
[root@localhost ~]# chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample
^* r511
                         11   6    77    41  -8410ms[ -37.8s] +/-   13ms

2. make the bond2 down
# ifdown bond2

2. check the status

[root@localhost ~]# chronyc activity
200 OK
0 sources online
1 sources offline  <---  the source is offline due to the down bond2.
0 sources doing burst (return to online)
0 sources doing burst (return to offline)
0 sources with unknown address
[root@localhost ~]# chronyc sources

210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample
^* r511                         11   6   177   446   +221ms[-8410ms] +/-   13ms  
this result tell us that the sync is normal.

3. change the source time, so we can check the source is offline or not. I got that result.

[root@localhost ~]# chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample
^* r511                         11   6   177  1018   +221ms[-8410ms] +/-   13ms

The "Reach" is not get bigger, and the "LastRx" is getting bigger. The time is not be synced.

Actual results:

Making Unrelated NIC down, cause the source offline. 
Expected results:

I still have an NIC that can connect to the source, when I set the Unrelated NIC to down. 
The source shouldn't get offline.

I don't really understand why this script should be executed.

Can anyone give some advice.


Comment 2 Miroslav Lichvar 2017-06-16 03:25:36 EDT
The chrony dispatcher script (incorrectly) assumes that a default route is needed to reach all NTP sources. That works in most cases, but may fail with local NTP servers.

The simple solution would be to keep all sources in the online state. This would slow down resynchronization of sources that are not reachable when the network is down.

A better solution would probably be to check each source separately if it isn't in a local network. I'm not sure how feasible that would be in a shell script.
Comment 4 Miroslav Lichvar 2017-08-09 04:47:03 EDT
A fix for this issue was included in upstream git:

Comment 6 Andrej Dzilský 2018-02-08 11:24:10 EST
Sanity Only.
Comment 9 errata-xmlrpc 2018-04-10 08:06:26 EDT
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, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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