[nSLUG] Why is ntp so terrible?
D G Teed
donald.teed at gmail.com
Sat Mar 11 08:53:07 AST 2017
NTP, should by default, log as a warning each time it
fails to reach any upstream source, and it should give
an error when it goes into the reject/mobilize status.
That status is as good as having no NTP, so it
should scream out it is failing. It should not be
necessary to enter two letter commands in ntpq
or set up nagios monitors on each host to monitor
time sync as seen on every system.
ntpd should also behave the same way as ntpdate. If ntpdate
can fail over from IPv6 to IPv4 and set the date, so should ntpd.
It is misleading that one works and the other silently fails.
If I could trade off, I'd rather it give us reliable performance
via status or abort the service on severe error
than sub-millisecond accuracy.
By default the logs have more information about the technical
stuff than about being connected with a source. I never did
find information about making the log more verbose
to reveal this problem, only some two letter
commands to the ntpq CLI.
openntpd might be something to look at someTIME.
But the issue goes beyond Linux. Our SAN should have
alerted there was no connection. Likely ntpd inside.
On Fri, Mar 10, 2017 at 9:49 PM, <billdavidson at eastlink.ca> wrote:
> So can we change the subject of this thread to"Why is NTP so great?". I
> could give a bunch of reasons! Imagine a protocol that can synchronize
> clocks over a distributed network, with a handful of packets, to
> sub-millisecond accuracy? It is mind boggling!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG