ntpmon should be more usable now
Eric S. Raymond
esr at thyrsus.com
Fri Dec 9 04:34:25 UTC 2016
Hal Murray <hmurray at megapathdsl.net>:
> esr at thyrsus.com said:
> > I don't know how to read the damned output. I have barely
> > any idea what those columns mean. I can't tell descending
> > from ascending from middle-outwards!
> It's what you want if you are trying to figure out who is using your server.
Thank you. Just that one sentence was amazingly helpful, actually. A lot
of previously disconnected facts fell into place when I read it.
/me adds that sentence to the mrulist
> A couple of examples from a handy server.
> lstint avgint rstr r m v count rport remote address
> 489277 20422 180 . 3 4 74 123 dhcp-103
> 492043 13366 180 . 3 4 125 123 dhcp-102
> 1210927 33 180 . 4 4 31564 123 tim
> The count column is the total packets. I think it includes both replies from
> servers as well as requests from servers in case you have too systems looking
> at each other. I don't think it includes ntpq queries.
I think I need to widen that lstint column...done.
Aha. While working on that I figured out the reason for the spurious
negative lstint values. They're supposed to be made by subtracting
the last transmission time passed up from now. In ntpq I initialize a
new PeerSummary instance for each other mrulist; int ntpmon I initialize one
such object and re-use it. You guessed it, stale timestamp.
> The first/lstint column is the time since the last packet. The second/avgint
> column is the average time between requests.
> The rstr column is the restriction bits that apply to that IP Address. The m
> and v columns are the mode and version from the last packet. The above shows
> 2 clients and 1 server.
> The rport is the remote/source port from the last packet. The remote address
> should be obvious.
I more or less knew these things from studying the code for the Mode 6
protocol, actually. What I was missing was any clue about what they
> The mru section will take forever on any busy server. I think the default
> memory limit matches the old 600 slot default.
> It will probably screwup a nice clean API, but if you want to display the
> most recent slots, you can do something like:
> read the whole collection. They come back sorted by lstint - most recent
> remember the IP Addresses of several slots just below the ones you print.
> Next time, rather than read the whole thing, start with the IP Addresses
> you saved.
> display the new data and update the saved IP Addresses...
Simpler (I think): add a parameter to the reqest method saying "Just give me
enough records to get the last N most recent entries".
> If you want to play, you can add keyboard commands to fiddle the sort order.
> Oldest first should be easy. Just read as many as fit. Sorting by other
> columns will be hard.
> I'd like a q for quit.
So write it, already. The Python curses API is well-documented, and
dead-simple if you've ever used the C version. And at 142 LOC ntpmon
isn't a high mountain to climb.
(Happens I wrote a lot of the Python ncurses code, and a lot of the
ncurses C library beneath it too.)
I'd like to hack on this, but my priorities now have to be (a) ripping out
the interface-scanning hair, and (b) simplifying and fixing some
broken stuff in the waf recipe. I can take some time out for ntpmon
because it's so trivial to modify, but I need to focus.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel