Bug 1410457 - leap second acceptance only if majority of servers breaks hierarchical NTP configuration with peers (since 4.2.6)
Summary: leap second acceptance only if majority of servers breaks hierarchical NTP co...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ntp
Version: 6.9
Hardware: All
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Miroslav Lichvar
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-05 14:39 UTC by Laurent Deniel
Modified: 2020-03-11 15:34 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1461196 (view as bug list)
Environment:
Last Closed: 2017-06-13 18:34:46 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Laurent Deniel 2017-01-05 14:39:43 UTC
Description of problem:

Since 4.2.6 the leap second is only accepted if:
- provided by file or by a REF_CLOCK
- or if a majority of servers announce it (while it was previously accepted if only one server announces it)

This breaks hierarchical NTP configuration when for instance you have stratum 2 servers configured as peers for fault tolerance (and other) reasons.

Example :

  (stratum 1)        (stratum 2)          (stratum 3)
[NTP server 1]  <----- [NTP server A]  <------- NTP Clients 
[NTP server 2]  <----- [NTP server B]  <------- ...
                <----- [NTP server C]  <------- ...
                                       <------- ....
1 and 2 are servers for A,B,C
A,B,C are peers 

There is no distinction between the stratum 1 NTP server and the stratum 2 peers when computing the majority. So the leap lecond announced by the two servers are not taken into account in this case by any stratum 2 servers.

The code is :

} else if (leap_vote > sys_survivors / 2) {

so this gives for the example :

2 > 5/2 ==> 2 > 2 ==> KO

This would only work with 2 machines at stratum 2 (i.e. 1 peer) but this could again fail if one of the 2 NTP server of stratum 1 is not available at this time.

So the new algorithm is not that optimal and breaks existing configurations in production.

Version-Release number of selected component: any 4.2.6 version

How reproducible: yes

Steps to Reproduce: 
1. configure more peers than servers of higher stratum
2. insert leap second at higher stratum

Actual results: received leap second indication is ignored

Expected results: leap second is injected

Additional info:

Suggested changes:

- revert change ;-) i.e. if (leap_vote > 1)
  but I agree that this might not be ideal in all cases so a more complex 
  scheme might need to be found:

- always accept leap if the server is at higher stratum else still take the  
  majority (so of servers/peers of same or lower stratums)

- or introduce a new configurable parameter : (if leap_vote > parameter))

- or ?

Comment 1 Miroslav Lichvar 2017-01-05 14:56:31 UTC
The problem with the original approach was that it was too easy to spread false leap seconds and it did happen in the past. Your suggestion to take into account stratum sounds interesting, but this is a complex problem and I'd strongly suggest to report this on bugs.ntp.org, or one of the ntp mailing lists, so more people can discuss it.

Comment 2 Laurent Deniel 2017-01-05 16:10:01 UTC
As customer of Red Hat and user of RHEL, I would assume it is part of Red Hat job to check/discuss with upstream if the patch is not trivial ;-) 
Anyway: http://bugs.ntp.org/show_bug.cgi?id=3364

Comment 7 Chris Williams 2017-06-13 18:34:46 UTC
Red Hat Enterprise Linux 6 transitioned to the Production 3 Phase on May 10, 2017.  During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.
 
The official life cycle policy can be reviewed here:
 
http://redhat.com/rhel/lifecycle
 
This issue does not appear to meet the inclusion criteria for the Production Phase 3 and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification.  Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:
 
https://access.redhat.com

Comment 8 Laurent Deniel 2017-06-13 19:37:22 UTC
RHEL6 was chosen since this was the starting point of this issue. BUT this bug is present in any present and future release if nobody fixes it !
So bz created for RHEL7 as well : 1461196


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