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@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@hgm ~]$ ntpd --version ntpd 0.9.6-b9cadf5-hgm Nov 30 2016 03:44:12 [murray@hgm ~]$ ntpq --version ntpq 0.9.6-119-play 2016-11-06T00:05:45Z [murray@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@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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
