Bug 30854 - LOCAL driver should only be used when no timeserver is configured
LOCAL driver should only be used when no timeserver is configured
Status: REOPENED
Product: UCS
Classification: Unclassified
Component: NTP
UCS 5.0
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
:
Depends on:
Blocks: 51498
  Show dependency treegraph
 
Reported: 2013-03-21 15:11 CET by Janek Walkenhorst
Modified: 2020-07-04 08:45 CEST (History)
3 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 4: Minor Usability: Impairs usability in secondary scenarios
Who will be affected by this bug?: 4: Will affect most installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.183
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Janek Walkenhorst univentionstaff 2013-03-21 15:11:51 CET
There is a problem when using the LOCAL clock: ntpd repeatedly switches between the upstream timeserver and the local clock, thus keeping the stratum and sync state as if synced to the local clock instead of the NTP clock.
That makes the peer unattractive for downstream clients, which in turn prefer their local clock because the other servers are high stratum/local-reference too.

The orphan mode should be investigated to replace the LOCAL clock. In theory the LOCAL clock is only required on the DC master and only if no other timeserver{,2,3} is configured; The DC backup/slave automaticall use the DC master/backup and should switch to orphan mode if upstream servers are temporarily not available.


How to reproduce the problem:
Master:
 timeserver=mammut.knut.univention.de
 reset clock ~35days back
 restart ntpd
Backup:
 timeserver=mammut.knut.univention.de
 reset clock ~35days back
 restart ntpd
Slave:
 reset clock ~35days back
 restart ntpd

wait
see the master/backup correct their clock but never reaching "sync_ntp" or a low stratum.
observe master/backup regularly switching between ntp server and LOCAL.
see the slave never correcting.



References:
  http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html
"This driver is intended for use in an isolated network where no external source of synchronization such as a radio clock or modem is available."

  http://www.eecis.udel.edu/~mills/ntp/html/refclock.html
"If a server with this driver is connected directly or indirectly to the public Internet, there is some danger that it can destabilize other clients."

  http://newsgroups.derkeiler.com/Archive/Comp/comp.protocols.time.ntp/2011-11/msg00026.html
"is prone to switch to the LOCAL driver more often than is helpful."
"Once it is selected, it continues to appear to be a better source than the network source, even after many polls, thanks to the 0 delay and root dispersion of reference clocks. This behavior is why this list/newsgroup is full of advice to avoid using the LOCAL driver,"

http://serverfault.com/questions/472455/why-is-ntp-syncing-to-local-rather-than-remote-server
Comment 1 Tobias Birkefeld univentionstaff 2014-01-29 10:59:23 CET
I would prefere if there will be a ucr variable to switch, if local timeserver will be included in ntp.conf or just the values of the ucr variables timeserver[2,3]
Comment 2 Stefan Gohmann univentionstaff 2017-06-16 20:39:12 CEST
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4.

If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
Comment 3 Florian Best univentionstaff 2017-06-28 14:52:40 CEST
There is a Customer ID set so I set the flag "Enterprise Customer affected".
Comment 4 Stefan Gohmann univentionstaff 2017-08-08 07:09:57 CEST
This issue has been filed against UCS 3.1.

UCS 3.1 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen this issue. In this case please provide detailed information on how this issue is affecting you.
Comment 5 Janek Walkenhorst univentionstaff 2017-08-08 12:29:59 CEST
Still relevant:
Correct time is important for S4 domains.
Until Bug #27728 is fixed the master uses the LOCAL clock by default.
Comment 6 Ingo Steuwer univentionstaff 2020-07-03 20:52:10 CEST
This issue has been filed against UCS 4.2.

UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.
Comment 7 Philipp Hahn univentionstaff 2020-07-04 08:45:59 CEST
This still is an issue.