[Xymon] Oversize data/client msg vs time out

Phil Crooker Phil.Crooker at orix.com.au
Wed Apr 11 01:57:08 CEST 2018


In my experience when xymon considers the client message is too big, it just chops it off at the size limit and carries on with what it has. Did you try enlarging the message size? I originally had an issue with this with bbwin, it ignored the message size setting, but I imagine the powershell client works.


cheers, Phil

________________________________
From: Xymon <xymon-bounces at xymon.com> on behalf of Bakkies Gatvol <bakgat8 at hotmail.com>
Sent: Tuesday, April 10, 2018 5:07:31 AM
To: Xymon Mailing List
Subject: [Xymon] Oversize data/client msg vs time out

I sometimes get xymond yellow with oversize client message - I love that.  And btw

Statistics for Xymon daemon
Version: 4.3.23


My issue is not with that.  I have a server that fails sending to xymon, but only fails partly. So what I get is that Xymon claims for eg: procs are not running .. in my estimation - not because procs are not running, but because the whole "packet of info" did not make it to xymon.

I can correlate the two things - error message in ~xymon/client/logs and bad procs reports.

My question is why do I get no matching yellow in xymond. Surely it should be able to detect "this is not a full packet" just the same as in an oversize packet? xymond does not show anything on the webpage, and honestly I have not trolled the logs - since the web is green - I assume there is nothing in the logs.


2018-04-08 09:30:12 Whoops ! Failed to send message (timeout)
2018-04-08 09:30:12 ->
2018-04-08 09:30:12 ->  Recipient '10.65.20.51 10.65.1.171', timeout 15
2018-04-08 09:30:12 ->  1st line: 'client pluto.linux linux'
2018-04-08 16:37:12 Whoops ! Failed to send message (timeout)
2018-04-08 16:37:12 ->
2018-04-08 16:37:12 ->  Recipient '10.65.20.51 10.65.1.171', timeout 15
2018-04-08 16:37:12 ->  1st line: 'client pluto.linux linux'

I solved the problem temporarily with a delayed red .. because as soon as a full packet makes it - the procs are happy again.

If I knew how to extend the timeout I would try that too - but clearly that is also a hack-patch on the real issue.

The issue seems to be on one subnet - but I have not gotten worked up enough to deal with network about it.

Thoughts?

BG




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20180411/24565f7a/attachment.html>


More information about the Xymon mailing list