May 2016 - Xymon - Xymon mailman web

Need help with upgrade from 4.3.17 to 4.3.20
by cleaver＠terabithia.org 17 Jul '18

17 Jul '18

Hmm. So far, the only way I've been able to reproduce this is by replacing the ScriptAlias directives with mere Alias's in the xymon.conf apache config. Has there been any change in the path you've used for the CGI directory since the previous version, or is there any chance that another Alias line is taking precedence over the ScriptAlias? Do you see anything in the apache access/error logs that indicates an error? -jc On Tue, May 19, 2015 10:37 am, Cortes, Manny wrote: > Having the same problem after installing 4.3.20 on both Ubuntu server > 14.04 and 15.04. > > Thanks, > > > Manuel A Cortes > > Systems Programmer III > > [IBM_Cert] > > IBM Certified System Administrator AIX 7 > > Information Services > > 321-841-6534 > > Orlandohealth.com > > Facebook.com/orlandohealth > > Youtube.com/orlandohealth > > @orlandohealth on twitter > > > > 1414 Kuhl Avenue.,MP136 > > Orlando, Florida 32806 > > From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Asif Iqbal > Sent: Tuesday, May 19, 2015 12:59 PM > To: J.C. Cleaver > Cc: xymon at xymon.com > Subject: Re: [Xymon] Need help with upgrade from 4.3.17 to 4.3.20 > > > > On Tue, May 19, 2015 at 12:40 PM, J.C. Cleaver > <cleaver at terabithia.org<mailto:cleaver at terabithia.org>> wrote: > Hmm. It seems like it's trying to pass along the binary rather than > actually execute it. Can you > > a) validate the permissions on the various .sh files inside the > /xymon-cgi/ directory. (Wondering if there's a case where make install > doesn't set permissions properly), and > > > /var/lib/xymon/cgi-bin$ ls -al > total 6560 > drwxr-xr-x 2 root root 4096 May 19 10:19 . > drwxr-xr-x 16 xymon xymon 4096 May 19 10:19 .. > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 acknowledgements.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 appfeed-critical.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 appfeed.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 certreport.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 columndoc.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 confreport-critical.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 confreport.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 criticalview.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 csvinfo.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 datepage.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 eventlog.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 findhost.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 ghostlist.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 historylog.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 history.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 hostgraphs.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 hostlist.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 nongreen.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 notifications.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 perfdata.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 reportlog.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 report.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 showgraph.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 snapshot.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 svcstatus.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 topchanges.sh > > > b) verify that the ScriptAlias or ExecCGI options are still present in > apache.conf. > > > grep xymon-cgi /etc/apache2/sites-enabled/xymon-apache.conf > # "/xymon" and "/xymon-cgi" URLs. > ScriptAlias /xymon-cgi/ "/var/lib/xymon/cgi-bin/" > RewriteRule ^/xymon-cgi/bb-hist.sh /xymon-cgi/history.sh [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-eventlog.sh /xymon-cgi/eventlog.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-rep.sh /xymon-cgi/report.sh [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-replog.sh /xymon-cgi/reportlog.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-snapshot.sh /xymon-cgi/snapshot.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-findhost.sh /xymon-cgi/findhost.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-csvinfo.sh /xymon-cgi/csvinfo.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbitcolumn.sh /xymon-cgi/columndoc.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-datepage.sh /xymon-cgi/datepage.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbitgraph.sh /xymon-cgi/showgraph.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-hostsvc.sh /xymon-cgi/svcstatus.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-histlog.sh /xymon-cgi/historylog.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-confreport.sh /xymon-cgi/confreport.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-confreport-critical.sh > /xymon-cgi/confreport-critical.sh [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-nkview.sh /xymon-cgi/criticalview.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-certreport.sh /xymon-cgi/certreport.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-nongreen.sh /xymon-cgi/nongreen.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-hostgraphs.sh /xymon-cgi/hostgraphs.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-ghosts.sh /xymon-cgi/ghostlist.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-notifylog.sh /xymon-cgi/notifications.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-hostlist.sh /xymon-cgi/hostlist.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-perfdata.sh /xymon-cgi/perfdata.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-topchanges.sh /xymon-cgi/topchanges.sh > [R=permanent,L] > > > HTH, > > -jc > > > On Tue, May 19, 2015 7:56 am, Asif Iqbal wrote: >> 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<http://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? >> _______________________________________________ >> Xymon mailing list >> Xymon at xymon.com<mailto:Xymon at xymon.com> >> http://lists.xymon.com/mailman/listinfo/xymon >> > > > > > -- > Asif Iqbal > PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu<http://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? > > ________________________________ > > This e-mail message and any attached files are confidential and are > intended solely for the use of the addressee(s) named above. If you are > not the intended recipient, any review, use, or distribution of this > e-mail message and any attached files is strictly prohibited. > > This communication may contain material protected by Federal privacy > regulations, attorney-client work product, or other privileges. If you > have received this confidential communication in error, please notify the > sender immediately by reply e-mail message and permanently delete the > original message. To reply to our email administrator directly, send an > email to: postmaster at orlandohealth.com . > > If this e-mail message concerns a contract matter, be advised that no > employee or agent is authorized to conclude any binding agreement on > behalf of Orlando Health by e-mail without express written confirmation by > an officer of the corporation. Any views or opinions presented in this > e-mail are solely those of the author and do not necessarily represent > those of Orlando Health. >

8 25

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 07 Nov '17

07 Nov '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

6 7

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

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

Xymon Client Short Hostname (was: Re: xymon for AIX)
by novosirj＠rutgers.edu 31 May '16

31 May '16

You are most welcome. So here’s some followup: many of us have had this problem before, and it seems OS-specific. Is there any way to get this more right by default? I see that many/most of my entries in hosts.cfg have CLIENT:<hostname> specified. My server is Solaris 10, my clients are a mixture of things. > On May 31, 2016, at 5:10 PM, L Foo <wonderfoo2 at gmail.com> wrote: > > Thanks for ALL your valuable feedback! > > The hint from Ryan seemed to have cured the client page reporting issues. As it turned out, the AIX clients in questioned showed up in 'Ghost Clients' list on in short hostname as opposed to it's real FQDN hostname. I've since updated the xymon server side configuration's files for the said AIX clients from FQDN hostname to short hostnames, the client pages were getting proper updates now. Thank you Ryan!!! > > On Thursday, May 26, 2016 12:05 AM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote: > > > On Thu, May 26, 2016 at 4:44 AM L Foo <wonderfoo2 at gmail.com> wrote: > The netcat to port 1984 seems to have went through/connected ok based on below output: > > # nc -v 172.31.2.131 1984 > Ncat: Version 6.40 ( http://nmap.org/ncat ) > Ncat: Connected to 172.31.2.131:1984. > > You ran this on the AIX host? If this works, then telnet should have also worked, and so should the xymon client. > > Can you please try the following (on the AIX host): > > # echo "ping" | nc 127.31.2.131 1984 > > That should return the xymon version details of the Xymon server. > > Then try this: > > # /xymon/bin/xymon 172.31.2.131 ping > > You should see the same thing. Or maybe a timeout > > If this doesn't work, then can you try this: > > # truss -f /xymon/bin/xymon 172.31.2.131 ping > > I'm particularly interested in the output around socket() and connect() calls, and what responses codes are given. > > I'm wondering if you have some sort of kernel-based binary restrictions in place, such as Trusted AIX, TCB or Trusted Execution. From what I can tell, these tools allow one to lock down a server so that no unauthorized binaries can execute, or they might be able to execute but cannot perform certain functions. > > An alternative to all of this is to use my xymon-rclient script, available on xymonton.org, or http://tools.rebel-it.com.au/xymon-rclient. Essentially it allows for an clientless client by pushing the Xymon client script to the target from the Xymon server (typically over ssh) and grabs the client data directly. In this way, it doesn't rely on a xymon client binary. There are some limitations, which is why it's better to try to get your client working, but it may be easier to get something going this way. > > Cheers > Jeremy > > > -- ____ || \\UTGERS, |---------------------------*O*--------------------------- ||_// the State | Ryan Novosielski - novosirj at rutgers.edu || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus || \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark `'

1 0

xymon for AIX
by wonderfoo2＠gmail.com 31 May '16

31 May '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.

6 12

xymonproxy crashing under the load
by jtrott＠dancrai.com 31 May '16

31 May '16

Hi. We have a large xymon setup that averages 25 messages/sec for xymond. I am in the process of migrating to a new xymon server and was planning on using a front end xymonproxy process on a third box to keep traffic going to both old and new boxes while I migrated across the old data (primarily the rrd data as that requires conversion from 32bit to 64bit). The xymonproxy is working fine under light load (20 or so client machines) but when I modify the firewall port forward to point the incoming port 1984 traffic to it it crashes after a few seconds. 2016-05-31 16:08:19.793720 xymonproxy version 4.3.27-1.el7.terabithia starting 2016-05-31 16:08:19.793791 Listening on 0.0.0.0:1984 2016-05-31 16:08:19.793796 Sending to 2 Xymon server(s): 172.16.100.103:1984 172.16.100.101:1984 2016-05-31 16:09:23.010861 conn 0: server 1 (172.16.100.101:1984) not responding, message lost 2016-05-31 16:09:23.011363 conn 0, socket -1: write shutdown failed: Bad file descriptor 2016-05-31 16:09:24.012798 conn 0: server 1 (172.16.100.101:1984) not responding, message lost 2016-05-31 16:09:25.014274 conn 0, socket -1: write shutdown failed: Bad file descriptor *** buffer overflow detected ***: xymonproxy terminated ======= Backtrace: ========= /lib64/libc.so.6(__fortify_fail+0x37)[0x7f234c396597] /lib64/libc.so.6(+0x10c750)[0x7f234c394750] /lib64/libc.so.6(+0x10e507)[0x7f234c396507] xymonproxy[0x403e11] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f234c2a9b15] xymonproxy[0x406579] ======= Memory map: ======== 00400000-0041d000 r-xp 00000000 fd:00 25459501 /usr/libexec/xymon/xymonproxy 0061d000-0061e000 r--p 0001d000 fd:00 25459501 /usr/libexec/xymon/xymonproxy 0061e000-0061f000 rw-p 0001e000 fd:00 25459501 /usr/libexec/xymon/xymonproxy 0061f000-00646000 rw-p 00000000 00:00 0 02472000-025f4000 rw-p 00000000 00:00 0 [heap] 7f234a874000-7f234a889000 r-xp 00000000 fd:00 18879360 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f234a889000-7f234aa88000 ---p 00015000 fd:00 18879360 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f234aa88000-7f234aa89000 r--p 00014000 fd:00 18879360 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f234aa89000-7f234aa8a000 rw-p 00015000 fd:00 18879360 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f234aa8a000-7f234aaae000 r-xp 00000000 fd:00 16856000 /usr/lib64/liblzma.so.5.0.99 7f234aaae000-7f234acad000 ---p 00024000 fd:00 16856000 /usr/lib64/liblzma.so.5.0.99 7f234acad000-7f234acae000 r--p 00023000 fd:00 16856000 /usr/lib64/liblzma.so.5.0.99 7f234acae000-7f234acaf000 rw-p 00024000 fd:00 16856000 /usr/lib64/liblzma.so.5.0.99 7f234acaf000-7f234acd0000 r-xp 00000000 fd:00 16915048 /usr/lib64/libselinux.so.1 7f234acd0000-7f234aed0000 ---p 00021000 fd:00 16915048 /usr/lib64/libselinux.so.1 7f234aed0000-7f234aed1000 r--p 00021000 fd:00 16915048 /usr/lib64/libselinux.so.1 7f234aed1000-7f234aed2000 rw-p 00022000 fd:00 16915048 /usr/lib64/libselinux.so.1 7f234aed2000-7f234aed4000 rw-p 00000000 00:00 0 7f234aed4000-7f234aeea000 r-xp 00000000 fd:00 16855963 /usr/lib64/libresolv-2.17.so 7f234aeea000-7f234b0ea000 ---p 00016000 fd:00 16855963 /usr/lib64/libresolv-2.17.so 7f234b0ea000-7f234b0eb000 r--p 00016000 fd:00 16855963 /usr/lib64/libresolv-2.17.so 7f234b0eb000-7f234b0ec000 rw-p 00017000 fd:00 16855963 /usr/lib64/libresolv-2.17.so 7f234b0ec000-7f234b0ee000 rw-p 00000000 00:00 0 7f234b0ee000-7f234b0f1000 r-xp 00000000 fd:00 17026913 /usr/lib64/libkeyutils.so.1.5 7f234b0f1000-7f234b2f0000 ---p 00003000 fd:00 17026913 /usr/lib64/libkeyutils.so.1.5 7f234b2f0000-7f234b2f1000 r--p 00002000 fd:00 17026913 /usr/lib64/libkeyutils.so.1.5 7f234b2f1000-7f234b2f2000 rw-p 00003000 fd:00 17026913 /usr/lib64/libkeyutils.so.1.5 7f234b2f2000-7f234b2ff000 r-xp 00000000 fd:00 18086631 /usr/lib64/libkrb5support.so.0.1 7f234b2ff000-7f234b4ff000 ---p 0000d000 fd:00 18086631 /usr/lib64/libkrb5support.so.0.1 7f234b4ff000-7f234b500000 r--p 0000d000 fd:00 18086631 /usr/lib64/libkrb5support.so.0.1 7f234b500000-7f234b501000 rw-p 0000e000 fd:00 18086631 /usr/lib64/libkrb5support.so.0.1 7f234b501000-7f234b517000 r-xp 00000000 fd:00 16855957 /usr/lib64/libpthread-2.17.so 7f234b517000-7f234b717000 ---p 00016000 fd:00 16855957 /usr/lib64/libpthread-2.17.so 7f234b717000-7f234b718000 r--p 00016000 fd:00 16855957 /usr/lib64/libpthread-2.17.so 7f234b718000-7f234b719000 rw-p 00017000 fd:00 16855957 /usr/lib64/libpthread-2.17.so 7f234b719000-7f234b71d000 rw-p 00000000 00:00 0 7f234b71d000-7f234b720000 r-xp 00000000 fd:00 17867018 /usr/lib64/libdl-2.17.so 7f234b720000-7f234b91f000 ---p 00003000 fd:00 17867018 /usr/lib64/libdl-2.17.so 7f234b91f000-7f234b920000 r--p 00002000 fd:00 17867018 /usr/lib64/libdl-2.17.so 7f234b920000-7f234b921000 rw-p 00003000 fd:00 17867018 /usr/lib64/libdl-2.17.so 7f234b921000-7f234b950000 r-xp 00000000 fd:00 17149883 /usr/lib64/libk5crypto.so.3.1 7f234b950000-7f234bb4f000 ---p 0002f000 fd:00 17149883 /usr/lib64/libk5crypto.so.3.1 7f234bb4f000-7f234bb51000 r--p 0002e000 fd:00 17149883 /usr/lib64/libk5crypto.so.3.1 7f234bb51000-7f234bb52000 rw-p 00030000 fd:00 17149883 /usr/lib64/libk5crypto.so.3.1 7f234bb52000-7f234bb53000 rw-p 00000000 00:00 0 7f234bb53000-7f234bb56000 r-xp 00000000 fd:00 16915067 /usr/lib64/libcom_err.so.2.1 7f234bb56000-7f234bd55000 ---p 00003000 fd:00 16915067 /usr/lib64/libcom_err.so.2.1 7f234bd55000-7f234bd56000 r--p 00002000 fd:00 16915067 /usr/lib64/libcom_err.so.2.1 7f234bd56000-7f234bd57000 rw-p 00003000 fd:00 16915067 /usr/lib64/libcom_err.so.2.1 7f234bd57000-7f234be2c000 r-xp 00000000 fd:00 17166500 /usr/lib64/libkrb5.so.3.3 7f234be2c000-7f234c02c000 ---p 000d5000 fd:00 17166500 /usr/lib64/libkrb5.so.3.3 7f234c02c000-7f234c039000 r--p 000d5000 fd:00 17166500 /usr/lib64/libkrb5.so.3.3 7f234c039000-7f234c03c000 rw-p 000e2000 fd:00 17166500 /usr/lib64/libkrb5.so.3.3 7f234c03c000-7f234c085000 r-xp 00000000 fd:00 17177116 /usr/lib64/libgssapi_krb5.so.2.2 7f234c085000-7f234c285000 ---p 00049000 fd:00 17177116 /usr/lib64/libgssapi_krb5.so.2.2 7f234c285000-7f234c286000 r--p 00049000 fd:00 17177116 /usr/lib64/libgssapi_krb5.so.2.2 7f234c286000-7f234c288000 rw-p 0004a000 fd:00 17177116 /usr/lib64/libgssapi_krb5.so.2.2 7f234c288000-7f234c43f000 r-xp 00000000 fd:00 16855941 /usr/lib64/libc-2.17.so 7f234c43f000-7f234c63f000 ---p 001b7000 fd:00 16855941 /usr/lib64/libc-2.17.so 7f234c63f000-7f234c643000 r--p 001b7000 fd:00 16855941 /usr/lib64/libc-2.17.so 7f234c643000-7f234c645000 rw-p 001bb000 fd:00 16855941 /usr/lib64/libc-2.17.so 7f234c645000-7f234c64a000 rw-p 00000000 00:00 0 7f234c64a000-7f234c6aa000 r-xp 00000000 fd:00 18095822 /usr/lib64/libpcre.so.1.2.0 7f234c6aa000-7f234c8a9000 ---p 00060000 fd:00 18095822 /usr/lib64/libpcre.so.1.2.0 7f234c8a9000-7f234c8aa000 r--p 0005f000 fd:00 18095822 /usr/lib64/libpcre.so.1.2.0 7f234c8aa000-7f234c8ab000 rw-p 00060000 fd:00 18095822 /usr/lib64/libpcre.so.1.2.0 7f234c8ab000-7f234ca69000 r-xp 00000000 fd:00 17026905 /usr/lib64/libcrypto.so.1.0.1e 7f234ca69000-7f234cc69000 ---p 001be000 fd:00 17026905 /usr/lib64/libcrypto.so.1.0.1e 7f234cc69000-7f234cc83000 r--p 001be000 fd:00 17026905 /usr/lib64/libcrypto.so.1.0.1e 7f234cc83000-7f234cc8f000 rw-p 001d8000 fd:00 17026905 /usr/lib64/libcrypto.so.1.0.1e 7f234cc8f000-7f234cc93000 rw-p 00000000 00:00 0 7f234cc93000-7f234ccf6000 r-xp 00000000 fd:00 18093381 /usr/lib64/libssl.so.1.0.1e 7f234ccf6000-7f234cef5000 ---p 00063000 fd:00 18093381 /usr/lib64/libssl.so.1.0.1e 7f234cef5000-7f234cef9000 r--p 00062000 fd:00 18093381 /usr/lib64/libssl.so.1.0.1e 7f234cef9000-7f234cf00000 rw-p 00066000 fd:00 18093381 /usr/lib64/libssl.so.1.0.1e 7f234cf00000-7f234cf0b000 r-xp 00000000 fd:00 17867002 /usr/lib64/liblz4.so.1.7.1 7f234cf0b000-7f234d10a000 ---p 0000b000 fd:00 17867002 /usr/lib64/liblz4.so.1.7.1 7f234d10a000-7f234d10b000 r--p 0000a000 fd:00 17867002 /usr/lib64/liblz4.so.1.7.1 7f234d10b000-7f234d10c000 rw-p 00000000 00:00 0 7f234d10c000-7f234d121000 r-xp 00000000 fd:00 16915045 /usr/lib64/libz.so.1.2.7 7f234d121000-7f234d320000 ---p 00015000 fd:00 16915045 /usr/lib64/libz.so.1.2.7 7f234d320000-7f234d321000 r--p 00014000 fd:00 16915045 /usr/lib64/libz.so.1.2.7 7f234d321000-7f234d322000 rw-p 00015000 fd:00 16915045 /usr/lib64/libz.so.1.2.7 7f234d322000-7f234d343000 r-xp 00000000 fd:00 18043068 /usr/lib64/ld-2.17.so 7f234d52e000-7f234d538000 rw-p 00000000 00:00 0 7f234d540000-7f234d543000 rw-p 00000000 00:00 0 7f234d543000-7f234d544000 r--p 00021000 fd:00 18043068 /usr/lib64/ld-2.17.so 7f234d544000-7f234d545000 rw-p 00022000 fd:00 18043068 /usr/lib64/ld-2.17.so 7f234d545000-7f234d546000 rw-p 00000000 00:00 0 7ffdfcb9d000-7ffdfcbbf000 rw-p 00000000 00:00 0 [stack] 7ffdfcbdb000-7ffdfcbdd000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] 2016-05-31 16:09:25.092174 xymonproxy version 4.3.27-1.el7.terabithia starting 2016-05-31 16:09:25.092364 Listening on 0.0.0.0:1984 2016-05-31 16:09:25.092379 Sending to 2 Xymon server(s): 172.16.100.103:1984 172.16.100.101:1984 Xymonproxy is running on CentOS 7 with all the latest patches installed. 172.16.100.103 is xymon 4.3.16 on CentOS 5, 172.16.100.101 is xymon 4.3.27-1.el7.terabithia on CentOS 7. Any ideas on how to troubleshoot this further? Thanks, JT

1 1

Bug in client data handling in 4.3.27
by jtrott＠dancrai.com 31 May '16

31 May '16

Hi. We are in the process of migrating xymon from a CentOS 5 server running 4.3.16 to a CentOS 7 server running 4.3.27-1 (terabithia-xymon) and have run into a bug while testing the new install. I have setup a third box with a xymonproxy to allow delivery to both servers at the same time to reduce downtime for the migration of the 200GB or so of historical data. Both servers have identically setup hosts.cfg with almost all clients listed in include and dspinclude (for layout reasons) files. This was working fine in 4.3.16 but on 4.3.27 it works fine for bbwin clients, but not for xymon-client or hobbit-client clients on linux. For the linux clients I get the new clientlog green diamond showing up (once I modified the include file to end in .cfg and added ALLOWALLCONFIGFILES="TRUE" to xymonserver.cfg) but all the other client tests stay purple. If I move one of the linux clients from an include file into the main hosts.cfg file it starts behaving normally. Any ideas? Thanks, JT

1 1