[Xymon] Xymond and xymonnet quirks

[Poppy, Ben]

I believe this is the same patch you provided to me a few weeks ago. I am extremely happy to report that we've had no purple storms since then..

-----Original Message-----
From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Henrik Størner
Sent: Wednesday, May 02, 2012 12:40 AM
To: xymon at xymon.com
Subject: Re: [Xymon] Xymond and xymonnet quirks

On 01-05-2012 21:25, Steve Holmes wrote:
> We just ran into this same problem and removing the 'dns' tag from one 
> DNS server (non-production) which wasn't working reduced the time to 
> do the DNS tests from over 300 seconds to 22. This was after already 
> tuning the options on the xymonnet call.

I've learned a lot more about the DNS timeout handling in C-ARES after this thread started back in August.

The DNS timeout-settings in 4.3.7 really are broken, in that the DNS library doesn't work the way I thought it did when I wrote the code. 
Instead of being a timeout on the total DNS lookup, the timeout setting is the timeout of the initial DNS query - which will then be retried with exponentially higher timeouts a number of times (4, I think is the default). The net effect is that the default timeout settings in Xymon results in DNS queries that take about 30 minutes to timeout.

The attached patch against 4.3.7 will change the way the timeout settings to two fixed values, resulting in a timeout for DNS operations of approximately 23 seconds.

> Also, WRT the unknown option --timelimit, we think that in (4.3.7) 
> xymonnet.c starting at line 2011:
>
>      else if (strcmp(argv[argi], "--timelimit=") == 0) {
>        char *p = strchr(argv[argi], '=');
>        p++; runtimewarn = atol(p);
>      }
>      else if (strcmp(argv[argi], "--huge=") == 0) {
>        char *p = strchr(argv[argi], '=');
>        p++; warnbytesread = atoi(p);
>      }
>
> Both of the strcmp calls should be argnmatch. The second one is for a 
> different option, of course, but it probably would get the same error 
> without this fix. Note, I haven't tested this, but I'm pretty 
> confident that it is right.

You are right, of course.


Regards,
Henrik

______________________________________________________________________
The contents of this message may contain private, protected and/or privileged information.  If you received this message in error, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained within.  Please contact the sender and advise of the erroneous delivery by return e-mail or telephone.  Thank you for your cooperation.