On Sat, Jul 2, 2016 at 7:36 AM Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
On Sat, 2 Jul 2016, 02:52 Junaid Shahid <shahid.junaid at gmail.com> 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