May 2016 - Xymon - Xymon mailman web

Need help with upgrade from 4.3.17 to 4.3.20
by vadud3＠gmail.com 17 Jul '18

17 Jul '18

I am not sure what I need to after the upgrade for the columns to show data instead of something like this ELF �� >� �� @��@�� Þ ��@�8� �@�%�"� �� @��@�@��@�@��ø ��ø �� 8 ��8 @��8 @�� @��@��ää��ää�� I removed FollowSymLinks from xymon-apache.conf file under /xymon-cgi/ and /xymon-seccgi/ and restarted. I am using ubuntu -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

9 29

Recovery notifications not generated when test goes red->yellow->green?
by hobbit＠elyograg.org 13 Dec '17

13 Dec '17

It appears that if a test goes from the red state, to the yellow state, and then to the green state, no recovery notification is sent. If it goes directly from red to green, then we get a notification. Initial notifications are only sent on RED and PURPLE. We have recovery notifications configured for most tests. Xymon server is 4.3.21, built using makerpm.sh and installed with yum on CentOS 6. I do not know whether our previous version (4.3.14) behaved similarly. It was almost an accident that I discovered the problem at all. Is this expected behavior? If it is, can I change it? Thanks, Shawn

4 3

CLASS not working as expected
by steve＠opendium.com 11 Dec '17

11 Dec '17

Under Xymon 4.3.25, I'm trying to use the class attribute to group hosts together by what monitoring and alerting they need. So for each host I have a hosts.cfg line like: 192.0.2.1 somehost.example.com # CLASS:Foo trace ssh Then in analysis.cfg I have: CLASS=Foo PROC this PROC that And alerts.cfg has: CLASS=Foo SCRIPT=blah However, the tests in analysis.cfg are not being applied. If I replace CLASS=Foo with HOST=somehost.example.com they work as expected. Also, CLASS=linux seems to work, which implies that the CLASS: directive in the hosts.cfg is being ignored. As far as I can tell, the messages on xymon's "client" channel don't contain the class name that was specified in hosts.cfg, so xymond_client is using the class that the client sent instead. Other channels, such as "status" do include the class name that was specified in hosts.cfg. Am I misunderstanding how the class is supposed to be used, or is this a bug? -- - Steve Hill Technical Director Opendium Limited http://www.opendium.com Direct contacts: Instant messager: xmpp:steve at opendium.com Email: steve at opendium.com Phone: sip:steve at opendium.com Sales / enquiries contacts: Email: sales at opendium.com Phone: +44-1792-824568 / sip:sales at opendium.com Support contacts: Email: support at opendium.com Phone: +44-1792-825748 / sip:support at opendium.com

7 9

DNS failures causing "runtime longer than time limit"
by jlaidman＠rebel-it.com.au 11 Sep '17

11 Sep '17

Hi I'm running Xymon v4.3.10 on Linux, and I'm quite sure it's compiled with c-ares support. I have 12 new DNS servers that were added to Xymon about one month ago. All of my server entries in hosts.cfg have "testip". The tasks.cfg runs xymonet with "--dns-timeout=3". The hosts entries look like so: 10.10.10.1 dnshost1.example.com # testip dns=NS:example.com,SOA: example.com About a week ago, connectivity to all of these servers failed, and at the same time, the xymonnet run time jumped from less than 15 seconds to about 330 seconds, so about 315 seconds extra. The xymonnet page says 295 seconds is taken up by DNS tests. If the increase in time taken is about 315 and is entirely due to the 12 servers failing, then each failed server is adding about 26 seconds to the total run time. I don't think this should be happening like this. With two DNS checks per server, the DNS checks should be taking 6 seconds each to time-out, not 26. If I run xymonnet with "--timing --no-update" and specify only one hostname, I can view the results and the timing. This shows that the ping check gets reported after about 3 seconds, and then the DNS tests are executed and take 26 seconds total. My naiive assumption was that when a server failed a ping (and didn't have "noclear" defined in hosts.cfg) then the network checks would be skipped. On re-reading the man page for hosts.cfg, it dawned on me that a failed ping simply suppresses failed test /results/, but doesn't stop the tests from being run. So the real problem is that the "--dns-timeout=3" is not being taken into consideration by xymonnet. If I run xymonnet with "--debug" it tells me: 1900 2015-06-03 12:02:20 ares_search: tlookup='example.com', class=1, type=2 1900 2015-06-03 12:02:20 ares_search: tlookup='example.com', class=1, type=6 1900 2015-06-03 12:02:20 Processing 0 DNS lookups with ARES 1900 2015-06-03 12:02:46 Finished ARES queue after loop 423 This is peculiar. Why would it say "processing 0 DNS lookups" when there are two lookups to test? Could this be because xymonnet hasn't actually been built with ARES support and I didn't know it? Is there a good way to tell? If I add "--no-ares" I get the same results perhaps suggesting a lack of ARES support. On the other hand, if I add "timeout:3" and "attempts:1" into resolv.conf, I also get the same results. If I run "nm /path/to/xymonnet | grep gethostby" it returns "ares_gethostbyname". Just for fun, I compiled Xymon v4.3.21 and ran the xymonnet binary from there, with no change in behaviour. I also tried removing the "--dns-timeout" option so that it defaults to 30 seconds, but still no change - 26 seconds for two DNS tests. So, I'm not really sure what the problem is, but xymonnet certainly isn't behaving as I would expect. Cheers Jeremy

2 3

i586, logfetch: ... delta NNN bytes exceeds max buffer size 0
by a_s_y＠sama.ru 04 Jul '16

04 Jul '16

Hello. I saw a strange problem since 4.3.26 (I not used versions between 4.3.16 and 4.3.26). 4.3.27 contains it too. 2016-05-23 14:44:14.052315 logfetch: /var/log/httpd2/error_log delta 2098854 bytes exceeds max buffer size 0; skipping some data 2016-05-23 14:45:54.580396 logfetch: /var/log/httpd2/error_log delta 2105418 bytes exceeds max buffer size 0; skipping some data 2016-05-23 14:47:35.120075 logfetch: /var/log/httpd2/error_log delta 2109847 bytes exceeds max buffer size 0; skipping some data max buffer size 0 somehow. I built i586 and x86_64 binary from one srpm. x86_64 works fine. Spec file is not contains architecture dependent parts. I see that this is macro in the client/logfetch.c (#define MAXCHECK 102400) and I don't understand how this is possible. Can anyone confirm the problem on i586 ? Log continues to be analysed however. -- Regards, Sergey

2 5

Strange Ghost report
by colin.coe＠gmail.com 02 Jul '16

02 Jul '16

Hi all I've got a ghost report coming up with the IP and "Candidate" of the Xymon server and a "Hostname" of a CNAME belonging to a another server. I've checked this other server and its Xymon client settings are correct and its correctly showing on the appropriate Xymon page. How can I get more detail of this ghost report, like the client data? Thanks CC

2 1

EXTIME still valid ?
by rltexas1＠gmail.com 22 Jun '16

22 Jun '16

Is the EXTIME option still valid in the alerts.cfg I am having problems testing the following EXTIME=1:1140:1240 Should be exclude Monday's 11:40 to 12:40. Will test EXTIME=M:1140:1240 But if it's M for Monday what would Sunday be ? Thanks

4 4

Intelligent CPU Load Settings
by howe.bill＠gmail.com 21 Jun '16

21 Jun '16

Xymon'ers, Is there any planned functionality to be able to dynamically set a xymon client's LOAD alert settings based upon how many processors it has? The current static defaults are not too helpful, and hand editing an entry in /etc/xymon/analysis/*.cfg for every server just shouldn't have to be done. _*Ideally*_ It would be best if along with the "top" view that is reported by clients, they also reported their CPU count (either with "nproc" or "grep -c proc /proc/cpuinfo") Then the CPU count could be shown on client's "cpu" service page. <= Critical information when determining if load is a problem or not. Since the count would then be reported to and available on the xymon server, it could then be possible to set warnings and criticals based off of CPU count. (IE Warn at a load number equal to CPU count, Critical at a number equal to CPU count x 1.5) Regards, -- Bill Howe howe.bill at gmail.com

2 4

xymon for AIX
by wonderfoo2＠gmail.com 02 Jun '16

02 Jun '16

Hi Stef, Your last tip was helpful to get through with the hump on getting the AIX client compiled and initial install. I noticed the monitoring page (cpu,disk, memory) for the said client is not populated aside from the standard monitors coming off the server (conn,info,ssh,trends). the client log is throwing "Whoops ! Failed to send message (timeout)". I send in a debug for test to the server from the client, which is also timing out. Please advise. /xymon/logs # tail -10 xymonclient.log 2016-05-18 15:51:47.497327 -> Recipient '172.31.2.131', timeout 15 2016-05-18 15:51:47.497375 -> 1st line: 'client aixadm.aix aix' 2016-05-18 15:56:51.683098 Whoops ! Failed to send message (timeout) 2016-05-18 15:56:51.683283 -> 2016-05-18 15:56:51.683308 -> Recipient '172.31.2.131', timeout 15 2016-05-18 15:56:51.683352 -> 1st line: 'client aixadm.aix aix' 2016-05-18 16:01:56.124743 Whoops ! Failed to send message (timeout) 2016-05-18 16:01:56.127297 -> 2016-05-18 16:01:56.127323 -> Recipient '172.31.2.131', timeout 15 2016-05-18 16:01:56.127371 -> 1st line: 'client aixadm.aix aix' /xymon/bin # ./xymon --debug 172.31.2.131 test 9568302 2016-05-18 15:58:27.133743 Transport setup is: 9568302 2016-05-18 15:58:27.133913 xymondportnumber = 1984 9568302 2016-05-18 15:58:27.133926 xymonproxyhost = NONE 9568302 2016-05-18 15:58:27.133940 xymonproxyport = 0 9568302 2016-05-18 15:58:27.133953 Recipient listed as '172.31.2.131' 9568302 2016-05-18 15:58:27.133967 Standard protocol on port 1984 9568302 2016-05-18 15:58:27.133995 Will connect to address 172.31.2.131 port 1984 9568302 2016-05-18 15:58:42.134223 Timeout while talking to Xymon daemon at 172.31.2.131:1984 - retrying 9568302 2016-05-18 15:58:43.134348 Will connect to address 172.31.2.131 port 1984 9568302 2016-05-18 15:58:58.134561 Timeout while talking to Xymon daemon at 172.31.2.131:1984 - retrying 9568302 2016-05-18 15:58:59.134657 Will connect to address 172.31.2.131 port 1984 9568302 2016-05-18 15:59:14.134814 Closing connection 2016-05-18 15:59:14.134870 Whoops ! Failed to send message (timeout) 2016-05-18 15:59:14.135049 -> 2016-05-18 15:59:14.135099 -> Recipient '172.31.2.131', timeout 15 2016-05-18 15:59:14.135185 -> 1st line: 'test' Thank you.

9 21

question
by m.pingel＠ndr.de 02 Jun '16

02 Jun '16

Hi, is it possible to configure a maximum level of memory from a process? Thanks Mit freundlichen Grüßen Matthias Pingel

3 2