On Sat, Jul 2, 2016 at 7:36 AM Jeremy Laidman <user-71895fb2e44c@xymon.invalid>
wrote:
On Sat, 2 Jul 2016, 02:52 Junaid Shahid <user-bfbf9229dbc9@xymon.invalid> wrote:
Thank you Jeremy for your suggestion!
I have run this command on the client, but I don't know what conclusions
can I draw from it. Here is the outptu, (after being dropped to xymoncmd):
0.00user 0.00system 0:00.00elapsed 33%CPU (0avgtext+0avgdata
680maxresident)k
0inputs+0outputs (0major+200minor)pagefaults 0swaps
OK, so what next? The likely causes seem to have been eliminated, or at
least unlikely.
What I'd do next is to get a packet capture on both endpoints, of the
client message, complete with timestamps on the capture output, when
there's a significant time discrepancy; 45 seconds would be great, but
anything more than a few seconds would be sufficient (an order of magnitude
longer than the expected runtime of the xymonclient.sh script). Then I'd
compare the capture timestamps with the time shown in the contents of the
client message. This should hint at whether the time anomaly (sounds like
a scifi plot device) is at the client or server.
For extra points, trace the client side using strace/truss with timestamps
enabled.
Note that you don't need to wait (up to 5 minutes) for the client message
to be transmitted. You can send a client message any time you like by
running xymonclient.sh within xymoncmd. This also makes it easier to use
strace/truss.
J