[email protected] 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 > idea.
> 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 > behavior. ... Yes. 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. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
