[ntp:questions] Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync
darryl-mailinglists at netbauds.net
Thu Aug 28 15:36:31 UTC 2008
Steve Kostecke wrote:
> On 2008-08-26, Darryl Miles <darryl-mailinglists at netbauds.net> wrote:
>> Unruh wrote:
>>> A far better idea is to monitor the offset from the ntp servers to
>>> let you know if there is a clock problem.
>> I'd appreciate a tool for that. "/usr/sbin/ntpdc -check
>> 0.0000:0000:0000 -print"
> ntpq is the preferred monitoring tool.
> ntpq -c"rv 0 offset" will tell you the current offset of your ntpd.
So it is the "offset" that I should look at! Thanks, I wasn't sure.
I guess an offset of 0.0000 is perfect ?
Now how do I tell the difference between an offset being reported as
0.0000 due to no sync and an offset being reported as 0.0000 due to a
perfect sync ?
I'm trying to establish that whomever created such a
tool/script/whatever which accepted my simple bound requirements has
taken into account all failure scenarios that I can / the community can
Then make it really easy for them to ask the NTP sub-system to report on
that its well being in respect of its primary function.
How abouts a new ntpq/ntpdc command "summary" could be implemented, with
a simple "key: value" output of data, with simple "WARNING:" and
"ERROR:" and "FATAL:" reporting of concerns. With "Overall Status: GOOD"
Another new command verify/check accuracy against a bounds specification
and again report what is inside that bound and what is outside that bound.
Then all that is left is to publish a paragraph into a man page with a
few examples of possible "bound requirement specifications" and what
they might mean to a system in real life.
As a system admin wanting to monitor their NTP and kernel clock state
(as judged by NTP) only needs to consult documentation and copy'n'paste
from an example. This would be ideal planning.
>> that takes various parameters for your acceptable accuracy and returns
>> with zero/non-zero exit status. That might also dump data like
>> adjtimex -print and indicate items of concern to the administrator.
> Collecting information from all those sources is the job for a script.
No problem on the mechanism to do it, but its a job for an NTP groker
and maybe something to be shipped as part of the NTP suite, i.e. not
something a system administrator wants to make up on the spot and get it
so easily wrong.
More information about the questions