Please exercise ntpq, I just refactored it
Eric S. Raymond
esr at thyrsus.com
Tue Nov 22 00:10:11 UTC 2016
Hal Murray <hmurray at megapathdsl.net>:
> esr at thyrsus.com said:
> >> How about setting up a simple script that at least tries all of the
> > Hm. All it could detect is crashes. Time-varying output pretty scotches any
> > prospect of real regression testing.
> Yes, but it has a good chance of catching a large class of simple bugs.
> In hindsight, I'm a bit surprised something like that isn't on your checklist
I've had a lot of other things to think about. Like this morning's CVE burst.
> We should do it with all the programs we build and again after we
> install things. If nothing else, it will verify that the libraries are
> linked correctly. The simple case would print out the version.
> It might be useful to have (or have waf build) a script that does the post
> install tests - something an admin could run after a system upgrade.
> We should have a config file that tests all the options for ntpd. It would
> need a command line switch so that it doesn't actually try to run anything.
> How about --check? That might be handy anyway. You could use it to check
> your changes to ntp.conf before restarting ntpd.
I'm not clear on how we'd tell good behavior from bad in that particular
context. It's easy to tell when ntpq crashes, but how do we know when ntpd
is processing an option wrongly?
Is this something you'd be willing to work on? You seem to have a clearer
vision of what the tests ought to be like, and I still have pre-1.0 work
to do getting ntpdig moved and writing ntpmon.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel