Eric S. Raymond
esr at thyrsus.com
Thu Mar 22 20:54:34 UTC 2018
Hal Murray <hmurray at megapathdsl.net>:
> Eric said:
> > I've never tried do describe that kind of testing because it's not easy to
> > tell people without prior experience running the clients what a success/
> > failure indication looks like. Of course alarm bells would go off on a
> > crash, but the most definite thing I could say otherwise is "suspect a
> > problem if the number don't look lilke they usually do".
> I think it's worthwhile to include some rough sanity checks in a
> get-ready-for-a-release document. Another time when that sort of check would
> be useful is before the push when making a significant change.
Yes, I tend to run through my checklist then, too.
> Yes, it's hard to describe what success looks like. But the context is we
> are getting ready for a release or doing a big update, so the target audience
> is wizards rather then newbies.
> > I always do ntpmon first, as that test excerises the packet library pretty
> > well and would be more difficult to test jig than others becuse of the
> > ncurses otput.
> > I dump clock and system variables using ntpq to check that they look sane.
> > I test ntpdig and ntpwait.
> Good list. I'd put ntpq -p in there too.
That should have been #2 on the list after running ntpmon. Sometimes I do it
> We should be explicit about how to "dump clock and system variables". I'm
> thinking of chunks you can copy-paste.
> Any objections if I write the text? Where should it go?
None at all. You have way more NTP ops experience than me; that makes
you better qualified.
I think you already have the beginnings of a procedure document under devel/.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
More information about the devel