Backward-compatibility of ntpq may be an issue
hmurray at megapathdsl.net
Fri Dec 23 21:00:01 UTC 2016
esr at thyrsus.com said:
> Hal, I was reviewing some recent changes, and it occurred to me that your
> commit changing the default of showall in ntpq may have not been a good
> I don't think the showall functional change in either ntpmon or ntpq was a
> bad thing in itself. But backwards-incompatible changes that might affect
> scripting worry me some. I think of the NTP userbase as very conservative
> and likely to get upset if "ntpq peers" in a pipeline does not have stable
Poor choice of words on my part. It's really a bug fix. Cleaning up the
code is just fortunate.
There are two problems in this area. One is that there isn't any
documentation on what peers get skipped or why you would want to skip them or
that there are alternative commands that do what you might prefer. The other
is that the group culture says "ntpq -p" and never mentions that some
important info might get skipped or that there is an alternative.
Under normal circumstances, nothing gets skipped. I have a hacked version of
the old ntpq that prints out a would-get-skipped message and then prints it
anyway. It goes off during startup on pool slots. I don't know the details
- I'd have to look at the code.
Perhaps I'm oversensitive to this area since I wasted a lot of time when
debugging early pool stuff because the slots I was trying to track down
didn't get printed out. I never did figure out a good reason for skipping
some slots or a good description for which slots get skipped.
Alternatives would be to remember if any slots were skipped and print out a
warning message. Or find a place to add a flag in the printout to indicate
that a slot would have been skipped. Or add a command to revert to the old
behavior. Or... But those changes might break scripts too.
These are my opinions. I hate spam.
More information about the devel