ntpq quirks

[Hal Murray]

The mru list is getting printed out oldest first.  I thought you fixed that.

The print-what-you-have after ^C doesn't work if the output is a pipe.  
(Classic doesn't work either.)
[murray at second ~]$ ntpq -nc mru | tee foo.log
Ctrl-C will stop MRU retrieval and display partial results.
^Cclose failed in file object destructor:
sys.excepthook is missing
lost sys.stderr


The date in the python version string is close to useless.

[murray at hgm ~]$ ntpd --version
ntpd 0.9.6-b9cadf5-hgm Nov 30 2016 03:44:12
[murray at hgm ~]$ ntpq --version
ntpq 0.9.6-119-play 2016-11-06T00:05:45Z
[murray at hgm ~]$ 

I don't know what the right answer is.

The date is ages ago.  The "play" is the directory I built it in.  The "hgm" 
in the ntpd string is what I put there with waf --build-version-tag=


I'm getting hangs with mrulist.  I haven't figured out what's going on.  Yes, 
it works OK in small local cases.  I'm getting hangs in big local cases (pool 
server).  If I wait a while then ^C, it prints out a bunch of stuff (in 
backwards order), then stops.  It doesn't print out any of the
  346 (0 updates)
messages, but I don't know if the new version does that normally.
...
  1231      0   90 . 3 4      1   123 92.24.199.193
  1230      0   90 . 3 4      1 30704 223.24.43.95
  1230      0   90 . 3 3      1 60456 78.145.21.250
  1230   0.00   90 . 3 3      3  3688 86.135.151.203
  1230      0   90 . 3 3      1 44231 175.151.247.31
[murray at second ~]$

It's a pool server getting lots of traffic.  The 1200 is ballpark of how long 
since ntpd was restarted.  So either local packets are getting dropped and 
the retransmission logic is broken or something else is broken.

Any suggestions for how to debug this?

How about adding a few counters to ntpq so we can at least get some hints?


-- 
These are my opinions.  I hate spam.