From nmaharaj at tcta.co.za Tue Dec 1 06:38:28 2015 From: nmaharaj at tcta.co.za (Nikesh Maharaj) Date: Tue, 1 Dec 2015 05:38:28 +0000 Subject: [Xymon] http error Message-ID: HTTP/1.1 301 Moved Permanently Content-Type: text/html; charset=UTF-8 Location: http://vip/ESS/ Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Tue, 01 Dec 2015 05:34:57 GMT Connection: close Content-Length: 138 Seconds: 0.003540000 Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and automatically archived by Mimecast SA (Pty) Ltd, an innovator in Software as a Service (SaaS) for business. Mimecast Unified Email Management (UEM) offers email continuity, security, archiving and compliance with all current legislation. To find out more, visit http://www.mimecast.co.za/uem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.kunberger at itv-denkendorf.de Tue Dec 1 09:46:18 2015 From: andreas.kunberger at itv-denkendorf.de (andreas.kunberger at itv-denkendorf.de) Date: Tue, 1 Dec 2015 09:46:18 +0100 Subject: [Xymon] =?iso-8859-1?q?error_installing_Terabithia_rpm__xymon-cli?= =?iso-8859-1?q?ent-4=2E3=2E24-1=2Eel6=2Ex86=5F64?= Message-ID: Since last update I get following error when I try to upgrade the Terabithia RPMs >sudo yum upgrade -C Loaded plugins: fastestmirror, langpacks Resolving Dependencies --> Running transaction check ---> Package xymon-client.x86_64 0:4.3.23-1.el7 will be updated ---> Package xymon-client.x86_64 0:4.3.24-1.1.el7 will be an update --> Processing Dependency: selinux-policy >= 3.13.1-60.el7 for package: xymon-client-4.3.24-1.1.el7.x86_64 --> Finished Dependency Resolution Error: Package: xymon-client-4.3.24-1.1.el7.x86_64 (Xymon) Requires: selinux-policy >= 3.13.1-60.el7 Installed: selinux-policy-3.13.1-23.el7_1.21.noarch (@updates) selinux-policy = 3.13.1-23.el7_1.21 Available: selinux-policy-3.13.1-23.el7.noarch (base) selinux-policy = 3.13.1-23.el7 Available: selinux-policy-3.13.1-23.el7_1.7.noarch (updates) selinux-policy = 3.13.1-23.el7_1.7 Available: selinux-policy-3.13.1-23.el7_1.8.noarch (updates) selinux-policy = 3.13.1-23.el7_1.8 Available: selinux-policy-3.13.1-23.el7_1.13.noarch (updates) selinux-policy = 3.13.1-23.el7_1.13 Available: selinux-policy-3.13.1-23.el7_1.17.noarch (updates) selinux-policy = 3.13.1-23.el7_1.17 Available: selinux-policy-3.13.1-23.el7_1.18.noarch (updates) selinux-policy = 3.13.1-23.el7_1.18 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles -nodigest >cat /etc/redhat-release CentOS Linux release 7.1.1503 (Core) What is the cause and what can I do? Kind regards i.A. Andreas Kunberger -- Deutsche Institute für Textil- und Faserforschung Denkendorf Andreas Kunberger Netzwerk Körschtalstraße 26, 73770 Denkendorf Tel.: +49 (0)7 11 93 40 - 2 58 FAX: +49 (0)7 11 93 40 - 4 15 E-Mail: andreas.kunberger at ditf.de http://www.ditf.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From sys1002 at yahoo.com Tue Dec 1 11:42:21 2015 From: sys1002 at yahoo.com (Michael Resnick) Date: Tue, 1 Dec 2015 10:42:21 +0000 (UTC) Subject: issues with new install References: <927202393.12325429.1448966541680.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <927202393.12325429.1448966541680.JavaMail.yahoo@mail.yahoo.com> Using just rclient latest on rhel 6.6 xymon server with latest rpm - Xymon 4.3.24-1.el6.terabithia the only columns I am getting are clientlog conn info trends why aren't I seeing the rest of the columns ? Any help appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlaidman at rebel-it.com.au Tue Dec 1 14:33:46 2015 From: jlaidman at rebel-it.com.au (Jeremy Laidman) Date: Tue, 01 Dec 2015 13:33:46 +0000 Subject: [Xymon] Bug in TRENDS handling? Message-ID: Hiya I think I've found a rather obscure bug in the handling of the TRENDS overrides in hosts.cfg. For example, the following hosts.cfg entry doesn't do what I'd expect: 192.168.0.1 server1.example.com # TRENDS:*,netstat_enhanced:ns1|ns2,netstat:netstat|netstat1 (Assume that GRAPHS in xymonserver.cfg includes "netstat" and "netstat_enhanced".) I would expect that the trends page for this host would have graphs of ns1, ns2 (in place of netstat_enhanced), and netstat and netstat1 (in place of just netstat). However, it appears that the "nestat_enhanced" entry masks the "netstat" entry, and the latter is set to the default of showing only the "netstat" graph. Another example is, if I have TRENDS:*,_vmstat_,vmstat:vmstat|vmstat3|vmstat4|vmstat5,... then my trends page shows only the one "vmstat" graph. After removing the "_vmstat_" I get four vmstat graphs as specified. If I upper-case any of the characters in the earlier definition, or if I move the definition to be later, everything works as expected. I had a quick look at the code, but I can't read C well enough to find the bug. Although I'm starting to suspect that the strstr() in svcstatus-trends.c might be successfully sub-string matching. Instead, it should match only a whole word (perhaps terminated by whitespace, comman, pipe and colon. But this is a guess, really. J -------------- next part -------------- An HTML attachment was scrubbed... URL: From cleaver at terabithia.org Tue Dec 1 16:22:13 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 1 Dec 2015 07:22:13 -0800 Subject: [Xymon] error installing Terabithia rpm xymon-client-4.3.24-1.el6.x86_64 In-Reply-To: References: Message-ID: Hi, thanks, It looks like CentOS pulled (or hasn't yet built) the selinux-policy-3.13.1-60 update in from RHEL 7 yet; several others have now reported this same problem. Can you try installing the 4.3.24-2 RPMs from http://terabithia.org/rpms/xymon/testing/el7/x86_64/ ? I downgraded the SELinux policy package on the build system to match what CentOS has actually pushed out. If it works, I'll push that into production. HTH, -jc On Tue, December 1, 2015 12:46 am, andreas.kunberger at itv-denkendorf.de wrote: > Since last update I get following error when I try to upgrade the > Terabithia RPMs > > >>sudo yum upgrade -C > > Loaded plugins: fastestmirror, langpacks > > Resolving Dependencies > > --> Running transaction check > > ---> Package xymon-client.x86_64 0:4.3.23-1.el7 will be updated > > ---> Package xymon-client.x86_64 0:4.3.24-1.1.el7 will be an update > > --> Processing Dependency: selinux-policy >= 3.13.1-60.el7 for package: > xymon-client-4.3.24-1.1.el7.x86_64 > > --> Finished Dependency Resolution > > Error: Package: xymon-client-4.3.24-1.1.el7.x86_64 (Xymon) > > Requires: selinux-policy >= 3.13.1-60.el7 > > Installed: selinux-policy-3.13.1-23.el7_1.21.noarch (@updates) > > selinux-policy = 3.13.1-23.el7_1.21 > > Available: selinux-policy-3.13.1-23.el7.noarch (base) > > selinux-policy = 3.13.1-23.el7 > > Available: selinux-policy-3.13.1-23.el7_1.7.noarch (updates) > > selinux-policy = 3.13.1-23.el7_1.7 > > Available: selinux-policy-3.13.1-23.el7_1.8.noarch (updates) > > selinux-policy = 3.13.1-23.el7_1.8 > > Available: selinux-policy-3.13.1-23.el7_1.13.noarch (updates) > > selinux-policy = 3.13.1-23.el7_1.13 > > Available: selinux-policy-3.13.1-23.el7_1.17.noarch (updates) > > selinux-policy = 3.13.1-23.el7_1.17 > > Available: selinux-policy-3.13.1-23.el7_1.18.noarch (updates) > > selinux-policy = 3.13.1-23.el7_1.18 > > You could try using --skip-broken to work around the problem > > You could try running: rpm -Va --nofiles -nodigest > > > >>cat /etc/redhat-release > > CentOS Linux release 7.1.1503 (Core) > > > What is the cause and what can I do? > > > Kind regards > > > i.A. Andreas Kunberger > > > -- > > > Deutsche Institute für Textil- und Faserforschung Denkendorf > > > Andreas Kunberger > > Netzwerk > > Körschtalstraße 26, 73770 Denkendorf > > > Tel.: +49 (0)7 11 93 40 - 2 58 > > FAX: +49 (0)7 11 93 40 - 4 15 > > E-Mail: andreas.kunberger at ditf.de > > http://www.ditf.de > > > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon > From cleaver at terabithia.org Tue Dec 1 16:29:18 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 1 Dec 2015 07:29:18 -0800 Subject: [Xymon] http error In-Reply-To: References: Message-ID: On Mon, November 30, 2015 9:38 pm, Nikesh Maharaj wrote: > > I configured xymon to monitor http on one of my servers. After xymon > upgrade, the icon is now orange with the following error. Am I doing > something wrong ? > > Xymon 4.3.24-1.el6.terabithia > > HTTP/1.1 301 Moved Permanently > Content-Type: text/html; charset=UTF-8 > Location: http://vip/ESS/ > Server: Microsoft-IIS/7.5 > X-Powered-By: ASP.NET > Date: Tue, 01 Dec 2015 05:34:57 GMT > Connection: close > Content-Length: 138 > > Seconds: 0.003540000 > Hi, This is an intentional 'Warning' that the URL checked is actually a permanent redirect, to remind you that Xymon isn't checking the actual URL that end users are being sent off to (in this case, "http://vip/ESS/"). To clear this, change the original URL you're checking to "httpstatus;YOURORIGINALURLHERE;301;" . You may want to check the destination as a separate URL as well. A future xymon version will allow status code logic to be specified by config as well. Regards, -jc From cleaver at terabithia.org Tue Dec 1 16:31:31 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 1 Dec 2015 07:31:31 -0800 Subject: [Xymon] issues with new install In-Reply-To: References: <927202393.12325429.1448966541680.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <03db75f98ec85750f1dc528e871df740.squirrel@mail.kkytbs.net> On Tue, December 1, 2015 2:42 am, Michael Resnick wrote: > Using just rclient latest on rhel 6.6 xymon server with latest rpm - Xymon > 4.3.24-1.el6.terabithiaÂ > the only columns I am getting are clientlog conn info trends > > why aren't I seeing the rest of the columns ? > > Any help appreciated. > Hi, I'm not incredibly familiar with rclient logistics, but it sounds like the issue might stem from xymond_client either not running or not knowing to process the incoming client message being received for the server. Are you receiving all the columns (disk, cpu, memory, etc...) for the xymon server *itself* and not getting them for a separate server you're trying to check with rclient? Or does nothing listed have a set of columns at all? -jc From sys1002 at yahoo.com Tue Dec 1 17:04:57 2015 From: sys1002 at yahoo.com (Michael Resnick) Date: Tue, 1 Dec 2015 16:04:57 +0000 (UTC) Subject: issues with new install In-Reply-To: <03db75f98ec85750f1dc528e871df740.squirrel@mail.kkytbs.net> References: <03db75f98ec85750f1dc528e871df740.squirrel@mail.kkytbs.net> Message-ID: <449603622.12688608.1448985897137.JavaMail.yahoo@mail.yahoo.com> xymon server itself is fine. All the other servers are tests with conn only, with just 2 havingxymon client and 6 running rclient. none of the servers have a full set of columns except the xymon server.rclient log shows successfully completed 6 servers and the clientlog looks good. I may try rolling back to 4.3.21 or earlier. The last I used at my previous job was 4.3.11 It is a pain to install , since I have no Internet access in this environment. From: J.C. Cleaver To: Michael Resnick Cc: Xymon Mailing List Sent: Tuesday, December 1, 2015 5:31 PM Subject: Re: issues with new install On Tue, December 1, 2015 2:42 am, Michael Resnick wrote: > Using just rclient latest on rhel 6.6 xymon server with latest rpm - Xymon > 4.3.24-1.el6.terabithiaÂ > the only columns I am getting are clientlog conn info trends > > why aren't I seeing the rest of the columns ? > > Any help appreciated. > Hi, I'm not incredibly familiar with rclient logistics, but it sounds like the issue might stem from xymond_client either not running or not knowing to process the incoming client message being received for the server. Are you receiving all the columns (disk, cpu, memory, etc...) for the xymon server *itself* and not getting them for a separate server you're trying to check with rclient? Or does nothing listed have a set of columns at all? -jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From cleaver at terabithia.org Tue Dec 1 17:33:08 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 1 Dec 2015 08:33:08 -0800 Subject: [Xymon] Bug in TRENDS handling? In-Reply-To: References: Message-ID: <4cdbb3d9fa53160007fc35fad2a1bf27.squirrel@mail.kkytbs.net> On Tue, December 1, 2015 5:33 am, Jeremy Laidman wrote: > Hiya > > I think I've found a rather obscure bug in the handling of the TRENDS > overrides in hosts.cfg. For example, the following hosts.cfg entry > doesn't > do what I'd expect: > > 192.168.0.1 server1.example.com # > TRENDS:*,netstat_enhanced:ns1|ns2,netstat:netstat|netstat1 > > (Assume that GRAPHS in xymonserver.cfg includes "netstat" and > "netstat_enhanced".) > > I would expect that the trends page for this host would have graphs of > ns1, > ns2 (in place of netstat_enhanced), and netstat and netstat1 (in place of > just netstat). > > However, it appears that the "nestat_enhanced" entry masks the "netstat" > entry, and the latter is set to the default of showing only the "netstat" > graph. > > Another example is, if I have > TRENDS:*,_vmstat_,vmstat:vmstat|vmstat3|vmstat4|vmstat5,... > then my trends page shows only the one "vmstat" graph. After removing the > "_vmstat_" I get four vmstat graphs as specified. > > If I upper-case any of the characters in the earlier definition, or if I > move the definition to be later, everything works as expected. > > I had a quick look at the code, but I can't read C well enough to find the > bug. Although I'm starting to suspect that the strstr() in > svcstatus-trends.c might be successfully sub-string matching. Instead, it > should match only a whole word (perhaps terminated by whitespace, comman, > pipe and colon. But this is a guess, really. > > J That's an interesting one. This is not particularly well tested, but can you see if this patch fixes the issue you're seeing? It's basically just a transplant of the logic that was being used in the 'acceptonly' patch for isolation. -jc -------------- next part -------------- A non-text attachment was scrubbed... Name: xymon.trendspartial.patch Type: text/x-patch Size: 893 bytes Desc: not available URL: From rs at sys4.de Tue Dec 1 17:32:24 2015 From: rs at sys4.de (Robert Schetterer) Date: Tue, 1 Dec 2015 17:32:24 +0100 Subject: [Xymon] journalctl log monitoring Message-ID: <565DCB98.9090003@sys4.de> Hi, is there allready work done with xymon-client log monitor and journalctl, means without syslog running ? Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From john.thurston at alaska.gov Tue Dec 1 18:14:20 2015 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 01 Dec 2015 08:14:20 -0900 Subject: [Xymon] xymon hostdata module going rogue In-Reply-To: <2a97f13340498d494247f361400f0249.squirrel@mail.kkytbs.net> References: <17082AAFC33A934082836458CB53494367323DD1@MONDB03.na.lzb.hq> <55E0C860.8020900@alaska.gov> <55E0DDA0.2070906@alaska.gov> <2a97f13340498d494247f361400f0249.squirrel@mail.kkytbs.net> Message-ID: <565DD56C.7060809@alaska.gov> How embarrassing. I was composing a note to mention a problem with the list archives not capturing all messages . . . when I discovered that the message for which I was searching was never sent to the list. I composed the following message back in early October and then sent it only to myself :p No wonder it didn't generate any chatter. On 8/28/2015 3:12 PM, J.C. Cleaver wrote: > On Fri, August 28, 2015 3:16 pm, John Thurston wrote: >> On 8/28/2015 12:45 PM, John Thurston wrote: >>> On 6/10/2015 9:01 AM, Scot Kreienkamp wrote: >>>> I have a xymon server running 4.3.21 that seems to be accumulating >>>> processes like these: >>>> >>>> hobbit 28430 0.0 0.0 0 0 ? Z 12:50 0:00 >>>> [xymond_hostdata] . . . >>>> >>>> It seemed related to drop messages . . . >>> >>> Hey, I think I'm seeing the same thing on Solaris with 4.3.21 >>> >>> I've ended up here after a customer let me know that email alerts were >>> not working as expected. After a few hours of digging around, I decided >>> that the alert daemon was failing to retrieve hostnames and failing >>> miserably. >>> >>> Have other people seen this behavior? >> >> I have duplicated this behavior on another xymon server on Solaris. It >> certainly looks like this behavior breaks the alert daemon. Fortunately, >> I "drop" hosts in batches so can restart Xymon at that time, but this is >> still pretty icky. >> >> J.C., do you know if your patch made it into the code-base? >> >> Has anyone else tested this patch? If so, on what operating systems? This patch took care of the defunct/zonebie processes on "drop" events, but I've just discovered that it does not solve the underlying problem. It still appears that xymond_hostdata does not behave correctly following a "drop" command. The effect is that alerts fail to be delivered for _some_ messages because hostnames can no longer be retrieved. Example: My xymon server is humming along. I have the alert module debug-logging to alerts.log. Immediately after issuing a "drop" command of the sort: #xymon localhost "drop foo.bar.com sslcert" the following sorts appear in the alerts.log. After this, some messages may result in alert emails being sent, but most quietly disappear. Currently, my resolution is to "xymon.sh restart" but that is much too heavy handed for long term use. > 21178 2015-10-05 16:39:43.257559 get_xymond_message: Interrupted > 21178 2015-10-05 16:39:43.257624 No files modified, skipping reload of /opt/xymon/server/etc/alerts.cfg > 21178 2015-10-05 16:39:43.257680 No files modified, skipping reload of /opt/xymon/server/etc/holidays.cfg > 21178 2015-10-05 16:39:43.257718 Checking criteria for host 'doadrbjnu-sp.bar.com', which is not defined > 21178 2015-10-05 16:39:43.257773 Found a first matching rule > 21178 2015-10-05 16:39:43.257802 Checking criteria for host 'doadrbjnu-sp.bar.com', which is not defined > 21178 2015-10-05 16:39:43.257830 Checking criteria for host 'doadrbjnu-sp.bar.com', which is not defined > 21178 2015-10-05 16:39:43.257854 Found a first matching rule > 21178 2015-10-05 16:39:43.257879 Checking criteria for host 'doadrbjnu-sp.bar.com', which is not defined > 21178 2015-10-05 16:39:43.257910 Checking criteria for host 'steam.bar.com', which is not defined > 21178 2015-10-05 16:39:43.257935 Found a first matching rule > 21178 2015-10-05 16:39:43.257960 Checking criteria for host 'steam.bar.com', which is not defined > 21178 2015-10-05 16:39:43.257986 Checking criteria for host 'steam.bar.com', which is not defined > 21178 2015-10-05 16:39:43.258010 Found a first matching rule > 21178 2015-10-05 16:39:43.258035 Checking criteria for host 'steam.bar.com', which is not defined > 21178 2015-10-05 16:39:43.258061 Checking criteria for host 'upsjdc.bar.com', which is not defined > 21178 2015-10-05 16:39:43.258088 Found a first matching rule > 21178 2015-10-05 16:39:43.258113 Checking criteria for host 'upsjdc.bar.com', which is not defined > 21178 2015-10-05 16:39:43.258140 Checking criteria for host 'upsjdc.bar.com', which is not defined > 21178 2015-10-05 16:39:43.258164 Found a first matching rule > 21178 2015-10-05 16:39:43.258188 Checking criteria for host 'upsjdc.bar.com', which is not defined > 21178 2015-10-05 16:39:43.258211 0 alerts to go > 21178 2015-10-05 16:39:43.258270 Want msg 5039, startpos 134769, fillpos 134769, endpos -1, usedbytes=0, bufleft=131470 > 21178 2015-10-05 16:39:47.962032 Got 2831 bytes > 21178 2015-10-05 16:39:47.962143 xymond_alert: Got message 5039 @@page#5039/soajnuexhs1.bar.com|1444091987.961845|10.2.3.40|soajnuexhs1.bar.com|msgs|0.0.0.0|1444093787|red|red|1444088306|ETS/MsgDir|540754|||| > 21178 2015-10-05 16:39:47.962171 startpos 137600, fillpos 137600, endpos -1 > 21178 2015-10-05 16:39:47.962204 Got page message from soajnuexhs1.bar.com:msgs > 21178 2015-10-05 16:39:47.962252 Want msg 5040, startpos 137600, fillpos 137600, endpos -1, usedbytes=0, bufleft=128639 > 21178 2015-10-05 16:39:58.022397 Got 297 bytes > 21178 2015-10-05 16:39:58.022526 xymond_alert: Got message 5040 @@page#5040/doadofjdc-ea05p.bar.com|1444091998.022274|10.2.167.44|doadofjdc-ea05p.bar.com|msgs|0.0.0.0|1444093798|green|red|1444091998|DOA/IRIS||||| > 21178 2015-10-05 16:39:58.022558 startpos 137897, fillpos 137897, endpos -1 > 21178 2015-10-05 16:39:58.022593 Got page message from doadofjdc-ea05p.bar.com:msgs > 21178 2015-10-05 16:39:58.022630 Alert status changed from 1 to 0 > 21178 2015-10-05 16:39:58.022666 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.022706 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.022739 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.022776 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.022808 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.022841 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.022873 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.022904 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.022935 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.022967 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.022998 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.023028 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.023059 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.023089 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.023120 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.023151 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.023187 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.023221 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.023252 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.023282 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.023313 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.023342 Checking criteria for host 'doadofjdc-ea05p.bar.com', which is not defined > 21178 2015-10-05 16:39:58.023369 Found no first matching rule > 21178 2015-10-05 16:39:58.023402 Want msg 5041, startpos 137897, fillpos 137897, endpos -1, usedbytes=0, bufleft=128342 > 21178 2015-10-05 16:40:10.109262 get_xymond_message: Returning NULL due to EOF -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska From john.thurston at alaska.gov Tue Dec 1 18:32:58 2015 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 01 Dec 2015 08:32:58 -0900 Subject: [Xymon] xymon hostdata module going rogue In-Reply-To: <565DD56C.7060809@alaska.gov> References: <17082AAFC33A934082836458CB53494367323DD1@MONDB03.na.lzb.hq> <55E0C860.8020900@alaska.gov> <55E0DDA0.2070906@alaska.gov> <2a97f13340498d494247f361400f0249.squirrel@mail.kkytbs.net> <565DD56C.7060809@alaska.gov> Message-ID: <565DD9CA.6060604@alaska.gov> I was bit by this in the middle of November, and didn't notice it until a customer alerted me today to a shortage of email messages. To recap: Some alerts get sent correctly, but in other cases the alert daemon aborts message processing and no alert is sent. In the cases where the daemon stops processing, my debug log begins to accumulate messages of the sort: > 1730 2015-12-01 07:58:39.501785 Checking criteria for host 'upsjdc.state.ak.us', which is not defined There is sometimes a process left hanging around. At other times there is not. Performing a "xymon.sh restart" makes it all work again. Today, I had a process tree something like: > 29118 /opt/xymon/server/bin/xymonlaunch --config=/opt/xymon/server/etc/tasks.cfg --en > 29119 xymond --pidfile=/var/log/xymon/xymond.pid --restart=/opt/xymon/server/tmp/xymo > 29120 /opt/xymon/server/bin/xymonfetch --id=1 --interval=79 --no-daemon --pidfile=/va > 29144 xymond_channel --channel=stachg --log=/var/log/xymon/history.log xymond_history > 29201 xymond_history --pidfile=/var/log/xymon/xymond_history.pid > 29145 xymond_channel --channel=page --log=/var/log/xymon/alert.log xymond_alert --deb > 29307 xymond_alert --debug --checkpoint-file=/opt/xymon/server/tmp/alert.chk --checkp > 1588 I killed off PID 29145, it was recreated, and the alerts began flowing again. In this occurrence, it does not appear to be related to a "drop" message. My last recorded "drop" was at 20151103-0846 and the alert process didn't start logging "which is not defined" until 20151120-0007 The only thing I can think to do now is make my xymon client monitor the alert.log and warn me when "which is not defined" start appearing so I can manually kill/restart the process. -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska From john.thurston at alaska.gov Tue Dec 1 21:06:52 2015 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 01 Dec 2015 11:06:52 -0900 Subject: [Xymon] PID file for XYMOND_ALERT Message-ID: <565DFDDC.8020906@alaska.gov> So that I can kill off my errant process and keep xymon alerts flowing, I need to identify that process. It seems like it would be simple to get the right PID. I have xymon_history writing a pid file when it is launched with the following line in my tasks.cfg > CMD xymond_channel --channel=stachg --log=$XYMONSERVERLOGS/h.log xymond_history --pidfile=$XYMONSERVERLOGS/x_h.pid But I am unable to get xymon_alert to create this pid file. It isn't a documented option on the man-page, but I had hoped the capability was buried in the there anyway. It doesn't appear to be so :( So I thought maybe I could get the pid of the parent by specifying --pidfile on that instance of xymond_channel with: > CMD xymond_channel --channel=page --log=$XYMONSERVERLOGS/a.log --pidfile=$XYMONSERVERLOGS/x_a.pid xymond_alert --debug --checkpoint-file=$XYMONTMP/a.chk --checkpoint-interval=600 but this doesn't seem to work either. The only way I can think to identify the process is to pgrep -f "xymond_channel --channel=page" which seems like a long way around the barn, but I can make it work. Should I be able to get a pidfile written for this worker process, or it simply impossible? -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska From cleaver at terabithia.org Tue Dec 1 21:48:14 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 1 Dec 2015 12:48:14 -0800 Subject: [Xymon] alert/hostname loading (was Re: xymon hostdata module going rogue) In-Reply-To: <565DD56C.7060809@alaska.gov> References: <17082AAFC33A934082836458CB53494367323DD1@MONDB03.na.lzb.hq> <55E0C860.8020900@alaska.gov> <55E0DDA0.2070906@alaska.gov> <2a97f13340498d494247f361400f0249.squirrel@mail.kkytbs.net> <565DD56C.7060809@alaska.gov> Message-ID: <877291f035406a2f8d4f9a854fe3e158.squirrel@mail.kkytbs.net> On Tue, December 1, 2015 9:14 am, John Thurston wrote: > How embarrassing. I was composing a note to mention a problem with the > list archives not capturing all messages . . . when I discovered that > the message for which I was searching was never sent to the list. > > I composed the following message back in early October and then sent it > only to myself :p No wonder it didn't generate any chatter. > > On 8/28/2015 3:12 PM, J.C. Cleaver wrote: >> On Fri, August 28, 2015 3:16 pm, John Thurston wrote: >>> On 8/28/2015 12:45 PM, John Thurston wrote: >>>> On 6/10/2015 9:01 AM, Scot Kreienkamp wrote: >>>>> I have a xymon server running 4.3.21 that seems to be accumulating >>>>> processes like these: >>>>> >>>>> hobbit 28430 0.0 0.0 0 0 ? Z 12:50 0:00 >>>>> [xymond_hostdata] > . . . >>>>> >>>>> It seemed related to drop messages . . . >>>> >>>> Hey, I think I'm seeing the same thing on Solaris with 4.3.21 >>>> >>>> I've ended up here after a customer let me know that email alerts were >>>> not working as expected. After a few hours of digging around, I >>>> decided >>>> that the alert daemon was failing to retrieve hostnames and failing >>>> miserably. >>>> >>>> Have other people seen this behavior? >>> >>> I have duplicated this behavior on another xymon server on Solaris. It >>> certainly looks like this behavior breaks the alert daemon. >>> Fortunately, >>> I "drop" hosts in batches so can restart Xymon at that time, but this >>> is >>> still pretty icky. >>> >>> J.C., do you know if your patch made it into the code-base? >>> >>> Has anyone else tested this patch? If so, on what operating systems? > > This patch took care of the defunct/zonebie processes on "drop" events, > but I've just discovered that it does not solve the underlying problem. > It still appears that xymond_hostdata does not behave correctly > following a "drop" command. The effect is that alerts fail to be > delivered for _some_ messages because hostnames can no longer be > retrieved. > > Example: > > My xymon server is humming along. I have the alert module debug-logging > to alerts.log. Immediately after issuing a "drop" command of the sort: > > #xymon localhost "drop foo.bar.com sslcert" > > the following sorts appear in the alerts.log. After this, some messages > may result in alert emails being sent, but most quietly disappear. > Currently, my resolution is to "xymon.sh restart" but that is much too > heavy handed for long term use. > >> 21178 2015-10-05 16:39:43.257559 get_xymond_message: Interrupted >> 21178 2015-10-05 16:39:43.257624 No files modified, skipping reload of >> /opt/xymon/server/etc/alerts.cfg >> 21178 2015-10-05 16:39:43.257680 No files modified, skipping reload of >> /opt/xymon/server/etc/holidays.cfg >> 21178 2015-10-05 16:39:43.257718 Checking criteria for host >> 'doadrbjnu-sp.bar.com', which is not defined >> 21178 2015-10-05 16:39:43.257773 Found a first matching rule >> 21178 2015-10-05 16:39:43.257802 Checking criteria for host >> 'doadrbjnu-sp.bar.com', which is not defined >> 21178 2015-10-05 16:39:43.257830 Checking criteria for host >> 'doadrbjnu-sp.bar.com', which is not defined >> 21178 2015-10-05 16:39:43.257854 Found a first matching rule >> 21178 2015-10-05 16:39:43.257879 Checking criteria for host >> 'doadrbjnu-sp.bar.com', which is not defined >> 21178 2015-10-05 16:39:43.257910 Checking criteria for host >> 'steam.bar.com', which is not defined >> 21178 2015-10-05 16:39:43.257935 Found a first matching rule >> 21178 2015-10-05 16:39:43.257960 Checking criteria for host >> 'steam.bar.com', which is not defined >> 21178 2015-10-05 16:39:43.257986 Checking criteria for host >> 'steam.bar.com', which is not defined >> 21178 2015-10-05 16:39:43.258010 Found a first matching rule >> 21178 2015-10-05 16:39:43.258035 Checking criteria for host >> 'steam.bar.com', which is not defined >> 21178 2015-10-05 16:39:43.258061 Checking criteria for host >> 'upsjdc.bar.com', which is not defined >> 21178 2015-10-05 16:39:43.258088 Found a first matching rule >> 21178 2015-10-05 16:39:43.258113 Checking criteria for host >> 'upsjdc.bar.com', which is not defined >> 21178 2015-10-05 16:39:43.258140 Checking criteria for host >> 'upsjdc.bar.com', which is not defined >> 21178 2015-10-05 16:39:43.258164 Found a first matching rule >> 21178 2015-10-05 16:39:43.258188 Checking criteria for host >> 'upsjdc.bar.com', which is not defined >> 21178 2015-10-05 16:39:43.258211 0 alerts to go >> 21178 2015-10-05 16:39:43.258270 Want msg 5039, startpos 134769, fillpos >> 134769, endpos -1, usedbytes=0, bufleft=131470 >> 21178 2015-10-05 16:39:47.962032 Got 2831 bytes >> 21178 2015-10-05 16:39:47.962143 xymond_alert: Got message 5039 >> @@page#5039/soajnuexhs1.bar.com|1444091987.961845|10.2.3.40|soajnuexhs1.bar.com|msgs|0.0.0.0|1444093787|red|red|1444088306|ETS/MsgDir|540754|||| >> 21178 2015-10-05 16:39:47.962171 startpos 137600, fillpos 137600, endpos >> -1 >> 21178 2015-10-05 16:39:47.962204 Got page message from >> soajnuexhs1.bar.com:msgs >> 21178 2015-10-05 16:39:47.962252 Want msg 5040, startpos 137600, fillpos >> 137600, endpos -1, usedbytes=0, bufleft=128639 >> 21178 2015-10-05 16:39:58.022397 Got 297 bytes >> 21178 2015-10-05 16:39:58.022526 xymond_alert: Got message 5040 >> @@page#5040/doadofjdc-ea05p.bar.com|1444091998.022274|10.2.167.44|doadofjdc-ea05p.bar.com|msgs|0.0.0.0|1444093798|green|red|1444091998|DOA/IRIS||||| >> 21178 2015-10-05 16:39:58.022558 startpos 137897, fillpos 137897, endpos >> -1 >> 21178 2015-10-05 16:39:58.022593 Got page message from >> doadofjdc-ea05p.bar.com:msgs >> 21178 2015-10-05 16:39:58.022630 Alert status changed from 1 to 0 >> 21178 2015-10-05 16:39:58.022666 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.022706 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.022739 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.022776 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.022808 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.022841 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.022873 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.022904 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.022935 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.022967 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.022998 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.023028 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.023059 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.023089 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.023120 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.023151 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.023187 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.023221 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.023252 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.023282 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.023313 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.023342 Checking criteria for host >> 'doadofjdc-ea05p.bar.com', which is not defined >> 21178 2015-10-05 16:39:58.023369 Found no first matching rule >> 21178 2015-10-05 16:39:58.023402 Want msg 5041, startpos 137897, fillpos >> 137897, endpos -1, usedbytes=0, bufleft=128342 >> 21178 2015-10-05 16:40:10.109262 get_xymond_message: Returning NULL due >> to EOF Hmm. This seems to be fundamentally a different issue than the "hostdata module going rogue" thing, which was about zombies never being picked up. AFAICT, somehow the hosts tree structure is getting clobbered as a result of the drop (assuming all of those hosts are expected to be existing). There were a few patches for things in xymond.c at one point, and more error checking when going to POSIX btrees generally, but I hadn't encountered this in other intermittent hostlist readers. 1) Which version of Solaris is this? 2) Have you experienced this in other workers for xymon? (IE, xymond_client not being able to look up hostnames after a drop -- would probably lead to random purples) 3) Does issuing a "reload" command or -HUP to xymond_alert re-sync things? -jc From cleaver at terabithia.org Tue Dec 1 21:51:12 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 1 Dec 2015 12:51:12 -0800 Subject: [Xymon] xymon hostdata module going rogue In-Reply-To: <565DD9CA.6060604@alaska.gov> References: <17082AAFC33A934082836458CB53494367323DD1@MONDB03.na.lzb.hq> <55E0C860.8020900@alaska.gov> <55E0DDA0.2070906@alaska.gov> <2a97f13340498d494247f361400f0249.squirrel@mail.kkytbs.net> <565DD56C.7060809@alaska.gov> <565DD9CA.6060604@alaska.gov> Message-ID: <5686d2addd15045a2254438e0ba7a9f5.squirrel@mail.kkytbs.net> On Tue, December 1, 2015 9:32 am, John Thurston wrote: *snip* > In this occurrence, it does not appear to be related to a "drop" > message. My last recorded "drop" was at 20151103-0846 and the alert > process didn't start logging "which is not defined" until 20151120-0007 Hmm. Okay, that does change things slightly. Fortunately, that means it's probably specifically caused by drops per se. Were there any other errors that occurred with other components around this time? Perhaps the system being low enough on memory that some re-allocations might have failed? Regards, -jc From cleaver at terabithia.org Tue Dec 1 21:57:20 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 1 Dec 2015 12:57:20 -0800 Subject: [Xymon] PID file for XYMOND_ALERT In-Reply-To: <565DFDDC.8020906@alaska.gov> References: <565DFDDC.8020906@alaska.gov> Message-ID: <6acd06c8d766aed57e6a85e63285b3ab.squirrel@mail.kkytbs.net> On Tue, December 1, 2015 12:06 pm, John Thurston wrote: > So that I can kill off my errant process and keep xymon alerts flowing, > I need to identify that process. It seems like it would be simple to get > the right PID. I have xymon_history writing a pid file when it is > launched with the following line in my tasks.cfg > >> CMD xymond_channel --channel=stachg --log=$XYMONSERVERLOGS/h.log >> xymond_history --pidfile=$XYMONSERVERLOGS/x_h.pid > > But I am unable to get xymon_alert to create this pid file. It isn't a > documented option on the man-page, but I had hoped the capability was > buried in the there anyway. It doesn't appear to be so :( > > So I thought maybe I could get the pid of the parent by specifying > --pidfile on that instance of xymond_channel with: > >> CMD xymond_channel --channel=page --log=$XYMONSERVERLOGS/a.log >> --pidfile=$XYMONSERVERLOGS/x_a.pid xymond_alert --debug >> --checkpoint-file=$XYMONTMP/a.chk --checkpoint-interval=600 > > but this doesn't seem to work either. Unfortunately, this isn't an option with xymond_alert as-is, although it will be with 4.4 (since the --pid-file option will be in a standard library), and 4.4 (and the Terabithia RPMs) have a 'PIDFILE' option in tasks.cfg for controlling this at the xymonlaunch level too. The idea to have xymond_channel write out pid files too is an interesting one -- something I hadn't considered -- and might be able to be added in some form in 4.4. (How it could interact with --multilocal would be interesting, though...) > The only way I can think to > identify the process is to > pgrep -f "xymond_channel --channel=page" > which seems like a long way around the barn, but I can make it work. > > Should I be able to get a pidfile written for this worker process, or it > simply impossible? > This is probably the easiest in this case. Really, the xymond_channel process can substitute for xymond_alert in this case since xymond_channel will kill the worker(s) when it terminates itself (under normal circumstances). HTH, -jc From cleaver at terabithia.org Tue Dec 1 22:00:31 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 1 Dec 2015 13:00:31 -0800 Subject: [Xymon] issues with new install In-Reply-To: <449603622.12688608.1448985897137.JavaMail.yahoo@mail.yahoo.com> References: <03db75f98ec85750f1dc528e871df740.squirrel@mail.kkytbs.net> <449603622.12688608.1448985897137.JavaMail.yahoo@mail.yahoo.com> Message-ID: <46385f7a86d82e8d07ea64c0a65e7dad.squirrel@mail.kkytbs.net> On Tue, December 1, 2015 8:04 am, Michael Resnick wrote: > xymon server itself is fine. All the other servers are tests with conn > only, with just 2 havingxymon client and 6 running rclient. > none of the servers have a full set of columns except the xymon > server.rclient log shows successfully completed 6 servers and the > clientlog looks good. > I may try rolling back to 4.3.21 or earlier. The last I used at my > previous job was 4.3.11 > It is a pain to install , since I have no Internet access in this > environment. Can you edit tasks.cfg to run "xymond_client" (in the [clientdata] section) in --debug mode and see if you see data for these clients? Also, can you confirm that the non-xymonserver client (the "non-rclient" one) is working OK and you're getting status messages for? It seems like either a well-formed client message isn't making its way in in the first place, or xymond_client isn't properly processing it back into xymond. Either way, we should be able to see some evidence (or not) in the xymond_client logs as the clientlog injections occur. HTH, -jc From john.thurston at alaska.gov Tue Dec 1 22:03:03 2015 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 01 Dec 2015 12:03:03 -0900 Subject: [Xymon] alert/hostname loading (was Re: xymon hostdata module going rogue) In-Reply-To: <877291f035406a2f8d4f9a854fe3e158.squirrel@mail.kkytbs.net> References: <17082AAFC33A934082836458CB53494367323DD1@MONDB03.na.lzb.hq> <55E0C860.8020900@alaska.gov> <55E0DDA0.2070906@alaska.gov> <2a97f13340498d494247f361400f0249.squirrel@mail.kkytbs.net> <565DD56C.7060809@alaska.gov> <877291f035406a2f8d4f9a854fe3e158.squirrel@mail.kkytbs.net> Message-ID: <565E0B07.8090602@alaska.gov> On 12/1/2015 11:48 AM, J.C. Cleaver wrote: - snip - > > Hmm. This seems to be fundamentally a different issue than the "hostdata > module going rogue" thing, which was about zombies never being picked up. > > AFAICT, somehow the hosts tree structure is getting clobbered as a result > of the drop (assuming all of those hosts are expected to be existing). See my later message for its relation to 'drop' activity. > There were a few patches for things in xymond.c at one point, and more > error checking when going to POSIX btrees generally, but I hadn't > encountered this in other intermittent hostlist readers. > > 1) Which version of Solaris is this? Solaris 10, most recent update, SPARC > 2) Have you experienced this in other workers for xymon? (IE, > xymond_client not being able to look up hostnames after a drop -- would > probably lead to random purples) I haven't seen behavior like that with other worker processes. Is there a way to interactively run a worker process and have it hit the daemon process for the hostnames? Aside from making the process dump core, is there a way to get the daemon to spill its current list of hostnames? > 3) Does issuing a "reload" command or -HUP to xymond_alert re-sync things? I didn't do a 'reload', but I killed the "xymond_channel --channel=page --log=/var/log/xymon/alert.log xymond_alert" process and alerts started working again. I haven't yet found a way to induce this failure, so I haven't yet identified the minimal recovery steps. I'm working on it, though. -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska From cleaver at terabithia.org Tue Dec 1 22:20:55 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 1 Dec 2015 13:20:55 -0800 Subject: [Xymon] journalctl log monitoring In-Reply-To: <565DCB98.9090003@sys4.de> References: <565DCB98.9090003@sys4.de> Message-ID: On Tue, December 1, 2015 8:32 am, Robert Schetterer wrote: > Hi, is there allready work done with xymon-client log monitor and > journalctl, means without syslog running ? > > Best Regards > MfG Robert Schetterer > At this time, there's no specific work done yet. logfetch is built around seeking back and forth over a real file, starting at the byte position we last read to, which makes it somewhat tricky to conceptualize when using journalctl, where there's nothing seekable with which to deal with. (I'll spare the systemd and "everyone uses pagers so let's just build it into the viewer!" rants here, but at least the recent versions have a --no-pager option >.<) The simplest way to integrate would be to alter the xymonclient.sh code to have journalctl dump log contents using the *cursor or --since options to a separate file, which logfetch reads and handles like a "normal" log file to scan, which we rename or symlink around as needed. This has the advantage of allowing use of all the existing client-local.cfg rules regarding triggers and ignoring. We then save the cursor and start there for next time. Logfetch could also be patched to (similar to the commands used to determine filenames now) just execute a command and read text data from its STDOUT, making naive assumptions about input start/stopping. This code doesn't exist today. Longer term, there are some additional features that could be used to have a more generic framework for executing commands, retrieving sorted or syslog-level-specific log lines from a local source, and reporting back on them to the xymon server (and/or xymond_client) for final 'analysis.cfg' processing. The syntax for controlling a) which lines to retrieve and b) which lines to send back is likely to be different enough from the standard 'log:' format that IMO we'd want to have a new section in client-local for it. Arguably, splitting the logfetch run components out from xymonclient.sh and making a xymonclient-logfetch.sh, xymonclient-journalctl.sh, (etc...) call-out would be a nice, clean way of encapsulating that logic on the different types of systems. Again, that code doesn't exist today. For the very short term, re-enabling syslog or scripting output that simulates the [msgs:/var/log/message] data in the client message by hand are your only quick options. Regards, -jc From rs at sys4.de Tue Dec 1 22:32:43 2015 From: rs at sys4.de (Robert Schetterer) Date: Tue, 1 Dec 2015 22:32:43 +0100 Subject: [Xymon] journalctl log monitoring In-Reply-To: References: <565DCB98.9090003@sys4.de> Message-ID: <565E11FB.1040906@sys4.de> Am 01.12.2015 um 22:20 schrieb J.C. Cleaver: > On Tue, December 1, 2015 8:32 am, Robert Schetterer wrote: >> Hi, is there allready work done with xymon-client log monitor and >> journalctl, means without syslog running ? >> >> Best Regards >> MfG Robert Schetterer >> > > At this time, there's no specific work done yet. > > logfetch is built around seeking back and forth over a real file, starting > at the byte position we last read to, which makes it somewhat tricky to > conceptualize when using journalctl, where there's nothing seekable with > which to deal with. > > (I'll spare the systemd and "everyone uses pagers so let's just build it > into the viewer!" rants here, but at least the recent versions have a > --no-pager option >.<) > > The simplest way to integrate would be to alter the xymonclient.sh code to > have journalctl dump log contents using the *cursor or --since options to > a separate file, which logfetch reads and handles like a "normal" log file > to scan, which we rename or symlink around as needed. This has the > advantage of allowing use of all the existing client-local.cfg rules > regarding triggers and ignoring. We then save the cursor and start there > for next time. > > Logfetch could also be patched to (similar to the commands used to > determine filenames now) just execute a command and read text data from > its STDOUT, making naive assumptions about input start/stopping. > > This code doesn't exist today. > > > Longer term, there are some additional features that could be used to have > a more generic framework for executing commands, retrieving sorted or > syslog-level-specific log lines from a local source, and reporting back on > them to the xymon server (and/or xymond_client) for final 'analysis.cfg' > processing. The syntax for controlling a) which lines to retrieve and b) > which lines to send back is likely to be different enough from the > standard 'log:' format that IMO we'd want to have a new section in > client-local for it. > > > Arguably, splitting the logfetch run components out from xymonclient.sh > and making a xymonclient-logfetch.sh, xymonclient-journalctl.sh, (etc...) > call-out would be a nice, clean way of encapsulating that logic on the > different types of systems. > > Again, that code doesn't exist today. > > For the very short term, re-enabling syslog or scripting output that > simulates the [msgs:/var/log/message] data in the client message by hand > are your only quick options. > > > Regards, > -jc > Thx for explain ! Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From ohemming at gmail.com Tue Dec 1 22:35:34 2015 From: ohemming at gmail.com (oliver) Date: Tue, 1 Dec 2015 16:35:34 -0500 Subject: [Xymon] journalctl log monitoring In-Reply-To: References: <565DCB98.9090003@sys4.de> Message-ID: On Tue, Dec 1, 2015 at 4:20 PM, J.C. Cleaver wrote: > The simplest way to integrate would be to alter the xymonclient.sh code to > have journalctl dump log contents using the *cursor or --since options to > a separate file, which logfetch reads and handles like a "normal" log file > to scan, which we rename or symlink around as needed. This has the > advantage of allowing use of all the existing client-local.cfg rules > regarding triggers and ignoring. We then save the cursor and start there > for next time. journald.conf supports the ForwardToSyslog option ============================ Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall messages to all logged-in users. ============================ From rs at sys4.de Tue Dec 1 22:39:04 2015 From: rs at sys4.de (Robert Schetterer) Date: Tue, 1 Dec 2015 22:39:04 +0100 Subject: [Xymon] journalctl log monitoring In-Reply-To: References: <565DCB98.9090003@sys4.de> Message-ID: <565E1378.8090407@sys4.de> Am 01.12.2015 um 22:35 schrieb oliver: > On Tue, Dec 1, 2015 at 4:20 PM, J.C. Cleaver wrote: >> The simplest way to integrate would be to alter the xymonclient.sh code to >> have journalctl dump log contents using the *cursor or --since options to >> a separate file, which logfetch reads and handles like a "normal" log file >> to scan, which we rename or symlink around as needed. This has the >> advantage of allowing use of all the existing client-local.cfg rules >> regarding triggers and ignoring. We then save the cursor and start there >> for next time. > > journald.conf supports the ForwardToSyslog option > > ============================ > Control whether log messages received by the journal daemon shall be > forwarded to a traditional syslog daemon, to the kernel log buffer > (kmsg), to the system console, or sent as wall messages to all > logged-in users. > ============================ This i widly known , but i think that is/will be not default in many distros so having native journalctl log monitoring will be very usefull in any case > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon > Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From john.thurston at alaska.gov Tue Dec 1 22:41:26 2015 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 01 Dec 2015 12:41:26 -0900 Subject: [Xymon] xymon hostdata module going rogue In-Reply-To: <5686d2addd15045a2254438e0ba7a9f5.squirrel@mail.kkytbs.net> References: <17082AAFC33A934082836458CB53494367323DD1@MONDB03.na.lzb.hq> <55E0C860.8020900@alaska.gov> <55E0DDA0.2070906@alaska.gov> <2a97f13340498d494247f361400f0249.squirrel@mail.kkytbs.net> <565DD56C.7060809@alaska.gov> <565DD9CA.6060604@alaska.gov> <5686d2addd15045a2254438e0ba7a9f5.squirrel@mail.kkytbs.net> Message-ID: <565E1406.7010307@alaska.gov> On 12/1/2015 11:51 AM, J.C. Cleaver wrote: > On Tue, December 1, 2015 9:32 am, John Thurston wrote: > *snip* > >> In this occurrence, it does not appear to be related to a "drop" >> message. My last recorded "drop" was at 20151103-0846 and the alert >> process didn't start logging "which is not defined" until 20151120-0007 > > Hmm. Okay, that does change things slightly. Fortunately, that means it's > probably specifically caused by drops per se. Were there any other errors > that occurred with other components around this time? I have several instances of "Oversize status msg from " in the xymond.log, but those are appearing six hours before the bad behavior appeared in xymon_alert. I have difficulty believing they are related. > Perhaps the system > being low enough on memory that some re-allocations might have failed? I think this is unlikely. The system has 256GB of RAM, and there are no memory caps placed on the non-global zone in which xymon is running. I don't have information of its size on Nov 20, but today it using about 400MB of RAM. All of the zones on the system are consuming less than 10GB of the 256GB and it wouldn't have been significantly different a few weeks ago. I've been doing some 'drops' today to try to break it, but haven't succeeded. I'll continue to beat on it and see if I can find a repeatable failure scenario. fwiw, this is under 4.3.22 -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska From cleaver at terabithia.org Tue Dec 1 22:53:48 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 1 Dec 2015 13:53:48 -0800 Subject: [Xymon] xymon hostdata module going rogue In-Reply-To: <565E1406.7010307@alaska.gov> References: <17082AAFC33A934082836458CB53494367323DD1@MONDB03.na.lzb.hq> <55E0C860.8020900@alaska.gov> <55E0DDA0.2070906@alaska.gov> <2a97f13340498d494247f361400f0249.squirrel@mail.kkytbs.net> <565DD56C.7060809@alaska.gov> <565DD9CA.6060604@alaska.gov> <5686d2addd15045a2254438e0ba7a9f5.squirrel@mail.kkytbs.net> <565E1406.7010307@alaska.gov> Message-ID: <8facfe3bf7c2ba7e12314b9d290dbde4.squirrel@mail.kkytbs.net> On Tue, December 1, 2015 1:41 pm, John Thurston wrote: > On 12/1/2015 11:51 AM, J.C. Cleaver wrote: >> On Tue, December 1, 2015 9:32 am, John Thurston wrote: >> *snip* >> >>> In this occurrence, it does not appear to be related to a "drop" >>> message. My last recorded "drop" was at 20151103-0846 and the alert >>> process didn't start logging "which is not defined" until 20151120-0007 >> >> Hmm. Okay, that does change things slightly. Fortunately, that means >> it's >> probably specifically caused by drops per se. Were there any other >> errors >> that occurred with other components around this time? > > I have several instances of "Oversize status msg from " in the > xymond.log, but those are appearing six hours before the bad behavior > appeared in xymon_alert. I have difficulty believing they are related. Ack. Yeah, that should have been 'NOT specifically' :) >> Perhaps the system >> being low enough on memory that some re-allocations might have failed? > > I think this is unlikely. The system has 256GB of RAM, and there are no > memory caps placed on the non-global zone in which xymon is running. I > don't have information of its size on Nov 20, but today it using about > 400MB of RAM. All of the zones on the system are consuming less than > 10GB of the 256GB and it wouldn't have been significantly different a > few weeks ago. > > I've been doing some 'drops' today to try to break it, but haven't > succeeded. I'll continue to beat on it and see if I can find a > repeatable failure scenario. > > fwiw, this is under 4.3.22 Hmm. This is an area where it's possible that glibc/NULL issues might be causing subtle things too. I could easily see the btree getting hosed by tree re-insertion of a key we weren't really expecting. -jc From jlaidman at rebel-it.com.au Wed Dec 2 01:17:41 2015 From: jlaidman at rebel-it.com.au (Jeremy Laidman) Date: Wed, 02 Dec 2015 00:17:41 +0000 Subject: [Xymon] Bug in TRENDS handling? In-Reply-To: <4cdbb3d9fa53160007fc35fad2a1bf27.squirrel@mail.kkytbs.net> References: <4cdbb3d9fa53160007fc35fad2a1bf27.squirrel@mail.kkytbs.net> Message-ID: On Wed, Dec 2, 2015 at 3:33 AM J.C. Cleaver wrote: > This is not particularly well tested, but can you see if this patch fixes > the issue you're seeing? It's basically just a transplant of the logic > that was being used in the 'acceptonly' patch for isolation. > It works. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sys1002 at yahoo.com Wed Dec 2 08:54:39 2015 From: sys1002 at yahoo.com (Michael Resnick) Date: Wed, 2 Dec 2015 07:54:39 +0000 (UTC) Subject: issues with new install In-Reply-To: <46385f7a86d82e8d07ea64c0a65e7dad.squirrel@mail.kkytbs.net> References: <46385f7a86d82e8d07ea64c0a65e7dad.squirrel@mail.kkytbs.net> Message-ID: <1513110656.13111975.1449042879405.JavaMail.yahoo@mail.yahoo.com> Thanks. I have done more investigating. in the hostdata folder on the xymon server shows up, all the servers show "No such host" in the Info column, so it look like the hosts are not being created in hostdata. What is the trigger that creates the data ? Weird problem. I have been using xymon for years and have never seen this, but usually I build from the tar.Thanks for any help. From: J.C. Cleaver To: Michael Resnick Cc: Xymon Mailing List Sent: Tuesday, December 1, 2015 11:00 PM Subject: Re: issues with new install On Tue, December 1, 2015 8:04 am, Michael Resnick wrote: > xymon server itself is fine. All the other servers are tests with conn > only, with just 2 havingxymon client and 6 running rclient. > none of the servers have a full set of columns except the xymon > server.rclient log shows successfully completed 6 servers and the > clientlog looks good. > I may try rolling back to 4.3.21 or earlier. The last I used at my > previous job was 4.3.11 > It is a pain to install , since I have no Internet access in this > environment. Can you edit tasks.cfg to run "xymond_client" (in the [clientdata] section) in --debug mode and see if you see data for these clients? Also, can you confirm that the non-xymonserver client (the "non-rclient" one) is working OK and you're getting status messages for? It seems like either a well-formed client message isn't making its way in in the first place, or xymond_client isn't properly processing it back into xymond. Either way, we should be able to see some evidence (or not) in the xymond_client logs as the clientlog injections occur. HTH, -jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at tdiehl.org Wed Dec 2 15:01:33 2015 From: me at tdiehl.org (me at tdiehl.org) Date: Wed, 2 Dec 2015 09:01:33 -0500 (EST) Subject: [Xymon] error installing Terabithia rpm xymon-client-4.3.24-1.el6.x86_64 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2015, J.C. Cleaver wrote: > Hi, thanks, > > It looks like CentOS pulled (or hasn't yet built) the > selinux-policy-3.13.1-60 update in from RHEL 7 yet; several others have > now reported this same problem. > > Can you try installing the 4.3.24-2 RPMs from > http://terabithia.org/rpms/xymon/testing/el7/x86_64/ ? > > I downgraded the SELinux policy package on the build system to match what > CentOS has actually pushed out. If it works, I'll push that into > production. Alternatively, you can enable the cr repo and get the updates needed to install the rpms. I just did that for one of my machines and that fixed the problem. The problem is that RHEL 7.2 is out and the Centos folks have not caught up yet. The good news is that it looks like they are making progress. HTH -- Tom me at tdiehl.org Spamtrap address me123 at tdiehl.org > > > HTH, > -jc > > > On Tue, December 1, 2015 12:46 am, andreas.kunberger at itv-denkendorf.de wrote: >> Since last update I get following error when I try to upgrade the >> Terabithia RPMs >> >> >>> sudo yum upgrade -C >> >> Loaded plugins: fastestmirror, langpacks >> >> Resolving Dependencies >> >> --> Running transaction check >> >> ---> Package xymon-client.x86_64 0:4.3.23-1.el7 will be updated >> >> ---> Package xymon-client.x86_64 0:4.3.24-1.1.el7 will be an update >> >> --> Processing Dependency: selinux-policy >= 3.13.1-60.el7 for package: >> xymon-client-4.3.24-1.1.el7.x86_64 >> >> --> Finished Dependency Resolution >> >> Error: Package: xymon-client-4.3.24-1.1.el7.x86_64 (Xymon) >> >> Requires: selinux-policy >= 3.13.1-60.el7 >> >> Installed: selinux-policy-3.13.1-23.el7_1.21.noarch (@updates) >> >> selinux-policy = 3.13.1-23.el7_1.21 >> >> Available: selinux-policy-3.13.1-23.el7.noarch (base) >> >> selinux-policy = 3.13.1-23.el7 >> >> Available: selinux-policy-3.13.1-23.el7_1.7.noarch (updates) >> >> selinux-policy = 3.13.1-23.el7_1.7 >> >> Available: selinux-policy-3.13.1-23.el7_1.8.noarch (updates) >> >> selinux-policy = 3.13.1-23.el7_1.8 >> >> Available: selinux-policy-3.13.1-23.el7_1.13.noarch (updates) >> >> selinux-policy = 3.13.1-23.el7_1.13 >> >> Available: selinux-policy-3.13.1-23.el7_1.17.noarch (updates) >> >> selinux-policy = 3.13.1-23.el7_1.17 >> >> Available: selinux-policy-3.13.1-23.el7_1.18.noarch (updates) >> >> selinux-policy = 3.13.1-23.el7_1.18 >> >> You could try using --skip-broken to work around the problem >> >> You could try running: rpm -Va --nofiles -nodigest >> >> >> >>> cat /etc/redhat-release >> >> CentOS Linux release 7.1.1503 (Core) >> >> >> What is the cause and what can I do? >> >> >> Kind regards >> >> >> i.A. Andreas Kunberger >> >> >> -- >> >> >> Deutsche Institute für Textil- und Faserforschung Denkendorf >> >> >> Andreas Kunberger >> >> Netzwerk >> >> Körschtalstraße 26, 73770 Denkendorf >> >> >> Tel.: +49 (0)7 11 93 40 - 2 58 >> >> FAX: +49 (0)7 11 93 40 - 4 15 >> >> E-Mail: andreas.kunberger at ditf.de >> >> http://www.ditf.de >> >> >> _______________________________________________ >> Xymon mailing list >> Xymon at xymon.com >> http://lists.xymon.com/mailman/listinfo/xymon >> > > > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon > From fclaire at free.fr Thu Dec 3 09:10:11 2015 From: fclaire at free.fr (Francois Claire) Date: Thu, 3 Dec 2015 09:10:11 +0100 Subject: [Xymon] Bug in findhost ? Message-ID: <565FF8E3.90005@free.fr> Hi, I have troubles using the findhost feature with the "Jump to page" box checked. On my xymon server the result URL is using localhost instead of my xymon server's FQDN. This problem seems to be reproducible on www.xymon.com: - go to https://www.xymon.com/xymon-cgi/findhost.sh - enter "ipgw" in the search field - hit the search button - you're redirected towards http://vxymon.hswn.dk/services/#ipgw.hswn.dk Host vxymon.hswn.dk doesn't exist. On my system it's redirecting to http://localhost. 2 questions: - why is the xymon server hostname changing and is there a place to configure it for findhost's answer ? - why is the answer redirecting to http when the query was done on a https URL ? I looked into findhost.c but didn't have enough time to understand how all of this works. Cheers, Francois. From matt1299 at gmail.com Thu Dec 3 18:43:15 2015 From: matt1299 at gmail.com (Matt Vander Werf) Date: Thu, 3 Dec 2015 12:43:15 -0500 Subject: [Xymon] Possible Bug in Xymon Related to Purple Statuses Message-ID: Hello, I am having an issue with Xymon where instead of tests going purple when the client stops reporting, the tests are going clear. I noticed this with a host that had all it's tests go clear instead of purple. Turns out the network interface on the machine had completely died and this had happened a week ago! We never noticed because instead of going purple the tests for the machine went clear! This seems to only be an issue with a certain group of machines. For this group of machines, we have the ping test disabled by using the 'noping' option on all of them. This is because they are all behind a firewall with private IP addresses so they are unable to be contacted by the Xymon server. But they can still send client data out to the Xymon server. Turns out, ever since we started using the 'noping' option for all of them, none of the machines have ever gone purple... I tested this by stopping the xymon-client service on one of the machines in question, and sure enough, after the STATUSLIFETIME time limit, all the tests for that host went clear, instead of going purple. I looked through the different logs (I already had most set in debug mode for a different reason), and I didn't see much that would explain this (but I could have missed something). I did notice in the xymond log file that, according to xymond, they should have been going purple and not clear. Here's an excerpt from that log file (this is the machine which I stopped the service on): 9680 2015-12-02 09:57:48.040111 -> check_purple_status 9680 2015-12-02 09:57:48.047630 Purple log from memory 9680 2015-12-02 09:57:48.047674 ->handle_status 9680 2015-12-02 09:57:48.047676 modifyonly = 0, changed = 0 9680 2015-12-02 09:57:48.047680 - sum: 0, synced: 0, oldcolor: 0, newcolor: 1, modifychanged: 0 9680 2015-12-02 09:57:48.047682 posting to stachg channel: host=, test=memory 9680 2015-12-02 09:57:48.047684 -> posttochannel 9680 2015-12-02 09:57:48.047697 Posting message 14359 to 1 readers 9680 2015-12-02 09:57:48.047703 <- posttochannel 9680 2015-12-02 09:57:48.047705 posting to status channel 9680 2015-12-02 09:57:48.047706 -> posttochannel 9680 2015-12-02 09:57:48.047712 Posting message 72429 to 2 readers 9680 2015-12-02 09:57:48.047726 <- posttochannel 9680 2015-12-02 09:57:48.047727 <-handle_status Basically this showed up for all the different tests for this machine. And here's the event log for the same machine: Wed Dec 2 09:57:48 2015 cpu [image: green] [image: From -> To] [image: clear] Wed Dec 2 09:57:48 2015 disk [image: green] [image: From -> To] [image: clear] Wed Dec 2 09:57:48 2015 inode [image: green] [image: From -> To] [image: clear] Wed Dec 2 09:57:48 2015 memory [image: green] [image: From -> To] [image: clear] Any thoughts as to what's going on? Looks like a bug to me... Thanks!! -- Matt Vander Werf -------------- next part -------------- An HTML attachment was scrubbed... URL: From cleaver at terabithia.org Thu Dec 3 18:49:59 2015 From: cleaver at terabithia.org (Japheth Cleaver) Date: Thu, 3 Dec 2015 09:49:59 -0800 Subject: [Xymon] Possible Bug in Xymon Related to Purple Statuses In-Reply-To: References: Message-ID: <566080C7.9010001@terabithia.org> On 12/3/2015 9:43 AM, Matt Vander Werf wrote: > Hello, > > I am having an issue with Xymon where instead of tests going purple > when the client stops reporting, the tests are going clear. > > I noticed this with a host that had all it's tests go clear instead of > purple. Turns out the network interface on the machine had completely > died and this had happened a week ago! We never noticed because > instead of going purple the tests for the machine went clear! > > This seems to only be an issue with a certain group of machines. For > this group of machines, we have the ping test disabled by using the > 'noping' option on all of them. This is because they are all behind a > firewall with private IP addresses so they are unable to be contacted > by the Xymon server. But they can still send client data out to the > Xymon server. > > Turns out, ever since we started using the 'noping' option for all of > them, none of the machines have ever gone purple... > > I tested this by stopping the xymon-client service on one of the > machines in question, and sure enough, after the STATUSLIFETIME time > limit, all the tests for that host went clear, instead of going purple. > > > I looked through the different logs (I already had most set in debug > mode for a different reason), and I didn't see much that would explain > this (but I could have missed something). > > I did notice in the xymond log file that, according to xymond, they > should have been going purple and not clear. > > Here's an excerpt from that log file (this is the machine which I > stopped the service on): > > 9680 2015-12-02 09:57:48.040111 -> check_purple_status > 9680 2015-12-02 09:57:48.047630 Purple log from memory > 9680 2015-12-02 09:57:48.047674 ->handle_status > 9680 2015-12-02 09:57:48.047676 modifyonly = 0, changed = 0 > 9680 2015-12-02 09:57:48.047680 - sum: 0, synced: 0, oldcolor: 0, > newcolor: 1, modifychanged: 0 > 9680 2015-12-02 09:57:48.047682 posting to stachg channel: > host=, test=memory > 9680 2015-12-02 09:57:48.047684 -> posttochannel > 9680 2015-12-02 09:57:48.047697 Posting message 14359 to 1 readers > 9680 2015-12-02 09:57:48.047703 <- posttochannel > 9680 2015-12-02 09:57:48.047705 posting to status channel > 9680 2015-12-02 09:57:48.047706 -> posttochannel > 9680 2015-12-02 09:57:48.047712 Posting message 72429 to 2 readers > 9680 2015-12-02 09:57:48.047726 <- posttochannel > 9680 2015-12-02 09:57:48.047727 <-handle_status > > Basically this showed up for all the different tests for this machine. > > And here's the event log for the same machine: > > Wed Dec 2 09:57:48 2015 cpu green From -> To > clear > Wed Dec 2 09:57:48 2015 disk green From -> To > clear > Wed Dec 2 09:57:48 2015 inode green From -> To > clear > Wed Dec 2 09:57:48 2015 memory green From -> To clear > > > Any thoughts as to what's going on? Looks like a bug to me... > > Thanks!! > This is intentional. It's a result of the normal 'purple' behavior when a box is actually down, but it'll give you this behavior if you're testing a box that's "normally" conn-down (as far as xymon knows) anyway. You'll want to add the 'noclear' line as well to any of the systems that are not pingable if you want the client tests to actually go purple. https://www.xymon.com/help/manpages/man5/hosts.cfg.5.html#lbAG/ / /noclear/ /Controls whether stale status messages go purple or clear when a host is down. Normally, when a host is down the client statuses ("cpu", "disk", "memory" etc) will stop updating - this would usually make them go "purple" which can trigger alerts. To avoid that, Xymon checks if the "conn" test has failed, and if that is true then the other tests will go "clear" instead of purple so you only get alerts for the "conn" test. If you do want the stale statuses to go purple, you can use the "noclear" tag to override this behaviour./ Regards, -jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt1299 at gmail.com Thu Dec 3 18:59:03 2015 From: matt1299 at gmail.com (Matt Vander Werf) Date: Thu, 3 Dec 2015 12:59:03 -0500 Subject: [Xymon] Possible Bug in Xymon Related to Purple Statuses In-Reply-To: <566080C7.9010001@terabithia.org> References: <566080C7.9010001@terabithia.org> Message-ID: Ah, okay. That makes sense! I guess I was thinking that this only happened with other network tests and not the normal tests as well, but that appears to be a different setting. I must have misread or missed the noclear option when I was looking through the documentation.... I think maybe this should be documented better...something like if you use noping then you should also use noclear if you want purple statuses. But that's just my thinking... Thanks as always, J.C.!! -- Matt Vander Werf On Thu, Dec 3, 2015 at 12:49 PM, Japheth Cleaver wrote: > On 12/3/2015 9:43 AM, Matt Vander Werf wrote: > > Hello, > > I am having an issue with Xymon where instead of tests going purple when > the client stops reporting, the tests are going clear. > > I noticed this with a host that had all it's tests go clear instead of > purple. Turns out the network interface on the machine had completely died > and this had happened a week ago! We never noticed because instead of going > purple the tests for the machine went clear! > > This seems to only be an issue with a certain group of machines. For this > group of machines, we have the ping test disabled by using the 'noping' > option on all of them. This is because they are all behind a firewall with > private IP addresses so they are unable to be contacted by the Xymon > server. But they can still send client data out to the Xymon server. > > Turns out, ever since we started using the 'noping' option for all of > them, none of the machines have ever gone purple... > > I tested this by stopping the xymon-client service on one of the machines > in question, and sure enough, after the STATUSLIFETIME time limit, all the > tests for that host went clear, instead of going purple. > > > I looked through the different logs (I already had most set in debug mode > for a different reason), and I didn't see much that would explain this (but > I could have missed something). > > I did notice in the xymond log file that, according to xymond, they should > have been going purple and not clear. > > Here's an excerpt from that log file (this is the machine which I stopped > the service on): > > 9680 2015-12-02 09:57:48.040111 -> check_purple_status > 9680 2015-12-02 09:57:48.047630 Purple log from memory > 9680 2015-12-02 09:57:48.047674 ->handle_status > 9680 2015-12-02 09:57:48.047676 modifyonly = 0, changed = 0 > 9680 2015-12-02 09:57:48.047680 - sum: 0, synced: 0, oldcolor: 0, > newcolor: 1, modifychanged: 0 > 9680 2015-12-02 09:57:48.047682 posting to stachg channel: host=, > test=memory > 9680 2015-12-02 09:57:48.047684 -> posttochannel > 9680 2015-12-02 09:57:48.047697 Posting message 14359 to 1 readers > 9680 2015-12-02 09:57:48.047703 <- posttochannel > 9680 2015-12-02 09:57:48.047705 posting to status channel > 9680 2015-12-02 09:57:48.047706 -> posttochannel > 9680 2015-12-02 09:57:48.047712 Posting message 72429 to 2 readers > 9680 2015-12-02 09:57:48.047726 <- posttochannel > 9680 2015-12-02 09:57:48.047727 <-handle_status > > Basically this showed up for all the different tests for this machine. > > And here's the event log for the same machine: > > Wed Dec 2 09:57:48 2015 cpu [image: green] [image: From -> To] > [image: > clear] > Wed Dec 2 09:57:48 2015 disk [image: green] [image: From -> To] > [image: > clear] > Wed Dec 2 09:57:48 2015 inode [image: green] [image: From -> To] > [image: > clear] > Wed Dec 2 09:57:48 2015 memory [image: green] [image: From -> To] [image: > clear] > > > Any thoughts as to what's going on? Looks like a bug to me... > > Thanks!! > > > This is intentional. It's a result of the normal 'purple' behavior when a > box is actually down, but it'll give you this behavior if you're testing a > box that's "normally" conn-down (as far as xymon knows) anyway. > > You'll want to add the 'noclear' line as well to any of the systems that > are not pingable if you want the client tests to actually go purple. > > https://www.xymon.com/help/manpages/man5/hosts.cfg.5.html#lbAG > > *noclear* > *Controls whether stale status messages go purple or clear when a host is > down. Normally, when a host is down the client statuses ("cpu", "disk", > "memory" etc) will stop updating - this would usually make them go "purple" > which can trigger alerts. To avoid that, Xymon checks if the "conn" test > has failed, and if that is true then the other tests will go "clear" > instead of purple so you only get alerts for the "conn" test. If you do > want the stale statuses to go purple, you can use the "noclear" tag to > override this behaviour.* > > > Regards, > -jc > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wlrutherford at alaska.edu Thu Dec 3 20:04:46 2015 From: wlrutherford at alaska.edu (Walter Rutherford) Date: Thu, 3 Dec 2015 10:04:46 -0900 Subject: [Xymon] double proc test results Message-ID: I just noticed that several of my systems are reporting the same PROC multiple times. I've checked the analysis.d/libit.cfg file and the processes are defined only once for the machines as far as I can see - I even removed a wildcard host I thought might've been matching too much. Thu Dec 3 09:56:02 AKST 2015 - Processes ok [image: green] mysqld (found 2, req. 2 or more)[image: green] shibd (found 1, req. 1 or more)[image: green] salt-master (found 11, req. 1 or more)[image: green] munin-node (found 1, req. between 1 and 3)[image: green] shibd (found 1, req. 1 or more)[image: green] salt-master (found 11, req. 1 or more)[image: green] munin-node (found 1, req. between 1 and 3) It's not wrong, I still get the correct results on the main page, but it's distracting. Has anyone else seen this and what is/was your cure? WLR -------------- next part -------------- An HTML attachment was scrubbed... URL: From cleaver at terabithia.org Thu Dec 3 20:40:24 2015 From: cleaver at terabithia.org (Japheth Cleaver) Date: Thu, 3 Dec 2015 11:40:24 -0800 Subject: [Xymon] Possible Bug in Xymon Related to Purple Statuses In-Reply-To: References: <566080C7.9010001@terabithia.org> Message-ID: <56609AA8.4060706@terabithia.org> On 12/3/2015 9:59 AM, Matt Vander Werf wrote: > Ah, okay. That makes sense! I guess I was thinking that this only > happened with other network tests and not the normal tests as well, > but that appears to be a different setting. I must have misread or > missed the noclear option when I was looking through the documentation.... > > I think maybe this should be documented better...something like if you > use noping then you should also use noclear if you want purple > statuses. But that's just my thinking... Agreed. This should probably be documented a little better. IIRC it's automatic for the old dialup-type configs. Longer term, there was a TODO item for making conn/disable clear/dependency checking something that can happen centrally at the xymond level across the board. Right now, the effects of a server being 'conn' down are distributed among both xymonnet (dependency checking to suppress related 'red' TCP checks into 'clear') and xymond (stale xymond_client-derived (or other) tests going 'clear' instead of purple). It'd seem to make sense to make a 'conn' loss (as well as a 'disable .*') a core host flag with central effects. -jc From cleaver at terabithia.org Thu Dec 3 20:42:27 2015 From: cleaver at terabithia.org (Japheth Cleaver) Date: Thu, 3 Dec 2015 11:42:27 -0800 Subject: [Xymon] double proc test results In-Reply-To: References: Message-ID: <56609B23.9070505@terabithia.org> On 12/3/2015 11:04 AM, Walter Rutherford wrote: > I just noticed that several of my systems are reporting the same PROC > multiple times. > I've checked the analysis.d/libit.cfg file and the processes are > defined only once for the > machines as far as I can see - I even removed a wildcard host I > thought might've been > matching too much. > > > Thu Dec 3 09:56:02 AKST 2015 - Processes ok > > green mysqld (found 2, req. 2 or more) > green shibd (found 1, req. 1 or more) > green salt-master (found 11, req. 1 or more) > green munin-node (found 1, req. between 1 and 3) > green shibd (found 1, req. 1 or more) > green salt-master (found 11, req. 1 or more) > green munin-node (found 1, req. between 1 and 3) > > It's not wrong, I still get the correct results on the main page, but > it's distracting. > Has anyone else seen this and what is/was your cure? WLR That's odd. I do recall seeing something like that once, but it was quite a while ago and I don't remember the specific cause. When you do a xymond_client --dump-config do you see anything unusual relating to the rules for those checks? If not, can you place xymond_client into debug mode for a submission cycle so we can see what it's doing? HTH, -jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt1299 at gmail.com Fri Dec 4 12:49:48 2015 From: matt1299 at gmail.com (Matt Vander Werf) Date: Fri, 4 Dec 2015 06:49:48 -0500 Subject: [Xymon] "Discarding timed-out partial msg" Error Messages In-Reply-To: <4fdc5d799ad519c5461ed39385fd6580.squirrel@mail.kkytbs.net> References: <4fdc5d799ad519c5461ed39385fd6580.squirrel@mail.kkytbs.net> Message-ID: Hi J.C., Thanks for the e-mail and advice! A couple of questions: What's the default --lqueue value that Xymon uses? (Is there a way to see what it's using?) What exactly is your definition of "tons of simultaneous connections" here? Can you give me a number or range that you think would warrant increasing the --lqueue value? Could it be from clients/senders with longer than usual process listings? Or other clientlog statistics? (But still under the max client message value.) How would I be able to tell if there are long messages being sent in if the long messages are being discarded? The clients/senders are all different and there doesn't seem to be a pattern that I can see. Some hosts are showing up more then once though. All the connections to these machines SHOULD be coming in at the same connection speed.... I'm not seeing any network issues over any of our switches. And I'm not seeing any significant or unusual network traffic on the machines in question around the time of the time-out error messages (although it could be a very brief spike in traffic that isn't being seen since the status message is being discarded). I'll definitely look into the possibility of doing some TCP tuning on the Xymon server machine! Thanks again! -- Matt Vander Werf On Tue, Nov 24, 2015 at 3:17 PM, J.C. Cleaver wrote: > > > On Tue, November 24, 2015 6:29 am, Matt Vander Werf wrote: > > Hey all, > > > > Lately, I've been seeing quite a few error messages show up in xymond > > indicating that it was discarding a timed-out partial message from some > > machine. > > > > i.e. > > > > Latest error messages: > > Discarding timed-out partial msg from X.X.X.X > > > > They seem to be happening sporadically but more often than usual as of > > late. Maybe one or two every couple of days or so. They don't seem to be > > coming from the same machine/machines either. > > > > Is this something I should be worried about? Are there any side-effects > > from this happening too much? > > > > What are the causes of this happening? Any way to make it not happen as > > much? > > > > > > Any ideas or advice is greatly appreciated! > > > > Thanks!! > > > Broadly speaking, this is a result of the entire message not making it in > in the time allotted by xymond, which is 10s by default. It could be the > result of network congestion issues or packet loss, slow sender > performance, or slow xymon server performance. > > A quick fix might be to increase the --timeout= option to xymond to > something like 15 or 20s. > > If a netstat shows tons of simultaneous connections, you could also > increase --lqueue= to 768 or 1024. > > Are there any patterns on the clients/senders that are affected? Unusually > huge messages being sent over slow connections? > > If there isn't a network issue per se, and there are no local network > errors (or you're seeing the reports about messages from all over the > place), then it's time to look at network performance tuning on the xymon > box. Consider the various tcp* options via sysctl (recycle and reuse in > particular). If xymonnet is running on the same system (and you're doing) > high concurrency testing, be sure to increase your ip_local_port_range for > outbound connections. > > http://www.lognormal.com/blog/2012/09/27/linux-tcpip-tuning/ is a nice > resource for that. > > > HTH, > > -jc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pretorius.riaan at gmail.com Fri Dec 4 16:17:36 2015 From: pretorius.riaan at gmail.com (Riaan Pretorius [GMAIL]) Date: Fri, 4 Dec 2015 17:17:36 +0200 Subject: [Xymon] Idea about GUI Message-ID: Good Day, I have a suggestion for a XYMON UI update. Please let me know what you think of the idea? Riaan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2015-12-04 17.15.17.png Type: image/png Size: 124838 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2015-12-04 13.35.12.png Type: image/png Size: 79142 bytes Desc: not available URL: From josh at imaginenetworksllc.com Fri Dec 4 16:36:47 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 4 Dec 2015 10:36:47 -0500 Subject: [Xymon] Idea about GUI In-Reply-To: References: Message-ID: Looks great. I like the better gradient background. I use HTTP auth, though. I don't think the login page would interact the same. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Dec 4, 2015 at 10:17 AM, Riaan Pretorius [GMAIL] < pretorius.riaan at gmail.com> wrote: > Good Day, > > I have a suggestion for a XYMON UI update. Please let me know what you > think of the idea? > > > > > > > > Riaan > > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2015-12-04 13.35.12.png Type: image/png Size: 79142 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2015-12-04 17.15.17.png Type: image/png Size: 124838 bytes Desc: not available URL: From traxler at lsu.edu Fri Dec 4 17:00:30 2015 From: traxler at lsu.edu (Isaac W Traxler) Date: Fri, 4 Dec 2015 10:00:30 -0600 (CST) Subject: [Xymon] Idea about GUI In-Reply-To: References: Message-ID: Here is something I was toying arouond with a while back. All the changes (except a few) are done as tweaks to the the static html. - Two changes to config files (xymonmenu.cfg and xymonserver.cfg) were needed. - libcolor.h needed a change. - xymongen-pagegen.c needed changes to support each cell of the table having its own background color. The worst color of the page became a frame around the page instead of the background of the page. Comments? The patchfile for pagegen is 51 lines (to give an idea of tweaks): - add table to store class names char td_style_table[COL_COUNT+1][7] = {"green", "clear", "blue", "purple", "yellow", "red", "miss"}; - change fprintf(output, ""); to this fprintf(output, "", td_style_table[e->color]); If there is interest I will update the patch files for latest version and pass on what I have so far. I had not quite got the framing perfect on some of the pages (last bug I think). -- Isaac Traxler Storage & Infrastructure Manager High Performance Computing Louisiana State University, LONI 325 Frey Computing Center, Baton Rouge, LA 70803 225-578-1923 | traxler at lsu.edu On Fri, 4 Dec 2015, Riaan Pretorius [GMAIL] wrote: > Date: Fri, 4 Dec 2015 09:17:36 > From: "Riaan Pretorius [GMAIL]" > To: xymon at xymon.com > Subject: [Xymon] Idea about GUI > > ?Good Day, > > I have a suggestion for a XYMON UI update. Please let me know what you think of the idea? > > > [IMAGE] > > > [IMAGE] > ? > Riaan > > -------------- next part -------------- A non-text attachment was scrubbed... Name: xymon.png Type: image/png Size: 86214 bytes Desc: URL: From josh at imaginenetworksllc.com Fri Dec 4 17:40:13 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 4 Dec 2015 11:40:13 -0500 Subject: [Xymon] Idea about GUI In-Reply-To: References: Message-ID: Like the table. Really hate the white bg :( Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Dec 4, 2015 11:20 AM, "Isaac W Traxler" wrote: > > Here is something I was toying arouond with a while back. > > All the changes (except a few) are done as tweaks to the the static html. > - Two changes to config files (xymonmenu.cfg and xymonserver.cfg) were > needed. > - libcolor.h needed a change. > - xymongen-pagegen.c needed changes to support each cell of the table > having its own background color. The worst color of the page became a frame > around the page instead of the background of the page. > > Comments? > > The patchfile for pagegen is 51 lines (to give an idea of tweaks): > - add table to store class names > char td_style_table[COL_COUNT+1][7] = {"green", "clear", "blue", "purple", > "yellow", "red", "miss"}; > > - change > fprintf(output, ""); > to this > fprintf(output, "", td_style_table[e->color]); > > If there is interest I will update the patch files for latest version and > pass on what I have so far. I had not quite got the framing perfect on some > of the pages (last bug I think). > > -- > Isaac Traxler > Storage & Infrastructure Manager > High Performance Computing > Louisiana State University, LONI > 325 Frey Computing Center, Baton Rouge, LA 70803 > 225-578-1923 | traxler at lsu.edu > > On Fri, 4 Dec 2015, Riaan Pretorius [GMAIL] wrote: > > Date: Fri, 4 Dec 2015 09:17:36 >> From: "Riaan Pretorius [GMAIL]" >> To: xymon at xymon.com >> Subject: [Xymon] Idea about GUI >> >> ?Good Day, >> >> I have a suggestion for a XYMON UI update. Please let me know what you >> think of the idea? >> >> >> [IMAGE] >> >> >> [IMAGE] >> ? >> Riaan >> >> > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tgm at fastmail.com Sat Dec 5 09:31:53 2015 From: tgm at fastmail.com (tgm) Date: Sat, 5 Dec 2015 03:31:53 -0500 Subject: [Xymon] Xymon 4.3.22-beta Release Download Message-ID: <5662A0F9.6020404@fastmail.com> Now that Xymon 4.3.24 is out, I'm still seeing the same compile warning previously noted in this thread: xymonping.c: In function ‘show_results’: xymonping.c:363:5: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] printf(" (%u usec)\n", rtt_usecs); I'm not sure what the impact is. Thanks, Tim From dewelker at gmail.com Mon Dec 7 18:13:31 2015 From: dewelker at gmail.com (David Welker) Date: Mon, 7 Dec 2015 12:13:31 -0500 Subject: [Xymon] Layout Message-ID: I'm already familiar with "group"-ing things in almost every way possible (sorted, compressed, etc.), but was wondering if there is a way to indent or put different icons in the front of entries in the same group? For example: col1 col2 col3 col4 col5 col6 ------ ------ ------ ------ ------ ------ host 1 3 3 3 switch 1 1 1 1 switch 2 2 2 2 host 2 4 4 4 switch 1 1 1 1 switch 2 2 2 2 I was hoping changing fonts would work, but adding different header types, for example, simply made Xymon see that as part of the hostname for each entry, even when adding non-breaking spaces in front of an entry in hosts.cfg, Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From Galen.Johnson at sas.com Mon Dec 7 19:48:36 2015 From: Galen.Johnson at sas.com (Galen Johnson) Date: Mon, 7 Dec 2015 18:48:36 +0000 Subject: [Xymon] Xymon + graphite Message-ID: <1449514076552.92382@sas.com> Hey, Has anyone tried to integrate alerting based on Graphite? Or used Graphite as a trending replacement to rrd? I love Xymon for my monitoring but the limitations and aggregations of rrds are starting to become an issue. thanks =G= NB: I was sent this link today, http://blog.takipi.com/graphite-vs-grafana-build-the-best-monitoring-architecture-for-your-application/, and on the Graphite page there is this link under monitoring that I thought I might consider modifying for Xymon: https://github.com/blacked/graphite-to-zabbix. =G= -------------- next part -------------- An HTML attachment was scrubbed... URL: From cleaver at terabithia.org Tue Dec 8 16:19:50 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 8 Dec 2015 07:19:50 -0800 Subject: [Xymon] Layout In-Reply-To: References: Message-ID: <9a628d7736a3a492c0cb4e3cef5d1de4.squirrel@mail.kkytbs.net> On Mon, December 7, 2015 9:13 am, David Welker wrote: > I'm already familiar with "group"-ing things in almost every way possible > (sorted, compressed, etc.), but was wondering if there is a way to indent > or put different icons in the front of entries in the same group? > > For example: > > col1 col2 col3 col4 col5 col6 > ------ ------ ------ ------ ------ ------ > host 1 3 3 3 > switch 1 1 1 1 > switch 2 2 2 2 > host 2 4 4 4 > switch 1 1 1 1 > switch 2 2 2 2 > > I was hoping changing fonts would work, but adding different header types, > for example, simply made Xymon see that as part of the hostname for each > entry, even when adding non-breaking spaces in front of an entry in > hosts.cfg, David, At the moment, there's no easy way to do this. There might be a short term solution in the form of an arbitrary HTML prepend that could be configured in hosts.cfg (DISPLAYPREFIX:"html here" ?) but it'd be something of a hack. Do you think that would work for you? Longer term, the goal would be to make things like this CSS-controlled, and either reflective of a list relationship between "host 1" and "switch 1/2" in your example, or making all switches a 'type' that can then be CSS controlled. The stripping out of display HTML is on the radar for 4.4, but there's still additional work needing to be done. Regards, -jc From cleaver at terabithia.org Tue Dec 8 16:31:59 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 8 Dec 2015 07:31:59 -0800 Subject: [Xymon] Xymon 4.3.22-beta Release Download In-Reply-To: <5662A0F9.6020404@fastmail.com> References: <5662A0F9.6020404@fastmail.com> Message-ID: <69fd5dc652fcf73a350c0189c50bc052.squirrel@mail.kkytbs.net> On Sat, December 5, 2015 12:31 am, tgm wrote: > Now that Xymon 4.3.24 is out, I'm still seeing the same compile warning > previously noted in this thread: > > xymonping.c: In function âshow_resultsâ: > xymonping.c:363:5: warning: format â%uâ expects argument of type > âunsigned intâ, but argument 2 has type âlong unsigned intâ > [-Wformat=] > printf(" (%u usec)\n", rtt_usecs); > > I'm not sure what the impact is. Thanks. There shouldn't be any real impact for you. Now that fping is stable and being maintained again, xymonping is edging more towards quasi-deprecation unless there's a reason it's needed on specific platforms. This should still be fixed, though. Thanks for pointing it out. Regards, -jc From cleaver at terabithia.org Tue Dec 8 16:50:06 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 8 Dec 2015 07:50:06 -0800 Subject: [Xymon] "Discarding timed-out partial msg" Error Messages In-Reply-To: References: <4fdc5d799ad519c5461ed39385fd6580.squirrel@mail.kkytbs.net> Message-ID: <5a54f6bd3d641f1b09f44b7807bdfa6b.squirrel@mail.kkytbs.net> Hi Matt, Sorry for the delay. Had some unexpected time away from the keyboard this weekend. Responses inline. On Fri, December 4, 2015 3:49 am, Matt Vander Werf wrote: > Hi J.C., > > Thanks for the e-mail and advice! > > A couple of questions: > > What's the default --lqueue value that Xymon uses? (Is there a way to see > what it's using?) > > What exactly is your definition of "tons of simultaneous connections" > here? > Can you give me a number or range that you think would warrant increasing > the --lqueue value? The default is 512, which is compiled in. This really won't need to be increased unless xymond is being bogged down with lots of *literally* simultaneous waiting connections. It can be increased, but there's probably another sort of problem happening: either slow connectivity, high CPU load, or "backpressure" from too many channel workers causing xymond itself to be unable to keep up. I'm trying to think back and I don't think I had cause to increase it until SN was regularly hitting the 2500 msgs/s range, and it was lowered back down once other performance bottlenecks and some packet loss were identified. Try stracing xymond and seeing what it's doing. If there's a lot of waiting happening for network reading, that might be a sign that lqueue increasing could help. 768 or 1024 should be more than sufficient. Anything more than that except at bursts means there's some other backlog. > > Could it be from clients/senders with longer than usual process listings? > Or other clientlog statistics? (But still under the max client message > value.) It's possible, but unless you're bandwidth restricted somewhere senders should generally still be able to complete in the default time frame. If you *are* bandwith restricted then that's definitely something to consider, especially if the machines you're having problems with have a lot of burst network activity. (Speaking of burst network activity, try commenting out the 'netstat' output in the client if you don't have any port checks against the host.) > > How would I be able to tell if there are long messages being sent in if > the > long messages are being discarded? Yeah, this should probably be added in. Truncated messages have their first line displayed, but it's not so much a 'discard' here as it is a network timeout first and foremost. An strace with the -s 4096 (or some high number) might be able to catch the first bit of a read from the client if you're lucky there... HTH, -jc From dewelker at gmail.com Tue Dec 8 17:01:45 2015 From: dewelker at gmail.com (David Welker) Date: Tue, 8 Dec 2015 11:01:45 -0500 Subject: [Xymon] Layout In-Reply-To: <9a628d7736a3a492c0cb4e3cef5d1de4.squirrel@mail.kkytbs.net> References: <9a628d7736a3a492c0cb4e3cef5d1de4.squirrel@mail.kkytbs.net> Message-ID: JC, Naturally, CSS-controlled would be the best solution, but your proposed "hack" would work on older versions of Xymon (I'm still on v4.3.21)? I'm thinking if there was just a way to ignore html tags when determining the hostname from hosts.cfg, this hack of yours could work! Thanks, David On Tue, Dec 8, 2015 at 10:19 AM, J.C. Cleaver wrote: > > > On Mon, December 7, 2015 9:13 am, David Welker wrote: > > I'm already familiar with "group"-ing things in almost every way possible > > (sorted, compressed, etc.), but was wondering if there is a way to indent > > or put different icons in the front of entries in the same group? > > > > For example: > > > > col1 col2 col3 col4 col5 col6 > > ------ ------ ------ ------ ------ ------ > > host 1 3 3 3 > > switch 1 1 1 1 > > switch 2 2 2 2 > > host 2 4 4 4 > > switch 1 1 1 1 > > switch 2 2 2 2 > > > > I was hoping changing fonts would work, but adding different header > types, > > for example, simply made Xymon see that as part of the hostname for each > > entry, even when adding non-breaking spaces in front of an entry in > > hosts.cfg, > > > David, > > At the moment, there's no easy way to do this. There might be a short term > solution in the form of an arbitrary HTML prepend that could be configured > in hosts.cfg (DISPLAYPREFIX:"html here" ?) but it'd be something of a > hack. Do you think that would work for you? > > Longer term, the goal would be to make things like this CSS-controlled, > and either reflective of a list relationship between "host 1" and "switch > 1/2" in your example, or making all switches a 'type' that can then be CSS > controlled. The stripping out of display HTML is on the radar for 4.4, but > there's still additional work needing to be done. > > Regards, > -jc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cleaver at terabithia.org Tue Dec 8 17:57:15 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 8 Dec 2015 08:57:15 -0800 Subject: [Xymon] Layout In-Reply-To: References: <9a628d7736a3a492c0cb4e3cef5d1de4.squirrel@mail.kkytbs.net> Message-ID: <57922178f61bd960e37a5eef759090f5.squirrel@mail.kkytbs.net> On Tue, December 8, 2015 8:01 am, David Welker wrote: > JC, > > Naturally, CSS-controlled would be the best solution, but your proposed > "hack" would work on older versions of Xymon (I'm still on v4.3.21)? I'm > thinking if there was just a way to ignore html tags when determining the > hostname from hosts.cfg, this hack of yours could work! Well, there's probably a fair amount of stuff out there that reads the hosts.cfg file in expecting `grep ^[0-9] | awk '{print $2}'` (or something similar) to represent spaceless hostnames only. However, I think a separate config tag (pre-only? separate pre/post? use format or '&H' string to wrap what xymongen already displays?) should be fairly do-able. And yep, it could be done in the 4.3 branch as a patch. I'll see if this is something I can get a working version of for inclusion. Regards, -jc > On Tue, Dec 8, 2015 at 10:19 AM, J.C. Cleaver > wrote: > >> >> >> On Mon, December 7, 2015 9:13 am, David Welker wrote: >> > I'm already familiar with "group"-ing things in almost every way >> possible >> > (sorted, compressed, etc.), but was wondering if there is a way to >> indent >> > or put different icons in the front of entries in the same group? >> > >> > For example: >> > >> > col1 col2 col3 col4 col5 col6 >> > ------ ------ ------ ------ ------ ------ >> > host 1 3 3 3 >> > switch 1 1 1 1 >> > switch 2 2 2 2 >> > host 2 4 4 4 >> > switch 1 1 1 1 >> > switch 2 2 2 2 >> > >> > I was hoping changing fonts would work, but adding different header >> types, >> > for example, simply made Xymon see that as part of the hostname for >> each >> > entry, even when adding non-breaking spaces in front of an entry in >> > hosts.cfg, >> >> >> David, >> >> At the moment, there's no easy way to do this. There might be a short >> term >> solution in the form of an arbitrary HTML prepend that could be >> configured >> in hosts.cfg (DISPLAYPREFIX:"html here" ?) but it'd be something of a >> hack. Do you think that would work for you? >> >> Longer term, the goal would be to make things like this CSS-controlled, >> and either reflective of a list relationship between "host 1" and >> "switch >> 1/2" in your example, or making all switches a 'type' that can then be >> CSS >> controlled. The stripping out of display HTML is on the radar for 4.4, >> but >> there's still additional work needing to be done. >> >> Regards, >> -jc >> >> >> >> > From Foster.Patch at accuweather.com Tue Dec 8 20:43:29 2015 From: Foster.Patch at accuweather.com (Foster Patch) Date: Tue, 8 Dec 2015 19:43:29 +0000 Subject: [Xymon] Alarm Output to Text File? Message-ID: Hi, Pretty random question here- I have had the severe frustration of working with CPU monitoring on Windows 2000. I was wondering if it is possible to write a text file if an alarm like CPU goes red. I would have a persistent script running in the background that would check to see if that file exists, and commit and action based on its existence. I am still very new to Xymon and was just wondering if this was possible. Thank you, Foster Patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Wedaa at marist.edu Tue Dec 8 20:45:03 2015 From: Eric.Wedaa at marist.edu (Eric Wedaa) Date: Tue, 8 Dec 2015 14:45:03 -0500 Subject: [Xymon] Alerts.cfg doesn't wait before sending alert, help? Message-ID: My Google-fu failed me, maybe somebody can point me in the right direction. I have an alerts.cfg file with the following contents: page=webservers2 mail eric.wedaa at marist.edu COLOR=red duration>5m repeat=4h mail eric.wedaa at marist.edu COLOR=!red recovered What is happening is it sends a yellow alert right away when the webserver goes down, and 15 minutes later sends a red alert. I THOUGHT that this would not send a yellow alert, and then send a RED alert after 5 minutes. What am I doing wrong please? >>>Ericw From Paul.Root at CenturyLink.com Tue Dec 8 21:39:31 2015 From: Paul.Root at CenturyLink.com (Root, Paul T) Date: Tue, 8 Dec 2015 20:39:31 +0000 Subject: [Xymon] layout of terabithia xymon client Message-ID: I've recently inherited supporting a xymon network where the old admin use the terabithia rpms. I've spent most of the day looking for a particular test for a particular client. I finally found the script in /usr/share/xymon-client/sections directory. I can't find where that gets called from? Is this a normal terabithia layout? Where does it get invoked? Thanks, Paul. Paul Root Lead Engineer CenturyLink Network Reliability Operations Center 390 Commerce Dr Woodbury, MN 55125 Direct: (651)312-5207 Paul.Root at centurylink.com This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cleaver at terabithia.org Tue Dec 8 22:11:16 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 8 Dec 2015 13:11:16 -0800 Subject: [Xymon] Alarm Output to Text File? In-Reply-To: References: Message-ID: <592724fb5771bd58124ac0665fe5fc68.squirrel@mail.kkytbs.net> On Tue, December 8, 2015 11:43 am, Foster Patch wrote: > Hi, > > Pretty random question here- I have had the severe frustration of working > with CPU monitoring on Windows 2000. I was wondering if it is possible to > write a text file if an alarm like CPU goes red. I would have a persistent > script running in the background that would check to see if that file > exists, and commit and action based on its existence. I am still very new > to Xymon and was just wondering if this was possible. > > Thank you, > Foster Patch Hi, Actually, you can have xymon perform any arbitrary action you like as a result of an alert. See the 'SCRIPT' option in alerts.cfg(5) for the syntax. When the script executes, it'll get a whole bunch of details set in various environment variables, which can be used to do whatever you like. Various folks use this as an integration point with other systems, so it could do an HTTP POST into a ticketing / pager system, save data to a file for further processing (like this), send an SNMP trap to something else, or perform any other action the 'xymon' system user has the ability to. About the only thing to keep in mind is that this is one of the few places in xymon that we actually fork a process when processing a message, so if you're writing something very heavy, consider what might happen if you get an alert storm. There are a number of sample scripts at https://wiki.xymonton.org/doku.php/alerts that might work for you, or at least give you some further ideas. HTH, -jc From cleaver at terabithia.org Tue Dec 8 22:21:09 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Tue, 8 Dec 2015 13:21:09 -0800 Subject: [Xymon] layout of terabithia xymon client In-Reply-To: References: Message-ID: On Tue, December 8, 2015 12:39 pm, Root, Paul T wrote: > I've recently inherited supporting a xymon network where the old admin use > the terabithia rpms. > > I've spent most of the day looking for a particular test for a particular > client. I finally found the script in /usr/share/xymon-client/sections > directory. > > I can't find where that gets called from? Is this a normal terabithia > layout? Where does it get invoked? > Hi, Yes, that's part of the normal layout in the RPMs: [root at localhost /]# rpm -qa xymon | xargs -r rpm -ql | grep /sections /usr/share/xymon-client/sections /usr/share/xymon-client/sections/README /usr/share/xymon-client/sections/ipcs etc.. It's analogous to the "/local" directory (https://sourceforge.net/p/xymon/code/6800/) in that it's called by the xymonclient.sh script after the standard ${OS} processing is done, but before the final logfetch stuff is completed. It's intended as a spot for drop-in additions to the clientlog data going back without having to modify xymonclient.sh itself. The only difference between "/local/" and "/sections/" is that executables in /local/ come back in "[local:NAME]" client sections, and /sections/ ones are just "[NAME]" The intent is that packagers (for distros or for add-ons) can place things into "/sections/", while custom per-host stuff goes into "/local/" and they don't conflict. (Sort of like the vendordir/sitedir/localdir distinction for some language plugins.) There are copies of the README in /usr/share/doc/xymon-client*/ also. "/sections/" was a Terabithia add, but it'll be in 4.4 too: https://sourceforge.net/p/xymon/code/7755/ HTH, -jc From Paul.Root at CenturyLink.com Tue Dec 8 22:48:27 2015 From: Paul.Root at CenturyLink.com (Root, Paul T) Date: Tue, 8 Dec 2015 21:48:27 +0000 Subject: [Xymon] layout of terabithia xymon client In-Reply-To: References: Message-ID: The readme file was conveniently deleted. Part of obfuscation of the old admin. -----Original Message----- From: J.C. Cleaver [mailto:cleaver at terabithia.org] Sent: Tuesday, December 08, 2015 3:21 PM To: Root, Paul T Cc: Xymon mailinglist Subject: Re: [Xymon] layout of terabithia xymon client On Tue, December 8, 2015 12:39 pm, Root, Paul T wrote: > I've recently inherited supporting a xymon network where the old admin use > the terabithia rpms. > > I've spent most of the day looking for a particular test for a particular > client. I finally found the script in /usr/share/xymon-client/sections > directory. > > I can't find where that gets called from? Is this a normal terabithia > layout? Where does it get invoked? > Hi, Yes, that's part of the normal layout in the RPMs: [root at localhost /]# rpm -qa xymon | xargs -r rpm -ql | grep /sections /usr/share/xymon-client/sections /usr/share/xymon-client/sections/README /usr/share/xymon-client/sections/ipcs etc.. It's analogous to the "/local" directory (https://sourceforge.net/p/xymon/code/6800/) in that it's called by the xymonclient.sh script after the standard ${OS} processing is done, but before the final logfetch stuff is completed. It's intended as a spot for drop-in additions to the clientlog data going back without having to modify xymonclient.sh itself. The only difference between "/local/" and "/sections/" is that executables in /local/ come back in "[local:NAME]" client sections, and /sections/ ones are just "[NAME]" The intent is that packagers (for distros or for add-ons) can place things into "/sections/", while custom per-host stuff goes into "/local/" and they don't conflict. (Sort of like the vendordir/sitedir/localdir distinction for some language plugins.) There are copies of the README in /usr/share/doc/xymon-client*/ also. "/sections/" was a Terabithia add, but it'll be in 4.4 too: https://sourceforge.net/p/xymon/code/7755/ HTH, -jc This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From Phil.Crooker at orix.com.au Wed Dec 9 00:22:09 2015 From: Phil.Crooker at orix.com.au (Phil Crooker) Date: Tue, 8 Dec 2015 23:22:09 +0000 Subject: [Xymon] Alerts.cfg doesn't wait before sending alert, help? In-Reply-To: References: Message-ID: <1449616925520.58543@orix.com.au> Maybe it is triggering on a different rule? Did you try running 'xymond_alert --test' to see what is actually happening? ________________________________________ From: Xymon on behalf of Eric Wedaa Sent: Wednesday, 9 December 2015 6:15 AM To: Xymon at xymon.com Subject: [Xymon] Alerts.cfg doesn't wait before sending alert, help? My Google-fu failed me, maybe somebody can point me in the right direction. I have an alerts.cfg file with the following contents: page=webservers2 mail eric.wedaa at marist.edu COLOR=red duration>5m repeat=4h mail eric.wedaa at marist.edu COLOR=!red recovered What is happening is it sends a yellow alert right away when the webserver goes down, and 15 minutes later sends a red alert. I THOUGHT that this would not send a yellow alert, and then send a RED alert after 5 minutes. What am I doing wrong please? >>>Ericw _______________________________________________ Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon From wlrutherford at alaska.edu Wed Dec 9 01:42:33 2015 From: wlrutherford at alaska.edu (Walter Rutherford) Date: Tue, 8 Dec 2015 15:42:33 -0900 Subject: [Xymon] deleted test purple status Message-ID: Hello, I ended up with two ssh tests in my xymon main page: ssh and ssh2. This isn't a big problem except it's redundant. What I *really* wanted was to test that ssh2 is running but ssh1 is not. I think that's accomplished with a combo test but I haven't configured one of those yet. But in the meantime when I got rid of ssh from the hosts.cfg file and ran: /xymon 127.0.0.1 "drop HOSTNAME ssh" I got a full purple ssh column. I found the hist and histlogs directories with many ssh subdirectories (which I thought the 'drop' should've cleared) and recursively removed all of the ssh directories. Still as purple as Barney. I know I've handled this problem a lifetime ago while using BigBrother, and what I did today feels familiar, but I'm missing something. I finally had to put ssh back into the hosts.cfg file when management noticed all the purple indicators and got a bit anxious. What did I do wrong? Walter R. -------------- next part -------------- An HTML attachment was scrubbed... URL: From neilsimmonds1808 at gmail.com Wed Dec 9 10:23:03 2015 From: neilsimmonds1808 at gmail.com (Neil Simmonds) Date: Wed, 9 Dec 2015 09:23:03 +0000 Subject: [Xymon] Custom addon - missing client data Message-ID: Hi Blake, I’m also trying to implement this and as far as I can see the “clear” column is correct for this test (There’s a part of the script that sets the colour to clear) but I have a problem with no graphs showing which seems to be because the rrd data is not present in the xymon/data/rrd/clientname/ directory. Did you manage to get it working? Regards, Neil. *From:* Xymon [mailto:xymon-bounces at xymon.com] *On Behalf Of *Blake *Sent:* 03 September 2015 22:20 *To:* xymon at xymon.com *Subject:* [Xymon] Custom addon - missing client data I am trying to implement "xymon-mysql-counters" by ZeWaren which I found on github https://github.com/ZeWaren/xymon-mysql-counters. I have followed the directions adding "xymon_mysql_counters.pl" to the ext directory of clients and updated the mysql login information. I have verified that the appropriate user account is able to execute the script with 755 permissions and manual execution of the script works. Updates to clientlaunch.cfg have been configured as well. The client was restarted after this work was completed. On the server I have updated graphs.cfg on the server under etc/ appending graphs.cfg from github to the end of the file. Server side a mysql column is now present, however only a "no data" icon is present. Reviewing the returned client data shows there is no "[mysql]" section. My setup is a pull configuration using memcache. Thanks in advance for all help to get this working. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlaidman at rebel-it.com.au Thu Dec 10 10:59:56 2015 From: jlaidman at rebel-it.com.au (Jeremy Laidman) Date: Thu, 10 Dec 2015 09:59:56 +0000 Subject: [Xymon] rclient on new xymon install via rpms In-Reply-To: References: <1949354395.11887087.1448892605820.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: Michael On Tue, Dec 1, 2015 at 1:13 AM Michael Resnick via Xymon wrote: > > # su - xymon > This account is currently not available. > Whenever I need to do something as the xymon user, I find it easiest to simply run "sudo -u xymon ~xymon/client/bin/xymoncmd". -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlaidman at rebel-it.com.au Thu Dec 10 11:25:45 2015 From: jlaidman at rebel-it.com.au (Jeremy Laidman) Date: Thu, 10 Dec 2015 10:25:45 +0000 Subject: [Xymon] issues with new install In-Reply-To: References: <46385f7a86d82e8d07ea64c0a65e7dad.squirrel@mail.kkytbs.net> Message-ID: Michael, have you checked your ghost report? Perhaps the hostnames in hosts.cfg don't match what the clients know themselves as. J On Wed, Dec 2, 2015 at 6:57 PM Michael Resnick via Xymon wrote: > Thanks. I have done more investigating. in the hostdata folder on the > xymon server shows up, all the servers show "No such host" in the Info > column, so it look like the hosts are not being created in hostdata. What > is the trigger that creates the data ? Weird problem. I have been using > xymon for years and have never seen this, but usually I build from the tar. > Thanks for any help. > > ------------------------------ > *From:* J.C. Cleaver > *To:* Michael Resnick > *Cc:* Xymon Mailing List > *Sent:* Tuesday, December 1, 2015 11:00 PM > > *Subject:* Re: issues with new install > > On Tue, December 1, 2015 8:04 am, Michael Resnick wrote: > > xymon server itself is fine. All the other servers are tests with conn > > only, with just 2 havingxymon client and 6 running rclient. > > none of the servers have a full set of columns except the xymon > > server.rclient log shows successfully completed 6 servers and the > > clientlog looks good. > > I may try rolling back to 4.3.21 or earlier. The last I used at my > > previous job was 4.3.11 > > It is a pain to install , since I have no Internet access in this > > environment. > > > Can you edit tasks.cfg to run "xymond_client" (in the [clientdata] > section) in --debug mode and see if you see data for these clients? > > Also, can you confirm that the non-xymonserver client (the "non-rclient" > one) is working OK and you're getting status messages for? > > It seems like either a well-formed client message isn't making its way in > in the first place, or xymond_client isn't properly processing it back > into xymond. Either way, we should be able to see some evidence (or not) > in the xymond_client logs as the clientlog injections occur. > > > HTH, > > > > -jc > > > > > ---------- Forwarded message ---------- > From: Michael Resnick via Xymon > To: "J.C. Cleaver" > Cc: Xymon Mailing List > Date: Wed, 2 Dec 2015 08:57:40 +0100 (CET) > Subject: Re: [Xymon] issues with new install > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlaidman at rebel-it.com.au Thu Dec 10 11:49:08 2015 From: jlaidman at rebel-it.com.au (Jeremy Laidman) Date: Thu, 10 Dec 2015 10:49:08 +0000 Subject: [Xymon] Xymon + graphite In-Reply-To: <1449514076552.92382@sas.com> References: <1449514076552.92382@sas.com> Message-ID: On Tue, Dec 8, 2015 at 5:49 AM Galen Johnson wrote: > Has anyone tried to integrate alerting based on Graphite? Or used > Graphite as a trending replacement to rrd? I love Xymon for my monitoring > but the limitations and aggregations of rrds are starting to become an > issue. > Nope, but I'm intrigued by Graphite. Most of my servers have enormously long trends pages because of all the extra graphs I've added. These are indispensable for tracking down weird faults. But the number of graphs and RRD files has become unwieldy. One major shortcoming is that I can't put metrics from different hosts onto the same graph. I've used RRGrapher < http://pages.cs.wisc.edu/~plonka/RRGrapher/> to let me create ad-hoc graphs like this, but it's obviously from last millennium, and could do with a facelift. I'd also like to integrate Smokeping into my monitoring service. Having multiple interfaces into the suite of RRD files makes for a less-than-intuitive user experience. For trending, Xymon can threshold (alert) on RRD files with the "DS" operator in analysis.cfg. Perhaps this can be extended to alert on Holt-Winters aberrant behaviour thresholds. Doing the same sort of thing with a rewrite of the g2zproxy probably wouldn't be too difficult, at least not on the Xymon side. J -------------- next part -------------- An HTML attachment was scrubbed... URL: From beckert at phys.ethz.ch Thu Dec 10 13:45:49 2015 From: beckert at phys.ethz.ch (Axel Beckert) Date: Thu, 10 Dec 2015 13:45:49 +0100 Subject: [Xymon] Segfault in confreport-critical.sh / confreport.cgi in 4.3.24 Message-ID: <20151210124549.GT21654@phys.ethz.ch> Hi, Via corekeeper (https://packages.debian.org/stable/corekeeper) I became aware of a segfault of confreport.cgi. I'm able to reproduce it (at least) in a fresh browser instance (all cookies removed), going to "Find host", searching for a non-existing host and then clicking on "Config Report (Critical)". It says "172 hosts included" (i.e. not just a single host as it happens if I searched for an existing host before) and then outputs most of the page, but ends in the middle of the alerts listing at line 8049 in the middle of a table: 079xxxxxxx at example.com (R)5m 1s -4h -purple ports0765 At least in one of the cases it ended in the same line, but with "076 instead of 0765". So I suspect we hit some C string size limit once again. I don't have a proper backtrace (yet), but I had look at the source code and I'm quite confident that the issue is inside the function print_alert_recipients() starting at lib/loadalerts.c, line 1124. I suspect it's an overflow of the variable "buf". "l" seems large enough with 4kB. Kind regards, Axel Beckert -- Axel Beckert support: +41 44 633 26 68 IT Services Group, HPT H 6 voice: +41 44 633 41 89 Departement of Physics, ETH Zurich CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ From beckert at phys.ethz.ch Thu Dec 10 14:59:13 2015 From: beckert at phys.ethz.ch (Axel Beckert) Date: Thu, 10 Dec 2015 14:59:13 +0100 Subject: [Xymon] Segfault in confreport-critical.sh / confreport.cgi in 4.3.24 (now with backtrace) In-Reply-To: <20151210124549.GT21654@phys.ethz.ch> References: <20151210124549.GT21654@phys.ethz.ch> Message-ID: <20151210135913.GU21654@phys.ethz.ch> Hi, On Thu, Dec 10, 2015 at 01:45:49PM +0100, Axel Beckert wrote: > I don't have a proper backtrace (yet), but I had look at the source > code and I'm quite confident that the issue is inside the function > print_alert_recipients() starting at lib/loadalerts.c, line 1124. Here's the according backtrace. Doesn't look too helpful to me, though: # gdb /usr/lib/xymon/server/bin/confreport.cgi ./207855-33-33-11-1449754874-silberspitz--usr-lib-xymon-server-bin-confreport.cgi.core GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 [...] Reading symbols from /usr/lib/xymon/server/bin/confreport.cgi...Reading symbols from /usr/lib/debug/.build-id/f2/5c37643ea6a391c09535cc250d18cef4aa39cf.debug...done. done. [New LWP 207855] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/lib/xymon/server/bin/confreport.cgi --env=/usr/lib/xymon/server/etc/xymons'. Program terminated with signal SIGSEGV, Segmentation fault. #0 strlen () at ../sysdeps/x86_64/strlen.S:106 106 ../sysdeps/x86_64/strlen.S: No such file or directory. (gdb) bt #0 strlen () at ../sysdeps/x86_64/strlen.S:106 #1 0x0000000000403640 in print_host (testcount=18, testnames=0x167dcc0, host=0x166b070) at confreport.c:310 #2 main (argc=, argv=) at confreport.c:876 Line 310 of web/confreport.c looks liek this: newitem->visualdata = (char *)realloc(newitem->visualdata, strlen(newitem->visualdata) + strlen(visdata) + 5); So do I read the backtrace correctly that there was no proper value (e.g. a null pointer) was passed to strlen()? Then again I also don't find any file named strlen.S on the system where I build the packages either. (But it seems to be part of glibc's source code.) Kind regards, Axel Beckert -- Axel Beckert support: +41 44 633 26 68 IT Services Group, HPT H 6 voice: +41 44 633 41 89 Departement of Physics, ETH Zurich CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ From cleaver at terabithia.org Thu Dec 10 17:02:15 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Thu, 10 Dec 2015 08:02:15 -0800 Subject: [Xymon] Xymon + graphite In-Reply-To: References: <1449514076552.92382@sas.com> Message-ID: <520af2b751766bd1ed81ce8b92b00de7.squirrel@mail.kkytbs.net> On Thu, December 10, 2015 2:49 am, Jeremy Laidman wrote: > On Tue, Dec 8, 2015 at 5:49 AM Galen Johnson > wrote: > >> Has anyone tried to integrate alerting based on Graphite? Or used >> Graphite as a trending replacement to rrd? I love Xymon for my >> monitoring >> but the limitations and aggregations of rrds are starting to become an >> issue. >> > Nope, but I'm intrigued by Graphite. Most of my servers have enormously > long trends pages because of all the extra graphs I've added. These are > indispensable for tracking down weird faults. But the number of graphs > and > RRD files has become unwieldy. One major shortcoming is that I can't put > metrics from different hosts onto the same graph. I've used RRGrapher < > http://pages.cs.wisc.edu/~plonka/RRGrapher/> to let me create ad-hoc > graphs > like this, but it's obviously from last millennium, and could do with a > facelift. I'd been looking at http://www.flotcharts.org/ and a few other RRD graphing packages that could be used providing a more browseable interface. There's absolutely a need (aside from the CSS work and a potential "dashboard" view generally) for improved multi-host and multi-graph views besides the linear trends output, I agree. > > For trending, Xymon can threshold (alert) on RRD files with the "DS" > operator in analysis.cfg. Perhaps this can be extended to alert on > Holt-Winters aberrant behaviour thresholds. Doing the same sort of thing > with a rewrite of the g2zproxy probably wouldn't be too difficult, at > least > not on the Xymon side. > (Actually, the RRD files generated on new RPM installs have had HWPREDICT, SEASONAL, and a few other RRA's configured for a while now, if anyone feels like experimenting...) One problem with the current RRD paradigm is that alerting is happening only with data available at insertion time, not using data that's stored into RRD file (or whatever metric store you have) already, so xymond_rrd can't efficiently alert on things beyond that. A "xymond_trend" could operate asynchronously on the RRD files, but to get useful trend data back out of RRDs you'll need to flush the data to disk first, which more or less blows out your I/O performance. Fine if you're on SSD, but more of a problem if you're on heavily loaded spinning disks. The problem there is just that there're just so many different ways of doing this with a lot of different needs. To make something flexible enough would require a good survey of what people are looking for. (With that in mind -- What are people looking for? :) Maybe it's easier than I'm thinking.) Alternatively, sending the metric data off entirely to a different package, which can reinject an alert into xymon if/when it notices a trend, is an easily-approachable option using the RRD --processor option, which can fork your metric feed off to whatever you like (OpenTSDB, graphite, splunk, etc...). The re-posting of alerts back into xymon can be done with that package's notification tool set and some scripting of xymon messages. Regards, -jc From cleaver at terabithia.org Thu Dec 10 17:23:23 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Thu, 10 Dec 2015 08:23:23 -0800 Subject: [Xymon] Segfault in confreport-critical.sh / confreport.cgi in 4.3.24 (now with backtrace) In-Reply-To: <20151210135913.GU21654@phys.ethz.ch> References: <20151210124549.GT21654@phys.ethz.ch> <20151210135913.GU21654@phys.ethz.ch> Message-ID: On Thu, December 10, 2015 5:59 am, Axel Beckert wrote: > Hi, > > On Thu, Dec 10, 2015 at 01:45:49PM +0100, Axel Beckert wrote: >> I don't have a proper backtrace (yet), but I had look at the source >> code and I'm quite confident that the issue is inside the function >> print_alert_recipients() starting at lib/loadalerts.c, line 1124. > > Here's the according backtrace. Doesn't look too helpful to me, > though: > > # gdb /usr/lib/xymon/server/bin/confreport.cgi > ./207855-33-33-11-1449754874-silberspitz--usr-lib-xymon-server-bin-confreport.cgi.core > GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 > [...] > Reading symbols from /usr/lib/xymon/server/bin/confreport.cgi...Reading > symbols from > /usr/lib/debug/.build-id/f2/5c37643ea6a391c09535cc250d18cef4aa39cf.debug...done. > done. > [New LWP 207855] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > Core was generated by `/usr/lib/xymon/server/bin/confreport.cgi > --env=/usr/lib/xymon/server/etc/xymons'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 strlen () at ../sysdeps/x86_64/strlen.S:106 > 106 ../sysdeps/x86_64/strlen.S: No such file or directory. > (gdb) bt > #0 strlen () at ../sysdeps/x86_64/strlen.S:106 > #1 0x0000000000403640 in print_host (testcount=18, testnames=0x167dcc0, > host=0x166b070) at confreport.c:310 > #2 main (argc=, argv=) at confreport.c:876 > > Line 310 of web/confreport.c looks liek this: > > newitem->visualdata = (char *)realloc(newitem->visualdata, > strlen(newitem->visualdata) + strlen(visdata) + 5); > > So do I read the backtrace correctly that there was no proper value > (e.g. a null pointer) was passed to strlen()? > > Then again I also don't find any file named strlen.S on the system > where I build the packages either. (But it seems to be part of glibc's > source code.) > > Kind regards, Axel Beckert Hmm, Well, that's different from loadalerts.c, but there does seem to be a problem there. Can you see if this patch helps? -jc -------------- next part -------------- A non-text attachment was scrubbed... Name: confreport.patch Type: text/x-patch Size: 850 bytes Desc: not available URL: From beckert at phys.ethz.ch Thu Dec 10 17:38:04 2015 From: beckert at phys.ethz.ch (Axel Beckert) Date: Thu, 10 Dec 2015 17:38:04 +0100 Subject: [Xymon] Segfault in confreport-critical.sh / confreport.cgi in 4.3.24 (now with backtrace) In-Reply-To: References: <20151210124549.GT21654@phys.ethz.ch> <20151210135913.GU21654@phys.ethz.ch> Message-ID: <20151210163804.GV21654@phys.ethz.ch> Hi JC, On Thu, Dec 10, 2015 at 08:23:23AM -0800, J.C. Cleaver wrote: > On Thu, December 10, 2015 5:59 am, Axel Beckert wrote: > > On Thu, Dec 10, 2015 at 01:45:49PM +0100, Axel Beckert wrote: > >> I don't have a proper backtrace (yet), but I had look at the source > >> code and I'm quite confident that the issue is inside the function > >> print_alert_recipients() starting at lib/loadalerts.c, line 1124. > > > > Here's the according backtrace. Doesn't look too helpful to me, > > though: [...] > > #1 0x0000000000403640 in print_host (testcount=18, testnames=0x167dcc0, > > host=0x166b070) at confreport.c:310 [...] > Well, that's different from loadalerts.c, Indeed. My first guess was solely based on where the interrupted HTML output comes from. > but there does seem to be a problem there. Yeah, I figured in the meanwhile that visdata likely was NULL to cause that crash. I was just not sure which places would all need changes to fix that. > Can you see if this patch helps? Will check. Thanks for the patch! > Index: web/confreport.c > =================================================================== > --- web/confreport.c (revision 7835) > +++ web/confreport.c (working copy) > @@ -288,9 +288,10 @@ > } > else if (is_net_test(itm)) { > colname = strdup(itm); > + visdata = strdup(""); > } > > - > + if (!visdata) visdata = strdup(""); Those two additionans look a little bit redundant, but that shouldn't cause any harm. (I'd say the first addition shouldn't be necessary if the second one is present.) > - newitem->visualdata = (char *)realloc(newitem->visualdata, strlen(newitem->visualdata) + strlen(visdata) + 5); > + newitem->visualdata = newitem->visualdata ? > + (char *)realloc(newitem->visualdata, strlen(newitem->visualdata) + strlen(visdata) + 5) : > + (char *)malloc(strlen(visdata) + 5); That's the place where I thought, it might need changes, too, but I had no ideas which exactly. Kind regards, Axel Beckert -- Axel Beckert support: +41 44 633 26 68 IT Services Group, HPT H 6 voice: +41 44 633 41 89 Departement of Physics, ETH Zurich CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ From beckert at phys.ethz.ch Thu Dec 10 17:53:16 2015 From: beckert at phys.ethz.ch (Axel Beckert) Date: Thu, 10 Dec 2015 17:53:16 +0100 Subject: [Xymon] Segfault in confreport-critical.sh / confreport.cgi in 4.3.24 (now with backtrace) In-Reply-To: References: <20151210124549.GT21654@phys.ethz.ch> <20151210135913.GU21654@phys.ethz.ch> Message-ID: <20151210165316.GW21654@phys.ethz.ch> Hi JC, On Thu, Dec 10, 2015 at 08:23:23AM -0800, J.C. Cleaver wrote: > Can you see if this patch helps? The patched helped, thanks! Can't reproduce the issue anymore. Kind regards, Axel Beckert -- Axel Beckert support: +41 44 633 26 68 IT Services Group, HPT H 6 voice: +41 44 633 41 89 Departement of Physics, ETH Zurich CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ From bferrell at baywinds.org Thu Dec 10 18:05:40 2015 From: bferrell at baywinds.org (Bruce Ferrell) Date: Thu, 10 Dec 2015 09:05:40 -0800 Subject: [Xymon] Xymon + graphite In-Reply-To: <520af2b751766bd1ed81ce8b92b00de7.squirrel@mail.kkytbs.net> References: <1449514076552.92382@sas.com> <520af2b751766bd1ed81ce8b92b00de7.squirrel@mail.kkytbs.net> Message-ID: <5669B0E4.1000302@baywinds.org> On 12/10/2015 08:02 AM, J.C. Cleaver wrote: > > On Thu, December 10, 2015 2:49 am, Jeremy Laidman wrote: >> On Tue, Dec 8, 2015 at 5:49 AM Galen Johnson >> wrote: >> >>> Has anyone tried to integrate alerting based on Graphite? Or used >>> Graphite as a trending replacement to rrd? I love Xymon for my >>> monitoring >>> but the limitations and aggregations of rrds are starting to become an >>> issue. >>> >> Nope, but I'm intrigued by Graphite. Most of my servers have enormously >> long trends pages because of all the extra graphs I've added. These are >> indispensable for tracking down weird faults. But the number of graphs >> and >> RRD files has become unwieldy. One major shortcoming is that I can't put >> metrics from different hosts onto the same graph. I've used RRGrapher < >> http://pages.cs.wisc.edu/~plonka/RRGrapher/> to let me create ad-hoc >> graphs >> like this, but it's obviously from last millennium, and could do with a >> facelift. > I'd been looking at http://www.flotcharts.org/ and a few other RRD > graphing packages that could be used providing a more browseable > interface. There's absolutely a need (aside from the CSS work and a > potential "dashboard" view generally) for improved multi-host and > multi-graph views besides the linear trends output, I agree. > >> For trending, Xymon can threshold (alert) on RRD files with the "DS" >> operator in analysis.cfg. Perhaps this can be extended to alert on >> Holt-Winters aberrant behaviour thresholds. Doing the same sort of thing >> with a rewrite of the g2zproxy probably wouldn't be too difficult, at >> least >> not on the Xymon side. >> > (Actually, the RRD files generated on new RPM installs have had HWPREDICT, > SEASONAL, and a few other RRA's configured for a while now, if anyone > feels like experimenting...) > > > One problem with the current RRD paradigm is that alerting is happening > only with data available at insertion time, not using data that's stored > into RRD file (or whatever metric store you have) already, so xymond_rrd > can't efficiently alert on things beyond that. > > A "xymond_trend" could operate asynchronously on the RRD files, but to get > useful trend data back out of RRDs you'll need to flush the data to disk > first, which more or less blows out your I/O performance. Fine if you're > on SSD, but more of a problem if you're on heavily loaded spinning disks. > > The problem there is just that there're just so many different ways of > doing this with a lot of different needs. To make something flexible > enough would require a good survey of what people are looking for. > > (With that in mind -- What are people looking for? :) Maybe it's easier > than I'm thinking.) > > > Alternatively, sending the metric data off entirely to a different > package, which can reinject an alert into xymon if/when it notices a > trend, is an easily-approachable option using the RRD --processor option, > which can fork your metric feed off to whatever you like (OpenTSDB, > graphite, splunk, etc...). The re-posting of alerts back into xymon can be > done with that package's notification tool set and some scripting of xymon > messages. > > > Regards, > -jc Having done a bit of this type of thing in another life, what you're discussing is what we termed an alert manager/data collector architecture. The entire beauty of rrd data storage is it's simplicity and It automatically does rollups. I started my charting using flot and because of the complexity of managing js charting on all the different browsers, I eventually scrapped js charting entirely and used GD to generate chart images. For the particular use case, RRD didn't make sense as exact storage historical data was mandatory... rollups/data averaging was not allowed. From cleaver at terabithia.org Thu Dec 10 18:22:37 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Thu, 10 Dec 2015 09:22:37 -0800 Subject: [Xymon] Segfault in confreport-critical.sh / confreport.cgi in 4.3.24 (now with backtrace) In-Reply-To: <20151210165316.GW21654@phys.ethz.ch> References: <20151210124549.GT21654@phys.ethz.ch> <20151210135913.GU21654@phys.ethz.ch> <20151210165316.GW21654@phys.ethz.ch> Message-ID: On Thu, December 10, 2015 8:53 am, Axel Beckert wrote: > Hi JC, > > On Thu, Dec 10, 2015 at 08:23:23AM -0800, J.C. Cleaver wrote: >> Can you see if this patch helps? > > The patched helped, thanks! Can't reproduce the issue anymore. > Perfect, thanks! -jc (From earlier) >> --- web/confreport.c (revision 7835) >> +++ web/confreport.c (working copy) >> @@ -288,9 +288,10 @@ >> } >> else if (is_net_test(itm)) { >> colname = strdup(itm); >> + visdata = strdup(""); >> } >> >> - >> + if (!visdata) visdata = strdup(""); > > Those two additionans look a little bit redundant, but that shouldn't > cause any harm. (I'd say the first addition shouldn't be necessary > if the second one is present.) > That's correct. I added that primarily because of the structures above it (which all set visdata), and because I wasn't quite sure of ultimate source of some of this, and what was liable to fall through or not. From john.thurston at alaska.gov Thu Dec 10 18:24:53 2015 From: john.thurston at alaska.gov (John Thurston) Date: Thu, 10 Dec 2015 08:24:53 -0900 Subject: [Xymon] Xymon + graphite In-Reply-To: <520af2b751766bd1ed81ce8b92b00de7.squirrel@mail.kkytbs.net> References: <1449514076552.92382@sas.com> <520af2b751766bd1ed81ce8b92b00de7.squirrel@mail.kkytbs.net> Message-ID: <5669B565.2030502@alaska.gov> On 12/10/2015 7:02 AM, J.C. Cleaver wrote: > > Alternatively, sending the metric data off entirely to a different > package, which can reinject an alert into xymon if/when it notices a > trend, is an easily-approachable option using the RRD --processor option, > which can fork your metric feed off to whatever you like (OpenTSDB, > graphite, splunk, etc...). The re-posting of alerts back into xymon can be > done with that package's notification tool set and some scripting of xymon > messages. This seems like the "Xymonish" way to do this. Attempting to embed cross-host, historic-metric, and trending analysis seems to stray pretty far from the Big Brother/Xymon tradition. "Give me a red/yellow/green message and I'll put it a web page and send an email to whomever you have specified." (See my sig-line) -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska From ampinder.singh at hotmail.com Thu Dec 10 19:37:27 2015 From: ampinder.singh at hotmail.com (Ampinder Singh) Date: Thu, 10 Dec 2015 18:37:27 +0000 Subject: [Xymon] SCRIPT running twice Message-ID: Hello, I'm having an issue here. I want to run an external script in Xymon. So i follow the docs. I'm trying to run a test script that will for now just to an echo to a logfile. Here is what I have done. * In analysis.cfg HOST=qcdvap1096 LOG /home/xymon/client4.3.17/logfile "testword" * In client-local.cfg [qcdvap1096] log:/home/xymon/client4.3.17/logfile:2048 trigger error #The logfile is on the client * In alerts.cfg HOST=qcdvap1096 SERVICE=msgs COLOR=red,purple #MAIL ampinder.singh at cgi.com COLOR=red REPEAT=2h #SCRIPT /home/xymon/server/scripts/connect.sh MAIL ampinder.singh at cgi.com COLOR=red SCRIPT /home/xymon/server/scripts/connect.sh MAIL ampinder.singh at cgi.com COLOR=red I have created my test script on the server: #Name of the script: connect.sh #!/bin/bash #This script on the server where Xymon is installed will call another script ont the client (qcdvap1096) ssh xymon at 142.101.131.45 /home/xymon/client4.3.17/ext/test.sh This is my script on the client (qcdvap1096) that gets called #!/bin/bash #Name of the script: test.sh #Working line #echo "it's down again" >> /home/xymon/client4.3.17/loggenerated.txt echo "`date` "Server" "went" "out"" >> /home/xymon/client4.3.17/ampinder.txt So I manually add the word "testword" on logfile and it works my script gets called. But my only issue is that the script gets run twice. Like a second of eachother Here is the output of the log generated (/home/xymon/client4.3.17/loggenerated.tx) Thu Dec 10 13:12:55 EST 2015 Server went out Thu Dec 10 13:12:56 EST 2015 Server went out I dont know why it runs twice. I only want it to run once. As soon, it's see the word "testword" it should run it once. Could you please help me resolve this issue? Thanks Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From cleaver at terabithia.org Thu Dec 10 21:59:20 2015 From: cleaver at terabithia.org (Japheth Cleaver) Date: Thu, 10 Dec 2015 12:59:20 -0800 Subject: [Xymon] SCRIPT running twice In-Reply-To: References: Message-ID: <5669E7A8.6000003@terabithia.org> On 12/10/2015 10:37 AM, Ampinder Singh wrote: > > Hello, > > > I'm having an issue here. I want to run an external script in Xymon. > So i follow the docs. > > > I'm trying to run a test script that will for now just to an echo to a > logfile. > > > Here is what I have done. > > > * In analysis.cfg > > HOST=qcdvap1096 > LOG /home/xymon/client4.3.17/logfile "testword" > > * In client-local.cfg > [qcdvap1096] > log:/home/xymon/client4.3.17/logfile:2048 > trigger error > #The logfile is on the client > > * In alerts.cfg > HOST=qcdvap1096 SERVICE=msgs COLOR=red,purple > #MAIL ampinder.singh at cgi.com COLOR=red REPEAT=2h > #SCRIPT /home/xymon/server/scripts/connect.sh MAIL > ampinder.singh at cgi.com COLOR=red > SCRIPT /home/xymon/server/scripts/connect.sh MAIL > ampinder.singh at cgi.com COLOR=red > > > I have created my test script on the server: > #Name of the script: connect.sh > #!/bin/bash > #This script on the server where Xymon is installed will call another > script ont the client (qcdvap1096) > > ssh xymon at 142.101.131.45 /home/xymon/client4.3.17/ext/test.sh > > > This is my script on the client (qcdvap1096) that gets called > #!/bin/bash > #Name of the script: test.sh > #Working line > #echo "it's down again" >> /home/xymon/client4.3.17/loggenerated.txt > echo "`date` "Server" "went" "out"" >> > /home/xymon/client4.3.17/ampinder.txt > > So I manually add the word "testword" on logfile and it works my > script gets called. But my only issue is that the script gets run > twice. Like a second of eachother > > Here is the output of the log generated > (/home/xymon/client4.3.17/loggenerated.tx) > Thu Dec 10 13:12:55 EST 2015 Server went out > Thu Dec 10 13:12:56 EST 2015 Server went out > > I dont know why it runs twice. I only want it to run once. As soon, > it's see the word "testword" it should run it once. > > Could you please help me resolve this issue? > Thanks > Ajay Hi Ajay, That's an interesting bug there. The format for the SCRIPT line there is incorrect. The line: SCRIPT /home/xymon/server/scripts/connect.sh MAIL ampinder.singh at cgi.com COLOR=red should just be: SCRIPT /home/xymon/server/scripts/connect.sh ampinder.singh at cgi.com COLOR=red You should be able to run xymoncmd xymond_alert --dump-config before and after to see the difference. That being said, that mis-parsing shouldn't be causing commented lines to be read in improperly... So this is definitely a bug *somewhere*. Thanks for catching it. -jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andy.Farrior at victoriacollege.edu Fri Dec 11 04:14:16 2015 From: Andy.Farrior at victoriacollege.edu (FARRIOR, Andy) Date: Thu, 10 Dec 2015 21:14:16 -0600 Subject: [Xymon] how to get list of IP addresses used by Xymon for each host entry Message-ID: <0C30D5638F986649941729D95098903B48A401029A@mail2007.victoriacollege.edu> if your hosts.cfg file looks like this: 0.0.0.0 foo # dns 10.1.1.2 bar # testip ntp and the DNS lookup for foo is 10.1.1.1, what xymon command would I issue in a script to get a list of the IP addresses Xymon has associated with each host? so, for the above example, the result would be: 10.1.1.1 foo # tests 10.1.1.2 bar # tests I'm looking for a way to get the IP addresses Xymon is using for each host. thx, andy From cleaver at terabithia.org Fri Dec 11 06:31:44 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Thu, 10 Dec 2015 21:31:44 -0800 Subject: [Xymon] how to get list of IP addresses used by Xymon for each host entry In-Reply-To: <0C30D5638F986649941729D95098903B48A401029A@mail2007.victoriacollege.edu> References: <0C30D5638F986649941729D95098903B48A401029A@mail2007.victoriacollege.edu> Message-ID: <585541c20d8ac9cce0c5430041e6d01f.squirrel@mail.kkytbs.net> On Thu, December 10, 2015 7:14 pm, FARRIOR, Andy wrote: > > if your hosts.cfg file looks like this: > > 0.0.0.0 foo # dns > 10.1.1.2 bar # testip ntp > > and the DNS lookup for foo is 10.1.1.1, what xymon command would I issue > in a script to get a list of the IP addresses Xymon has associated with > each host? > > > so, for the above example, the result would be: > > 10.1.1.1 foo # tests > 10.1.1.2 bar # tests > > > I'm looking for a way to get the IP addresses Xymon is using for each > host. It depends a little on what you want. In a real sense, xymon doesn't systematically maintain a list of addresses used for the host. The only component that looks them up (xymonnet) does a fresh DNS lookup for each one with "0.0.0.0" that it finds. It's using the c-ares library for that, but it basically follows the same rules as the normal system resolver. It shouldn't be any different than scripting a 'host $SERVERNAME' call against hosts with no IP configured and parsing the result. Since xymonnet is executed, and then exits and is restarted at the next poll cycle, there's nothing that can really get cached either. If you want to see what IP actually *happened*, you could try something like this to get at the results of the 'conn' tests if you're using 4.3.18 or higher. xymon localhost "xymondboard test=conn fields=hostname,msg" | perl -pe 's/^([\w.-]+)\W.*&\w+\s([\d.]+).*/\1 \2/' All of the other ways of pulling data from xymond (like below) will just return the configured IP itself... the 0.0.0.0. xymon localhost "hostinfo fields=XMH_HOSTNAME,XMH_IP" HTH, -jc From henrik at hswn.dk Fri Dec 11 12:05:59 2015 From: henrik at hswn.dk (=?UTF-8?Q?Henrik_St=C3=B8rner?=) Date: Fri, 11 Dec 2015 12:05:59 +0100 Subject: [Xymon] Patch for xymonnet: Fails to detect closed ports on SSL-enabled services Message-ID: <37ee69bb11b6ef771e58eb944783e78f@hswn.dk> Hi, I ran into a weird issue this morning. When testing an SSL-enabled service (amqps), the status showed up as green even though there was no service listening on the port. It may be related to the fairly old OpenSSL version installed (0.9.8j + SUSE patches), because I have never seen it before - and it sounds like the kind of bug that ought to pop up fairly quickly. Debug shows: 38969 2015-12-11 12:02:01.466947 TCP tests completed normally Address=10.0.0.1:5671, open=1, res=0, err=5, connecttime=0.001542, totaltime=0.001542, 38969 2015-12-11 12:02:01.467163 Sending results for service amqps 38969 2015-12-11 12:02:01.467205 Adding to combo msg: status+30 foo,example,com.amqps green Fri Dec 11 12:02:01 2015 amqps ok The "open=1" is what triggers the green status, but it doesn't match the "err=5" which means the openssl-functions returned an error. This patch should fix it - against 4.3.24. Regards, Henrik -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssl-connrefused-4_3_24.diff URL: From fclaire at free.fr Fri Dec 11 14:00:59 2015 From: fclaire at free.fr (Francois Claire) Date: Fri, 11 Dec 2015 14:00:59 +0100 Subject: [Xymon] Bug in findhost ? In-Reply-To: <565FF8E3.90005@free.fr> References: <565FF8E3.90005@free.fr> Message-ID: <566AC90B.2090800@free.fr> Up ! > Hi, > > > I have troubles using the findhost feature with the "Jump to page" box > checked. On my xymon server the result URL is using localhost instead > of my xymon server's FQDN. > > This problem seems to be reproducible on www.xymon.com: > - go to https://www.xymon.com/xymon-cgi/findhost.sh > - enter "ipgw" in the search field > - hit the search button > - you're redirected towards http://vxymon.hswn.dk/services/#ipgw.hswn.dk > > Host vxymon.hswn.dk doesn't exist. On my system it's redirecting to > http://localhost. > > 2 questions: > - why is the xymon server hostname changing and is there a place to > configure it for findhost's answer ? > - why is the answer redirecting to http when the query was done on a > https URL ? > > > I looked into findhost.c but didn't have enough time to understand how > all of this works. > > > Cheers, > Francois. > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon From fclaire at free.fr Fri Dec 11 14:05:16 2015 From: fclaire at free.fr (Francois Claire) Date: Fri, 11 Dec 2015 14:05:16 +0100 Subject: [Xymon] xymonnet yellow alarm Message-ID: <566ACA0C.9030206@free.fr> Hi, Is there a way to configure the number of seconds where xymonnet will start to do a yellow alarm ? I can't find anything... I remember it was doing yellow alarms only if time to execute all tests is greater than 300 seconds. It seems it's now 20 seconds on my xymon server 4.3.21-4.el7.terabithia. Any hint is welcome. Cheers, Francois. From patrik_xymon at outlook.com Fri Dec 11 14:50:06 2015 From: patrik_xymon at outlook.com (Patrik Nussbaumer) Date: Fri, 11 Dec 2015 14:50:06 +0100 Subject: [Xymon] upgrade from BigBrother to Xymon Message-ID: Dear Xymon-Team I have some question about the Xymon Server. Can I upgrade from a BigBrother Server (Windows Server 2003) to a Xymon Server (UNIX)? Works Xymon on Windows Operating System (newer than Windows Server 2003)? Should I installing a ubuntu server version or will be ok when i installing ubuntu desktop version? Thanks for the answer best regards Patrik Nussbaumer -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Fri Dec 11 15:19:32 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 11 Dec 2015 09:19:32 -0500 Subject: [Xymon] upgrade from BigBrother to Xymon In-Reply-To: References: Message-ID: Yes Not really... Server would be best, though not necessary Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Dec 11, 2015 8:56 AM, "Patrik Nussbaumer" wrote: > Dear Xymon-Team > > > > I have some question about the Xymon Server. > > > > Can I upgrade from a BigBrother Server (Windows Server 2003) to a Xymon > Server (UNIX)? > > Works Xymon on Windows Operating System (newer than Windows Server 2003)? > > Should I installing a ubuntu server version or will be ok when i > installing ubuntu desktop version? > > > > Thanks for the answer > > > > best regards Patrik Nussbaumer > > > > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik at hswn.dk Fri Dec 11 15:37:57 2015 From: henrik at hswn.dk (=?UTF-8?Q?Henrik_St=C3=B8rner?=) Date: Fri, 11 Dec 2015 15:37:57 +0100 Subject: [Xymon] upgrade from BigBrother to Xymon In-Reply-To: References: Message-ID: Hi, Xymon server-part only runs on Linux (and other Unix variants). It will work fine on any of the Ubuntu variants, server or desktop. Upgrading from BB should be fairly straight-forward - your bb-hosts file must be renamed to "hosts.cfg", and the alert-setup must be re-done, since the Xymon alert configuration is very different. Regards, Henrik Den 11-12-2015 14:50, Patrik Nussbaumer skrev: > Dear Xymon-Team > > I have some question about the Xymon Server. > > Can I upgrade from a BigBrother Server (Windows Server 2003) to a Xymon Server (UNIX)? > > Works Xymon on Windows Operating System (newer than Windows Server 2003)? > > Should I installing a ubuntu server version or will be ok when i installing ubuntu desktop version? > > Thanks for the answer > > best regards Patrik Nussbaumer -------------- next part -------------- An HTML attachment was scrubbed... URL: From cleaver at terabithia.org Fri Dec 11 19:07:29 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Fri, 11 Dec 2015 10:07:29 -0800 Subject: [Xymon] Patch for xymonnet: Fails to detect closed ports on SSL-enabled services In-Reply-To: <37ee69bb11b6ef771e58eb944783e78f@hswn.dk> References: <37ee69bb11b6ef771e58eb944783e78f@hswn.dk> Message-ID: <9e29248efb96780b90844ec55b65dfda.squirrel@mail.kkytbs.net> On Fri, December 11, 2015 3:05 am, Henrik StÃ¸rner wrote: > Hi, > > I ran into a weird issue this morning. > > When testing an SSL-enabled service (amqps), the status showed up as > green even though there was no service listening on the port. > > It may be related to the fairly old OpenSSL version installed (0.9.8j + > SUSE patches), because I have never seen it before - and it sounds like > the kind of bug that ought to pop up fairly quickly. > > Debug shows: > 38969 2015-12-11 12:02:01.466947 TCP tests completed normally > Address=10.0.0.1:5671, open=1, res=0, err=5, connecttime=0.001542, > totaltime=0.001542, > 38969 2015-12-11 12:02:01.467163 Sending results for service amqps > 38969 2015-12-11 12:02:01.467205 Adding to combo msg: status+30 > foo,example,com.amqps green Fri Dec 11 > 12:02:01 2015 amqps ok > > The "open=1" is what triggers the green status, but it doesn't match > the "err=5" which means the openssl-functions returned an error. > > This patch should fix it - against 4.3.24. > This is an odd one. It really does seem like this should have been run into somehow before... How would you feel about expanding the parsing in xymonnet.c:decide_color() to catch for errors even on an open port? Something like the attached (untested)... -jc -------------- next part -------------- A non-text attachment was scrubbed... Name: ssl-connstrange.patch Type: text/x-patch Size: 1187 bytes Desc: not available URL: From cleaver at terabithia.org Fri Dec 11 19:16:02 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Fri, 11 Dec 2015 10:16:02 -0800 Subject: [Xymon] xymonnet yellow alarm In-Reply-To: <566ACA0C.9030206@free.fr> References: <566ACA0C.9030206@free.fr> Message-ID: <02024a8d518df2fc626ec29208a6dfb9.squirrel@mail.kkytbs.net> On Fri, December 11, 2015 5:05 am, Francois Claire wrote: > Hi, > > > Is there a way to configure the number of seconds where xymonnet will > start to do a yellow alarm ? > > I can't find anything... > > I remember it was doing yellow alarms only if time to execute all tests > is greater than 300 seconds. It seems it's now 20 seconds on my xymon > server 4.3.21-4.el7.terabithia. > > > Any hint is welcome. > Hi Francois, The xymonnet test itself will go yellow if its overall runtime exceeds the interval it's configured to execute at (according to xymonlaunch -- passed down via a $TASKSLEEP environment variable to any process which is executed at INTERVALs in tasks.cfg). xymonlaunch won't kill xymonnet if it takes longer, but it also won't launch it again until it finishes, so it's sort of a warning that your polling interval is not executing at the frequency desired. With xymonnet it's usually not effective to have it below the maximum --timeout value you're using for tests, since if there's anything unreachable it's going to cause the entire cycle to be delayed until that timeout happens. In the event there's a large network break or switch issue and you have a LOT of TCP (or worse, UDP) services down, xymonnet can end up taking longer than expected if your --concurrency=N isn't large enough to handle all the timeouts happening at once. It may be helpful to increase that value to handle a maximum "reasonable" simultaneous outage situation. HTH, -jc From cleaver at terabithia.org Fri Dec 11 19:18:36 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Fri, 11 Dec 2015 10:18:36 -0800 Subject: [Xymon] Bug in findhost ? In-Reply-To: <566AC90B.2090800@free.fr> References: <565FF8E3.90005@free.fr> <566AC90B.2090800@free.fr> Message-ID: <92be4d1c66607cb797c8eb3d0167fb4b.squirrel@mail.kkytbs.net> On Fri, December 11, 2015 5:00 am, Francois Claire wrote: >> >> I have troubles using the findhost feature with the "Jump to page" box >> checked. On my xymon server the result URL is using localhost instead >> of my xymon server's FQDN. >> >> This problem seems to be reproducible on www.xymon.com: >> - go to https://www.xymon.com/xymon-cgi/findhost.sh >> - enter "ipgw" in the search field >> - hit the search button >> - you're redirected towards http://vxymon.hswn.dk/services/#ipgw.hswn.dk >> >> Host vxymon.hswn.dk doesn't exist. On my system it's redirecting to >> http://localhost. >> >> 2 questions: >> - why is the xymon server hostname changing and is there a place to >> configure it for findhost's answer ? >> - why is the answer redirecting to http when the query was done on a >> https URL ? >> Confirmed; thanks for the report. It should just be using a relative URL by default, so there's certainly an error in there. A workaround for the moment is to uncheck the "Jump to page" option when searching. Regards, -jc From larry at fni-stl.com Fri Dec 11 20:26:17 2015 From: larry at fni-stl.com (Larry Bonham) Date: Fri, 11 Dec 2015 19:26:17 +0000 Subject: [Xymon] CONFIGCLASS change not getting picked up Message-ID: Not a major deal but as we are updating systems and changing OS versions (e.g. CONFIGCLASS=rhel6 changed to CONFIGCLASS=rhel7) the new setting is not getting read by the xymon server until I do a full restart of the xymon service. "service xymon-server reload" did not work. Also restarted remote side (hobbit in this case), dropped the client, added it back. Server kept using the old CONFIGCLASS setting even though the data coming through had the new value as shown in clientlog. [collector:] client xxxxx.linux rhel7 Anyone run into this before? v4.3.21 RHEL 6.7 ========================================================= Larry D. Bonham Financial Network Inc. ========================================================= ________________________________ CONFIDENTIALITY NOTICE: This electronic mail message is intended exclusively for recipient to which it is addressed. The contents of this message and any attachments may contain confidential and privileged information. Any unauthorized review, use, print, storage, copy, disclosure or distribution is strictly prohibited. If you have received this message in error, please advise the sender immediately by replying to the message's sender and delete all copies of this message and its attachments without disclosing the contents to anyone, or using the contents for any purpose. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cleaver at terabithia.org Sat Dec 12 21:11:34 2015 From: cleaver at terabithia.org (J.C. Cleaver) Date: Sat, 12 Dec 2015 12:11:34 -0800 Subject: [Xymon] Bug in findhost ? In-Reply-To: <92be4d1c66607cb797c8eb3d0167fb4b.squirrel@mail.kkytbs.net> References: <565FF8E3.90005@free.fr> <566AC90B.2090800@free.fr> <92be4d1c66607cb797c8eb3d0167fb4b.squirrel@mail.kkytbs.net> Message-ID: <8dd2adf972d9faadf7064987e2e0cfc2.squirrel@mail.kkytbs.net> On Fri, December 11, 2015 10:18 am, J.C. Cleaver wrote: > On Fri, December 11, 2015 5:00 am, Francois Claire wrote: > >>> >>> I have troubles using the findhost feature with the "Jump to page" box >>> checked. On my xymon server the result URL is using localhost instead >>> of my xymon server's FQDN. >>> >>> This problem seems to be reproducible on www.xymon.com: >>> - go to https://www.xymon.com/xymon-cgi/findhost.sh >>> - enter "ipgw" in the search field >>> - hit the search button >>> - you're redirected towards >>> http://vxymon.hswn.dk/services/#ipgw.hswn.dk >>> >>> Host vxymon.hswn.dk doesn't exist. On my system it's redirecting to >>> http://localhost. >>> >>> 2 questions: >>> - why is the xymon server hostname changing and is there a place to >>> configure it for findhost's answer ? >>> - why is the answer redirecting to http when the query was done on a >>> https URL ? >>> > > > Confirmed; thanks for the report. It should just be using a relative URL > by default, so there's certainly an error in there. > > A workaround for the moment is to uncheck the "Jump to page" option when > searching. There are actually a few different issues here, which will warrant slightly different solutions in 4.3.25 and 4.4x . The problem stems from how we're loading the environment in for the CGI scripts, which is slightly different than initscript-run xymonlaunch tasks or simply using the xymoncmd command. As a quick fix, do one of: - ensure your $XYMONWEBHOST variable in xymonserver.cfg is a statically assigned URL part, and/or - ensure $XYMONSERVERHOSTNAME and $XYMONSERVERWWWNAME variables are hard-coded to your server name, and/or - add a "MACHINEDOTS=your.hostname.here" entry to cgioptions.cfg This will also fix a display issue on the "info" page for hosts that have notes configured (the link works, but the link text URL is wrong). HTH, -jc From colin.coe at gmail.com Mon Dec 14 04:48:19 2015 From: colin.coe at gmail.com (Colin Coe) Date: Mon, 14 Dec 2015 11:48:19 +0800 Subject: [Xymon] clientconfig.cfg not getting updated Message-ID: Hi all I'm noticing that the Windows Powershell Xymon client isn't being updated to reflect changes in client-local.cfg. I had thought that changes on the Xymon server to client-local.cfg would result in changes on the Windows clients. Am I wrong here, and if so, what's the correct way to get these changes propagated out? I'm wanting the following to be pushed out to the clients: --- tail -n 2 /etc/xymon/client-local.cfg [os=powershell] clientversion:2.04:http://benmon1p.scada.horizonpower.com.au/pub/ --- clientlocal.cfg contains: --- eventlog:security ignore success ignore Success ignore "The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer" eventlog:system ignore "Contact the administrator to install the driver before you log in again" tssessions adreplicaton --- Thanks CC From BDale at kitchengroup.com.au Mon Dec 14 05:30:33 2015 From: BDale at kitchengroup.com.au (Brandon Dale) Date: Mon, 14 Dec 2015 04:30:33 +0000 Subject: [Xymon] clientconfig.cfg not getting updated In-Reply-To: References: Message-ID: <96BCCCBE6729EC4AA7F7806640317F4F268F43@KGexch01.kitchen-net.com.au> If you haven't already I would read through http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/XymonPSClient.doc it's pretty decent documentation. Try double checking this stuff: 1. Make sure you have copied the .xml file that contains the configuration for the client to the local machine into the same directory where the xymonclient.ps1 script lives http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/xymonclient_config.xml and that this contains a path for the client-local.cfg file and has clientremotecfgexec set to 1 (this is already done by default in the .xml file in that link) 2. Put your settings into the client-local.cfg file on your xymon server, I have put an example below, the valid commands are listed in XymonPSClient.doc [powershell] eventlogswanted:*:250000:warning,critical,error ifstat:ipv4 clientversion:2.04:\\somepath\goes\here 3. Wait for or manually run the PowerShell client (by restarting the XymonPSClient Service in windows), you need to do this at least twice as the first time you run it, it will get the commands you have in your client-local.cfg file on your xymon server and write them to the clientconfig.cfg (or whatever you called it in the .xml file) the second time it runs it will start reading it. Note: make sure you read the documentation for the eventlog ignore rules, the syntax is different. You can still use the IGNORE PATTERN but the way you select which eventlogs to check has changed in the powershell client compared to bbwin. Personally I ignore eventlogs in the analysis.cfg on the xymon server rather the in client-local.cfg as you can use regex to match on eventid + Source rather than just the description. Regards, Brandon -----Original Message----- From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Colin Coe Sent: Monday, 14 December 2015 2:48 PM To: xymon at xymon.com Subject: [Xymon] clientconfig.cfg not getting updated Hi all I'm noticing that the Windows Powershell Xymon client isn't being updated to reflect changes in client-local.cfg. I had thought that changes on the Xymon server to client-local.cfg would result in changes on the Windows clients. Am I wrong here, and if so, what's the correct way to get these changes propagated out? I'm wanting the following to be pushed out to the clients: --- tail -n 2 /etc/xymon/client-local.cfg [os=powershell] clientversion:2.04:http://benmon1p.scada.horizonpower.com.au/pub/ --- clientlocal.cfg contains: --- eventlog:security ignore success ignore Success ignore "The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer" eventlog:system ignore "Contact the administrator to install the driver before you log in again" tssessions adreplicaton --- Thanks CC _______________________________________________ Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon From patrik_xymon at outlook.com Mon Dec 14 11:55:22 2015 From: patrik_xymon at outlook.com (Patrik Nussbaumer) Date: Mon, 14 Dec 2015 11:55:22 +0100 Subject: [Xymon] upgrade from BigBrother to Xymon In-Reply-To: References: Message-ID: Hal Xymon-Tam I have some more Questions about Xymon. Can I configure Xymon that he looks like the old BigBrother? I mean white Background color. Works Xymon on ubuntu server 14? best regards Patrik Nussbaumer Von: Josh Luthman [mailto:josh at imaginenetworksllc.com] Gesendet: Freitag, 11. Dezember 2015 15:20 An: Patrik Nussbaumer Cc: xymon at xymon.com Betreff: Re: [Xymon] upgrade from BigBrother to Xymon Yes Not really... Server would be best, though not necessary Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Dec 11, 2015 8:56 AM, "Patrik Nussbaumer" > wrote: Dear Xymon-Team I have some question about the Xymon Server. Can I upgrade from a BigBrother Server (Windows Server 2003) to a Xymon Server (UNIX)? Works Xymon on Windows Operating System (newer than Windows Server 2003)? Should I installing a ubuntu server version or will be ok when i installing ubuntu desktop version? Thanks for the answer best regards Patrik Nussbaumer _______________________________________________ Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon -------------- next part -------------- An HTML attachment was scrubbed... URL: From fclaire at free.fr Mon Dec 14 14:25:46 2015 From: fclaire at free.fr (Francois Claire) Date: Mon, 14 Dec 2015 14:25:46 +0100 Subject: [Xymon] Bug in findhost ? In-Reply-To: <8dd2adf972d9faadf7064987e2e0cfc2.squirrel@mail.kkytbs.net> References: <565FF8E3.90005@free.fr> <566AC90B.2090800@free.fr> <92be4d1c66607cb797c8eb3d0167fb4b.squirrel@mail.kkytbs.net> <8dd2adf972d9faadf7064987e2e0cfc2.squirrel@mail.kkytbs.net> Message-ID: <566EC35A.7000102@free.fr> Le 12/12/2015 21:11, J.C. Cleaver a écrit : > There are actually a few different issues here, which will warrant > slightly different solutions in 4.3.25 and 4.4x . The problem stems > from how we're loading the environment in for the CGI scripts, which > is slightly different than initscript-run xymonlaunch tasks or simply > using the xymoncmd command. As a quick fix, do one of: - ensure your > $XYMONWEBHOST variable in xymonserver.cfg is a statically assigned URL > part, and/or - ensure $XYMONSERVERHOSTNAME and $XYMONSERVERWWWNAME > variables are hard-coded to your server name, and/or - add a > "MACHINEDOTS=your.hostname.here" entry to cgioptions.cfg This will > also fix a display issue on the "info" page for hosts that have notes > configured (the link works, but the link text URL is wrong). HTH, -jc Allright, thanks for the workarounds. And thank you for working on it. Cheers, Francois. From patrik_xymon at outlook.com Mon Dec 14 15:59:15 2015 From: patrik_xymon at outlook.com (Patrik Nussbaumer) Date: Mon, 14 Dec 2015 15:59:15 +0100 Subject: [Xymon] upgrade from BigBrother to Xymon In-Reply-To: References: Message-ID: What can I make when the command doesn't work (with sudo it also doesnt work)? And I have not found a resolution about installing with a gui? Von: Patrik Nussbaumer [mailto:patrik_xymon at outlook.com] Gesendet: Freitag, 11. Dezember 2015 14:50 An: xymon at xymon.com Betreff: upgrade from BigBrother to Xymon Dear Xymon-Team I have some question about the Xymon Server. Can I upgrade from a BigBrother Server (Windows Server 2003) to a Xymon Server (UNIX)? Works Xymon on Windows Operating System (newer than Windows Server 2003)? Should I installing a ubuntu server version or will be ok when i installing ubuntu desktop version? Thanks for the answer best regards Patrik Nussbaumer -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Mon Dec 14 16:08:06 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 14 Dec 2015 10:08:06 -0500 Subject: [Xymon] upgrade from BigBrother to Xymon In-Reply-To: References:

Message-ID: There is no GUI installer. Are you using those weird characters with tar? What's the output when the command fails? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Dec 14, 2015 9:59 AM, "Patrik Nussbaumer" wrote: > What can I make when the command «tar zxf xymon-4.3.10.tar.gz» doesn’t > work (with sudo it also doesnt work)? > > And I have not found a resolution about installing with a gui? > > > > *Von:* Patrik Nussbaumer [mailto:patrik_xymon at outlook.com] > *Gesendet:* Freitag, 11. Dezember 2015 14:50 > *An:* xymon at xymon.com > *Betreff:* upgrade from BigBrother to Xymon > > > > Dear Xymon-Team > > > > I have some question about the Xymon Server. > > > > Can I upgrade from a BigBrother Server (Windows Server 2003) to a Xymon > Server (UNIX)? > > Works Xymon on Windows Operating System (newer than Windows Server 2003)? > > Should I installing a ubuntu server version or will be ok when i > installing ubuntu desktop version? > > > > Thanks for the answer > > > > best regards Patrik Nussbaumer > > > > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Paul.Root at CenturyLink.com Mon Dec 14 16:14:46 2015 From: Paul.Root at CenturyLink.com (Root, Paul T) Date: Mon, 14 Dec 2015 15:14:46 +0000 Subject: [Xymon] upgrade from BigBrother to Xymon In-Reply-To: References:

Message-ID: I'll have to make some guesses here, but first I need to say, you have to give us more to work on. I've been in support for a long time, and "it doesn't work" doesn't mean anything. What doesn't work? This is like calling the help desk and saying "The internet is down!". I've had that, usually pressing the cap locks key on the users keyboard fixes the issue. Give us something to work with: Does the command just hang and you have to kill it? It's pretty big, maybe you don't wait long enough. Did you try tar -xvf xymon-4.3.10.tar.gz? This will give you output so you can see the progress of the files unpacking. Does it end in an error? What's the error? Are you trying to untar it into a directory you don't have write access to? Perhaps an nfs share that to which root can't write? Is it possible to untar it in two steps. Gunzip xymon-4.3.10.tar and then tar -xvf xymon-4.3.10.tar? Why are you trying to build such an old version of xymon? How about getting the latest, or just 1 or 2 revisions back? Ultimately my best guess is you have a corrupt tar file or you have write issues on your local media. From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Patrik Nussbaumer Sent: Monday, December 14, 2015 8:59 AM To: xymon at xymon.com Subject: Re: [Xymon] upgrade from BigBrother to Xymon What can I make when the command doesn't work (with sudo it also doesnt work)? And I have not found a resolution about installing with a gui? Von: Patrik Nussbaumer [mailto:patrik_xymon at outlook.com] Gesendet: Freitag, 11. Dezember 2015 14:50 An: xymon at xymon.com Betreff: upgrade from BigBrother to Xymon Dear Xymon-Team I have some question about the Xymon Server. Can I upgrade from a BigBrother Server (Windows Server 2003) to a Xymon Server (UNIX)? Works Xymon on Windows Operating System (newer than Windows Server 2003)? Should I installing a ubuntu server version or will be ok when i installing ubuntu desktop version? Thanks for the answer best regards Patrik Nussbaumer This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas at lienard.name Mon Dec 14 18:24:10 2015 From: nicolas at lienard.name (Nico) Date: Mon, 14 Dec 2015 18:24:10 +0100 Subject: [Xymon] FreeBSD [ifstat] processing Message-ID: Hello Having same issue with my FreeBSD 10.2 devices, i tried this patch on server side but it was not matching successfully all the interfaces due to bad regular expression matching on the mac addresses part. # netstat -ibn | egrep " 00:22:4d:ad:fe:35 893691871 0 0 1135451821124 497735825 0 107868664606 0 pflog 33160 0 0 0 0 697354 0 69531302 0 tap0 1500 00:bd:c4:41:4e:00 448130087 0 0 584819922588 250814356 0 43739464436 0 bridg 1500 02:f7:58:d9:cb:00 0 0 0 0 0 0 0 0 vlan1 1496 00:bd:c4:41:4e:00 58827595 0 0 61939630719 46134046 3255 29559453921 0 vlan2 1300 00:bd:c4:41:4e:00 450450 0 0 34627817 456686 110 36271656 0 tap30 1500 00:bd:24:27:3a:1e 109129 0 0 7518832 171580 0 231138481 0 bridg 1500 02:f7:58:d9:cb:1e 0 0 0 0 0 0 0 0 vlan3 1496 00:bd:24:27:3a:1e 143 0 0 10409 73 0 3893 0 It was matching only pflog0 interface with the regexp where the mac address part is in bold : "^([a-z0-9]+)\\s+\\d+\\s+\\s+ //s+>[:0-9]+\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+[0-9- ]+" }; Here a functional one (in bold the replacement) rrd/do_ifstat.c [line 31] /* Name MTU Network IP Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll */ /* lnc0 1500 172.16.10.0/24 172.16.10.151 26 - 1818 26 - 1802 - */ static const char *ifstat_freebsd_exprs[] = { "^([a-z0-9]+)\\s+\\d+\\s+\\s+ //s+>[a-z0123456789.:]+\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+[0-9- ]+" }; The part on client is working fine. Thanks and long life to Xymon ! regards, Nico From: Xymon [mailto:xymon-bounces at xymon.com ] On Behalf Of Jeremy Laidman Sent: Thursday, 20 February 2014 1:46 PM To: xymon at xymon.com Subject: Re: [Xymon] FreeBSD [ifstat] processing On 17 February 2014 23:24, Jeremy Laidman >> wrote: On 17 February 2014 18:48, Jeremy Laidman >> wrote: For this reason, it seems to make sense that the "link" lines are probably the best for this, as I would think that they would show packets contained only in physical frames (ethernet or some other medium). So I'm proposing that the FreeBSD client be adjusted from this: echo "[ifstat]" netstat -i -b -n | egrep -v "^lo|>; D=0.0.0.0; }; printf "%-5s %5s %-13s %-17s %12s %6s %14s %14s %6s %14s %6s\n" $A $B $C $D $E $F $G; done The output now only includes interface lines with "" and MAC address lines have been replaced with dummy values that parse correctly on the server. I now have useful interface graphs for my FreeBSD systems. This is an ugly hack, and I only want this in place until a proper solution can be implemented. So, I'm proposing that the xymonclient-freebsd.sh script be modified to use this line for [ifstat]: netstat -ibn | egrep "> 172.16.10.151 26 - 1818 26 - 1802 - */ +/* Name MTU Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll */ +/* em0 1500 00:11:22:33:44:55 26 - 1818 26 - 1802 - */ static const char *ifstat_freebsd_exprs[] = { - "^([a-z0-9]+)\\s+\\d+\\s+[0-9.\\/]+\\s+[0-9.]+\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+ [0-9-)\s+\d+\s+%5b0-9-%5d+\s+(\d+)\s+%5b0-9->]+" + "^([a-z0-9]+)\\s+\\d+\\s+\\s+[:0-9]+\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+ //s+[:0-9]+//s+//d+//s+[0-9-]+//s+(//d+)//s+//d+//s+[0-9-]+//s+(//d+)//s+>[0-9-)\s+\d+\s+%5b0-9-%5d+\s+(\d+)\s+%5b0-9->]+" }; /* Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll */ ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dito74 at gmail.com Mon Dec 14 19:28:38 2015 From: dito74 at gmail.com (Dito) Date: Mon, 14 Dec 2015 13:28:38 -0500 Subject: [Xymon] upgrade from BigBrother to Xymon In-Reply-To: References:

Message-ID: if you don't know how to install it on Linux you can download a virtual machine here, already built, it's not the latest version of the OS, it's an old OS, but maybe it works for you http://www.squidworks.net/software-projects/mag/ Gab On Mon, Dec 14, 2015 at 10:14 AM, Root, Paul T wrote: > I’ll have to make some guesses here, but first I need to say, you have to > give us more to work on. I’ve been in support for a long time, and “it > doesn’t work” doesn’t mean anything. What doesn’t work? This is like > calling the help desk and saying “The internet is down!”. I’ve had that, > usually pressing the cap locks key on the users keyboard fixes the issue. > > > > Give us something to work with: > > Does the command just hang and you have to kill it? It’s pretty big, maybe > you don’t wait long enough. > > Did you try tar –xvf xymon-4.3.10.tar.gz? This will give you output so > you can see the progress of the files unpacking. > > Does it end in an error? What’s the error? > > Are you trying to untar it into a directory you don’t have write access > to? Perhaps an nfs share that to which root can’t write? > > Is it possible to untar it in two steps. Gunzip xymon-4.3.10.tar and then > tar –xvf xymon-4.3.10.tar? > > > > Why are you trying to build such an old version of xymon? How about > getting the latest, or just 1 or 2 revisions back? > > > > Ultimately my best guess is you have a corrupt tar file or you have write > issues on your local media. > > > > > > *From:* Xymon [mailto:xymon-bounces at xymon.com] *On Behalf Of *Patrik > Nussbaumer > *Sent:* Monday, December 14, 2015 8:59 AM > *To:* xymon at xymon.com > *Subject:* Re: [Xymon] upgrade from BigBrother to Xymon > > > > What can I make when the command «tar zxf xymon-4.3.10.tar.gz» doesn’t > work (with sudo it also doesnt work)? > > And I have not found a resolution about installing with a gui? > > > > *Von:* Patrik Nussbaumer [mailto:patrik_xymon at outlook.com > ] > *Gesendet:* Freitag, 11. Dezember 2015 14:50 > *An:* xymon at xymon.com > *Betreff:* upgrade from BigBrother to Xymon > > > > Dear Xymon-Team > > > > I have some question about the Xymon Server. > > > > Can I upgrade from a BigBrother Server (Windows Server 2003) to a Xymon > Server (UNIX)? > > Works Xymon on Windows Operating System (newer than Windows Server 2003)? > > Should I installing a ubuntu server version or will be ok when i > installing ubuntu desktop version? > > > > Thanks for the answer > > > > best regards Patrik Nussbaumer > > > This communication is the property of CenturyLink and may contain > confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the sender > by reply e-mail and destroy all copies of the communication and any > attachments. > > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Mon Dec 14 21:27:05 2015 From: john.thurston at alaska.gov (John Thurston) Date: Mon, 14 Dec 2015 11:27:05 -0900 Subject: [Xymon] alert/hostname loading In-Reply-To: <565E0B07.8090602@alaska.gov> References: <17082AAFC33A934082836458CB53494367323DD1@MONDB03.na.lzb.hq> <55E0C860.8020900@alaska.gov> <55E0DDA0.2070906@alaska.gov> <2a97f13340498d494247f361400f0249.squirrel@mail.kkytbs.net> <565DD56C.7060809@alaska.gov> <877291f035406a2f8d4f9a854fe3e158.squirrel@mail.kkytbs.net> <565E0B07.8090602@alaska.gov> Message-ID: <566F2619.1050501@alaska.gov> On 12/1/2015 12:03 PM, John Thurston wrote: > On 12/1/2015 11:48 AM, J.C. Cleaver wrote: > - snip - >> >> Hmm. This seems to be fundamentally a different issue than the "hostdata >> module going rogue" thing, which was about zombies never being picked up. >> >> AFAICT, somehow the hosts tree structure is getting clobbered as a result >> of the drop (assuming all of those hosts are expected to be existing). - snip - > I haven't yet found a way to induce this failure, so I haven't yet > identified the minimal recovery steps. I'm working on it, though. I think I might be able to reproduce the failure :) Start with the following, stable server arrangement: + x.bar.com is running xymon 4.3.22 on Solaris 10 SPARC + The following is defined in tasks.cfg: CMD xymond_channel --channel=page --log=$XYMONSERVERLOGS/alert.log \ xymond_alert --debug --checkpoint-file=$XYMONTMP/alert.chk \ --checkpoint-interval=600 + Host foo.bar.com is defined in DNS and does not permit ICMP traffic and does not have a xymon client installed on it Throw a spanner in the works by the following actions: + Add host foo.bar.com to an existing page and group in hosts.cfg + ~/server/bin/xymoncmd ~/server/bin/xymonnet foo.bar.com And see the trouble commence in alert.log: > 6690 2015-12-14 10:52:06.859998 Got 415 bytes > 6690 2015-12-14 10:52:06.860110 xymond_alert: Got message 95 @@page#95/foo.bar.com|1450122726.859873|10.10.10.55|foo.bar.com|conn|0.0.0.0|1450124526|red|none|1450122726|Page/Subpage|65234|||| > 6690 2015-12-14 10:52:06.860140 startpos 5659, fillpos 5659, endpos -1 > 6690 2015-12-14 10:52:06.860172 Got page message from foo.bar.com:conn > 6690 2015-12-14 10:52:06.860249 Alert status changed from 0 to 1 > 6690 2015-12-14 10:52:06.860285 Checking criteria for host 'foo.bar.com', which is not defined > 6690 2015-12-14 10:52:06.861674 Checking criteria for host 'foo.bar.com', which is not defined > 6690 2015-12-14 10:52:06.861728 Checking criteria for host 'foo.bar.com', which is not defined > 6690 2015-12-14 10:52:06.861761 Found no first matching rule > 6690 2015-12-14 10:52:06.861813 No files modified, skipping reload of /opt/xymon/server/etc/alerts.cfg > 6690 2015-12-14 10:52:06.861861 No files modified, skipping reload of /opt/xymon/server/etc/holidays.cfg > 6690 2015-12-14 10:52:06.861891 Checking criteria for host 'zebra.bar.com', which is not defined After killing the "xymond_channel --channel=page" process, a new one is created as a child of xymonlaunch and everything behaves normally again. I currently have a tail on my alert.log to warn me of the appearance of the string, "which is not defined". When that appears, I know it is time to HUP the "page" channel. This is a rather crude hammer to leave laying on the table next to my production server, but it keeps us running :) I have a core file from the xymond_channel process, but its stack contains only: > feee041c _syscall6 (1, 1, 0, 1, 7d0, 3a0f4) + 20 > 00013c90 _start (0, 0, 0, 0, 0, 0) + 5c I have a core file from the xymond_alert process, but its stack contains only: > feede7d8 __pollsys (ffbfcd50, 1, ffbfcdc0, 0, 0, 0) + 8 > fee79b8c pselect (ffbfcd50, fef56790, fef56790, 40, ffbfcdc0, 0) + 1c8 > fee79f04 select (1, ffbfce58, 0, 0, ffbfce48, ffbfced8) + a0 > 00015fa4 get_xymond_message (4b400, 4b14c, 4b148, ffbfcf88, 4b16c, 35d50) + 270 > 0003293c main (1, 566f245d, 0, 33b00, 4b000, 33bb8) + 378 > 00014a34 _start (0, 0, 0, 0, 0, 0) + 5c which is whatever it was happily processing when I killed it, not the stack at the time it ended up at line 815 of loadalerts.c What can I do and what information can I gather which will help narrow the fault domain? -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska From colin.coe at gmail.com Tue Dec 15 02:58:32 2015 From: colin.coe at gmail.com (Colin Coe) Date: Tue, 15 Dec 2015 09:58:32 +0800 Subject: [Xymon] clientconfig.cfg not getting updated In-Reply-To: <96BCCCBE6729EC4AA7F7806640317F4F268F43@KGexch01.kitchen-net.com.au> References: <96BCCCBE6729EC4AA7F7806640317F4F268F43@KGexch01.kitchen-net.com.au> Message-ID: Hi Brandon Thanks for the reply. Yep, read through the doco a couple of times now trying to get this working. 1. Yep, c:\program files\xymon\xymonclient_config.xml exists (and xymonclient.ps1 is in this directory) and contains: --- xxx.xx.106.11 xxx.xx.176.11 c:\xymonclient.log c:\program files\xymon\clientconfig.cfg 0 1 1 --- 2. On the server (RHEL6.7, Teribithia RPM 4.3.24), /etc/xymon/client-local.cfg contains: --- [powershell] clientversion:2.04:http://http.url.to.file/pub/ tssessions adreplicaton --- I've changed "[os=powershell]" to just "[powershell]" and removed all but the above (for the powershell client) 3. I've stopped/started the powershell client and waited for a while with no joy. I've confirmed that the clients can manually download the file. Not sure what I'm missing here... Thanks On Mon, Dec 14, 2015 at 12:30 PM, Brandon Dale wrote: > If you haven't already I would read through http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/XymonPSClient.doc it's pretty decent documentation. > > Try double checking this stuff: > > 1. Make sure you have copied the .xml file that contains the configuration for the client to the local machine into the same directory where the xymonclient.ps1 script lives http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/xymonclient_config.xml and that this contains a path for the client-local.cfg file and has clientremotecfgexec set to 1 (this is already done by default in the .xml file in that link) > > 2. Put your settings into the client-local.cfg file on your xymon server, I have put an example below, the valid commands are listed in XymonPSClient.doc > > [powershell] > eventlogswanted:*:250000:warning,critical,error > ifstat:ipv4 > clientversion:2.04:\\somepath\goes\here > > 3. Wait for or manually run the PowerShell client (by restarting the XymonPSClient Service in windows), you need to do this at least twice as the first time you run it, it will get the commands you have in your client-local.cfg file on your xymon server and write them to the clientconfig.cfg (or whatever you called it in the .xml file) the second time it runs it will start reading it. > > Note: make sure you read the documentation for the eventlog ignore rules, the syntax is different. You can still use the IGNORE PATTERN but the way you select which eventlogs to check has changed in the powershell client compared to bbwin. > > Personally I ignore eventlogs in the analysis.cfg on the xymon server rather the in client-local.cfg as you can use regex to match on eventid + Source rather than just the description. > > > Regards, > > > Brandon > > > > > -----Original Message----- > From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Colin Coe > Sent: Monday, 14 December 2015 2:48 PM > To: xymon at xymon.com > Subject: [Xymon] clientconfig.cfg not getting updated > > Hi all > > I'm noticing that the Windows Powershell Xymon client isn't being updated to reflect changes in client-local.cfg. I had thought that changes on the Xymon server to client-local.cfg would result in changes on the Windows clients. Am I wrong here, and if so, what's the correct way to get these changes propagated out? > > I'm wanting the following to be pushed out to the clients: > --- > tail -n 2 /etc/xymon/client-local.cfg > [os=powershell] > clientversion:2.04:http://benmon1p.scada.horizonpower.com.au/pub/ > --- > > clientlocal.cfg contains: > --- > eventlog:security > ignore success > ignore Success > ignore "The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer" > eventlog:system > ignore "Contact the administrator to install the driver before you log in again" > tssessions > adreplicaton > --- > > Thanks > > CC > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon From BDale at kitchengroup.com.au Tue Dec 15 06:12:21 2015 From: BDale at kitchengroup.com.au (Brandon Dale) Date: Tue, 15 Dec 2015 05:12:21 +0000 Subject: [Xymon] clientconfig.cfg not getting updated In-Reply-To: References: <96BCCCBE6729EC4AA7F7806640317F4F268F43@KGexch01.kitchen-net.com.au> Message-ID: <96BCCCBE6729EC4AA7F7806640317F4F26A78B@KGexch01.kitchen-net.com.au> It should be writing a log file when it runs c:\xymonclient.log, do you see that log file being written, does it contain any errors? And in xymon are you seeing any of the data make it to your xymon server, you should see all the data in the clientlog column. One thing I have done in the past when having issues is use xymonsend from http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/xymonsend.ps1 to confirm I can talk to the xymon server. You can dot source this into powershell and run something like XymonSend "config client-local.cfg" "xymonservername" > c:\temp\client-local.cfg At least then you can see if you can actually pull down the files on that server or not. Regards, Brandon -----Original Message----- From: Colin Coe [mailto:colin.coe at gmail.com] Sent: Tuesday, 15 December 2015 12:59 PM To: Brandon Dale Cc: xymon at xymon.com Subject: Re: [Xymon] clientconfig.cfg not getting updated Hi Brandon Thanks for the reply. Yep, read through the doco a couple of times now trying to get this working. 1. Yep, c:\program files\xymon\xymonclient_config.xml exists (and xymonclient.ps1 is in this directory) and contains: --- xxx.xx.106.11 xxx.xx.176.11 c:\xymonclient.log c:\program files\xymon\clientconfig.cfg 0 1 1 --- 2. On the server (RHEL6.7, Teribithia RPM 4.3.24), /etc/xymon/client-local.cfg contains: --- [powershell] clientversion:2.04:http://http.url.to.file/pub/ tssessions adreplicaton --- I've changed "[os=powershell]" to just "[powershell]" and removed all but the above (for the powershell client) 3. I've stopped/started the powershell client and waited for a while with no joy. I've confirmed that the clients can manually download the file. Not sure what I'm missing here... Thanks On Mon, Dec 14, 2015 at 12:30 PM, Brandon Dale wrote: > If you haven't already I would read through http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/XymonPSClient.doc it's pretty decent documentation. > > Try double checking this stuff: > > 1. Make sure you have copied the .xml file that contains the > configuration for the client to the local machine into the same > directory where the xymonclient.ps1 script lives > http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/xymo > nclient_config.xml and that this contains a path for the > client-local.cfg file and has clientremotecfgexec set to 1 (this is > already done by default in the .xml file in that link) > > 2. Put your settings into the client-local.cfg file on your xymon > server, I have put an example below, the valid commands are listed in > XymonPSClient.doc > > [powershell] > eventlogswanted:*:250000:warning,critical,error > ifstat:ipv4 > clientversion:2.04:\\somepath\goes\here > > 3. Wait for or manually run the PowerShell client (by restarting the XymonPSClient Service in windows), you need to do this at least twice as the first time you run it, it will get the commands you have in your client-local.cfg file on your xymon server and write them to the clientconfig.cfg (or whatever you called it in the .xml file) the second time it runs it will start reading it. > > Note: make sure you read the documentation for the eventlog ignore rules, the syntax is different. You can still use the IGNORE PATTERN but the way you select which eventlogs to check has changed in the powershell client compared to bbwin. > > Personally I ignore eventlogs in the analysis.cfg on the xymon server rather the in client-local.cfg as you can use regex to match on eventid + Source rather than just the description. > > > Regards, > > > Brandon > > > > > -----Original Message----- > From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Colin Coe > Sent: Monday, 14 December 2015 2:48 PM > To: xymon at xymon.com > Subject: [Xymon] clientconfig.cfg not getting updated > > Hi all > > I'm noticing that the Windows Powershell Xymon client isn't being updated to reflect changes in client-local.cfg. I had thought that changes on the Xymon server to client-local.cfg would result in changes on the Windows clients. Am I wrong here, and if so, what's the correct way to get these changes propagated out? > > I'm wanting the following to be pushed out to the clients: > --- > tail -n 2 /etc/xymon/client-local.cfg > [os=powershell] > clientversion:2.04:http://benmon1p.scada.horizonpower.com.au/pub/ > --- > > clientlocal.cfg contains: > --- > eventlog:security > ignore success > ignore Success > ignore "The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer" > eventlog:system > ignore "Contact the administrator to install the driver before you log in again" > tssessions > adreplicaton > --- > > Thanks > > CC > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon From colin.coe at gmail.com Tue Dec 15 07:47:18 2015 From: colin.coe at gmail.com (Colin Coe) Date: Tue, 15 Dec 2015 14:47:18 +0800 Subject: [Xymon] clientconfig.cfg not getting updated In-Reply-To: <96BCCCBE6729EC4AA7F7806640317F4F26A78B@KGexch01.kitchen-net.com.au> References: <96BCCCBE6729EC4AA7F7806640317F4F268F43@KGexch01.kitchen-net.com.au> <96BCCCBE6729EC4AA7F7806640317F4F26A78B@KGexch01.kitchen-net.com.au> Message-ID: HI Brandon I appreciate your help with this. The log file (c:\xymonclient.log) is being written to and I can see "Using new remote config, saving locally" however the clientconfig.cfg while the files time stamp updates, the content doesn't change. I ended up putting that section of code in a try catch block but no error was generated. Doing the XymonSend resulted in the whole file being downloaded being downloaded from the Xymon server. I've done the Windows equiv of chmod 777 on the client-local.cfg to run out permission problems. It looks On Tue, Dec 15, 2015 at 1:12 PM, Brandon Dale wrote: > It should be writing a log file when it runs c:\xymonclient.log, do you see that log file being written, does it contain any errors? > And in xymon are you seeing any of the data make it to your xymon server, you should see all the data in the clientlog column. > > > One thing I have done in the past when having issues is use xymonsend from http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/xymonsend.ps1 to confirm I can talk to the xymon server. You can dot source this into powershell and run something like > > XymonSend "config client-local.cfg" "xymonservername" > c:\temp\client-local.cfg > > At least then you can see if you can actually pull down the files on that server or not. > > Regards, > > > Brandon > > > -----Original Message----- > From: Colin Coe [mailto:colin.coe at gmail.com] > Sent: Tuesday, 15 December 2015 12:59 PM > To: Brandon Dale > Cc: xymon at xymon.com > Subject: Re: [Xymon] clientconfig.cfg not getting updated > > Hi Brandon > > Thanks for the reply. > > Yep, read through the doco a couple of times now trying to get this working. > > 1. Yep, c:\program files\xymon\xymonclient_config.xml exists (and > xymonclient.ps1 is in this directory) and contains: > --- > > > xxx.xx.106.11 xxx.xx.176.11 > > c:\xymonclient.log > c:\program files\xymon\clientconfig.cfg > > 0 > 1 > > 1 > > --- > > 2. On the server (RHEL6.7, Teribithia RPM 4.3.24), /etc/xymon/client-local.cfg contains: > --- > [powershell] > clientversion:2.04:http://http.url.to.file/pub/ > tssessions > adreplicaton > --- > > I've changed "[os=powershell]" to just "[powershell]" and removed all but the above (for the powershell client) > > 3. I've stopped/started the powershell client and waited for a while with no joy. > > I've confirmed that the clients can manually download the file. > > Not sure what I'm missing here... > > Thanks > > On Mon, Dec 14, 2015 at 12:30 PM, Brandon Dale wrote: >> If you haven't already I would read through http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/XymonPSClient.doc it's pretty decent documentation. >> >> Try double checking this stuff: >> >> 1. Make sure you have copied the .xml file that contains the >> configuration for the client to the local machine into the same >> directory where the xymonclient.ps1 script lives >> http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/xymo >> nclient_config.xml and that this contains a path for the >> client-local.cfg file and has clientremotecfgexec set to 1 (this is >> already done by default in the .xml file in that link) >> >> 2. Put your settings into the client-local.cfg file on your xymon >> server, I have put an example below, the valid commands are listed in >> XymonPSClient.doc >> >> [powershell] >> eventlogswanted:*:250000:warning,critical,error >> ifstat:ipv4 >> clientversion:2.04:\\somepath\goes\here >> >> 3. Wait for or manually run the PowerShell client (by restarting the XymonPSClient Service in windows), you need to do this at least twice as the first time you run it, it will get the commands you have in your client-local.cfg file on your xymon server and write them to the clientconfig.cfg (or whatever you called it in the .xml file) the second time it runs it will start reading it. >> >> Note: make sure you read the documentation for the eventlog ignore rules, the syntax is different. You can still use the IGNORE PATTERN but the way you select which eventlogs to check has changed in the powershell client compared to bbwin. >> >> Personally I ignore eventlogs in the analysis.cfg on the xymon server rather the in client-local.cfg as you can use regex to match on eventid + Source rather than just the description. >> >> >> Regards, >> >> >> Brandon >> >> >> >> >> -----Original Message----- >> From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Colin Coe >> Sent: Monday, 14 December 2015 2:48 PM >> To: xymon at xymon.com >> Subject: [Xymon] clientconfig.cfg not getting updated >> >> Hi all >> >> I'm noticing that the Windows Powershell Xymon client isn't being updated to reflect changes in client-local.cfg. I had thought that changes on the Xymon server to client-local.cfg would result in changes on the Windows clients. Am I wrong here, and if so, what's the correct way to get these changes propagated out? >> >> I'm wanting the following to be pushed out to the clients: >> --- >> tail -n 2 /etc/xymon/client-local.cfg >> [os=powershell] >> clientversion:2.04:http://benmon1p.scada.horizonpower.com.au/pub/ >> --- >> >> clientlocal.cfg contains: >> --- >> eventlog:security >> ignore success >> ignore Success >> ignore "The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer" >> eventlog:system >> ignore "Contact the administrator to install the driver before you log in again" >> tssessions >> adreplicaton >> --- >> >> Thanks >> >> CC >> _______________________________________________ >> Xymon mailing list >> Xymon at xymon.com >> http://lists.xymon.com/mailman/listinfo/xymon From colin.coe at gmail.com Tue Dec 15 08:04:04 2015 From: colin.coe at gmail.com (Colin Coe) Date: Tue, 15 Dec 2015 15:04:04 +0800 Subject: [Xymon] clientconfig.cfg not getting updated In-Reply-To: References: <96BCCCBE6729EC4AA7F7806640317F4F268F43@KGexch01.kitchen-net.com.au> <96BCCCBE6729EC4AA7F7806640317F4F26A78B@KGexch01.kitchen-net.com.au> Message-ID: OK, by adding heaps of debug "WriteLog"s, I believe I've found the problem. Version 2.04 of the script. 2474 function XymonClientConfig($cfglines) 2475 { 2476 if ($cfglines -eq $null -or $cfglines -eq "") { return } 2477 WriteLog "DEBUG - " + $cfglines The above prints "DEBUG - " and nothing more, which tells me that it is not successfully talking to the server. The XymonSend function worked though... On Tue, Dec 15, 2015 at 2:47 PM, Colin Coe wrote: > HI Brandon > > I appreciate your help with this. > > The log file (c:\xymonclient.log) is being written to and I can see > "Using new remote config, saving locally" however the clientconfig.cfg > while the files time stamp updates, the content doesn't change. I > ended up putting that section of code in a try catch block but no > error was generated. > > Doing the XymonSend resulted in the whole file being downloaded being > downloaded from the Xymon server. > > I've done the Windows equiv of chmod 777 on the client-local.cfg to > run out permission problems. > > It looks > > On Tue, Dec 15, 2015 at 1:12 PM, Brandon Dale > wrote: > > It should be writing a log file when it runs c:\xymonclient.log, do you > see that log file being written, does it contain any errors? > > And in xymon are you seeing any of the data make it to your xymon > server, you should see all the data in the clientlog column. > > > > > > One thing I have done in the past when having issues is use xymonsend > from > http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/xymonsend.ps1 > to confirm I can talk to the xymon server. You can dot source this into > powershell and run something like > > > > XymonSend "config client-local.cfg" "xymonservername" > > c:\temp\client-local.cfg > > > > At least then you can see if you can actually pull down the files on > that server or not. > > > > Regards, > > > > > > Brandon > > > > > > -----Original Message----- > > From: Colin Coe [mailto:colin.coe at gmail.com] > > Sent: Tuesday, 15 December 2015 12:59 PM > > To: Brandon Dale > > Cc: xymon at xymon.com > > Subject: Re: [Xymon] clientconfig.cfg not getting updated > > > > Hi Brandon > > > > Thanks for the reply. > > > > Yep, read through the doco a couple of times now trying to get this > working. > > > > 1. Yep, c:\program files\xymon\xymonclient_config.xml exists (and > > xymonclient.ps1 is in this directory) and contains: > > --- > > > > > > xxx.xx.106.11 xxx.xx.176.11 > > > > c:\xymonclient.log > > c:\program > files\xymon\clientconfig.cfg > > > > 0 > > 1 > > > > 1 > > > > --- > > > > 2. On the server (RHEL6.7, Teribithia RPM 4.3.24), > /etc/xymon/client-local.cfg contains: > > --- > > [powershell] > > clientversion:2.04:http://http.url.to.file/pub/ > > tssessions > > adreplicaton > > --- > > > > I've changed "[os=powershell]" to just "[powershell]" and removed all > but the above (for the powershell client) > > > > 3. I've stopped/started the powershell client and waited for a while > with no joy. > > > > I've confirmed that the clients can manually download the file. > > > > Not sure what I'm missing here... > > > > Thanks > > > > On Mon, Dec 14, 2015 at 12:30 PM, Brandon Dale < > BDale at kitchengroup.com.au> wrote: > >> If you haven't already I would read through > http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/XymonPSClient.doc > it's pretty decent documentation. > >> > >> Try double checking this stuff: > >> > >> 1. Make sure you have copied the .xml file that contains the > >> configuration for the client to the local machine into the same > >> directory where the xymonclient.ps1 script lives > >> http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/xymo > >> nclient_config.xml and that this contains a path for the > >> client-local.cfg file and has clientremotecfgexec set to 1 (this is > >> already done by default in the .xml file in that link) > >> > >> 2. Put your settings into the client-local.cfg file on your xymon > >> server, I have put an example below, the valid commands are listed in > >> XymonPSClient.doc > >> > >> [powershell] > >> eventlogswanted:*:250000:warning,critical,error > >> ifstat:ipv4 > >> clientversion:2.04:\\somepath\goes\here > >> > >> 3. Wait for or manually run the PowerShell client (by restarting the > XymonPSClient Service in windows), you need to do this at least twice as > the first time you run it, it will get the commands you have in your > client-local.cfg file on your xymon server and write them to the > clientconfig.cfg (or whatever you called it in the .xml file) the second > time it runs it will start reading it. > >> > >> Note: make sure you read the documentation for the eventlog ignore > rules, the syntax is different. You can still use the IGNORE PATTERN but > the way you select which eventlogs to check has changed in the powershell > client compared to bbwin. > >> > >> Personally I ignore eventlogs in the analysis.cfg on the xymon server > rather the in client-local.cfg as you can use regex to match on eventid + > Source rather than just the description. > >> > >> > >> Regards, > >> > >> > >> Brandon > >> > >> > >> > >> > >> -----Original Message----- > >> From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Colin Coe > >> Sent: Monday, 14 December 2015 2:48 PM > >> To: xymon at xymon.com > >> Subject: [Xymon] clientconfig.cfg not getting updated > >> > >> Hi all > >> > >> I'm noticing that the Windows Powershell Xymon client isn't being > updated to reflect changes in client-local.cfg. I had thought that changes > on the Xymon server to client-local.cfg would result in changes on the > Windows clients. Am I wrong here, and if so, what's the correct way to get > these changes propagated out? > >> > >> I'm wanting the following to be pushed out to the clients: > >> --- > >> tail -n 2 /etc/xymon/client-local.cfg > >> [os=powershell] > >> clientversion:2.04:http://benmon1p.scada.horizonpower.com.au/pub/ > >> --- > >> > >> clientlocal.cfg contains: > >> --- > >> eventlog:security > >> ignore success > >> ignore Success > >> ignore "The local computer may not have the necessary registry > information or message DLL files to display messages from a remote computer" > >> eventlog:system > >> ignore "Contact the administrator to install the driver before you log > in again" > >> tssessions > >> adreplicaton > >> --- > >> > >> Thanks > >> > >> CC > >> _______________________________________________ > >> Xymon mailing list > >> Xymon at xymon.com > >> http://lists.xymon.com/mailman/listinfo/xymon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From BDale at kitchengroup.com.au Tue Dec 15 08:15:11 2015 From: BDale at kitchengroup.com.au (Brandon Dale) Date: Tue, 15 Dec 2015 07:15:11 +0000 Subject: [Xymon] clientconfig.cfg not getting updated In-Reply-To: References: <96BCCCBE6729EC4AA7F7806640317F4F268F43@KGexch01.kitchen-net.com.au> <96BCCCBE6729EC4AA7F7806640317F4F26A78B@KGexch01.kitchen-net.com.au>

Message-ID: <96BCCCBE6729EC4AA7F7806640317F4F2811AF@KGexch01.kitchen-net.com.au> Might be this xxx.xx.106.11 xxx.xx.176.11 then I know you can have more than 1 server here but I don’t know the syntax just double check this, maybe try with just a single server listed here. Regards, Brandon. From: Colin Coe [mailto:colin.coe at gmail.com] Sent: Tuesday, 15 December 2015 6:04 PM To: Brandon Dale Cc: xymon at xymon.com Subject: Re: [Xymon] clientconfig.cfg not getting updated OK, by adding heaps of debug "WriteLog"s, I believe I've found the problem. Version 2.04 of the script. 2474 function XymonClientConfig($cfglines) 2475 { 2476 if ($cfglines -eq $null -or $cfglines -eq "") { return } 2477 WriteLog "DEBUG - " + $cfglines The above prints "DEBUG - " and nothing more, which tells me that it is not successfully talking to the server. The XymonSend function worked though... On Tue, Dec 15, 2015 at 2:47 PM, Colin Coe > wrote: HI Brandon I appreciate your help with this. The log file (c:\xymonclient.log) is being written to and I can see "Using new remote config, saving locally" however the clientconfig.cfg while the files time stamp updates, the content doesn't change. I ended up putting that section of code in a try catch block but no error was generated. Doing the XymonSend resulted in the whole file being downloaded being downloaded from the Xymon server. I've done the Windows equiv of chmod 777 on the client-local.cfg to run out permission problems. It looks On Tue, Dec 15, 2015 at 1:12 PM, Brandon Dale > wrote: > It should be writing a log file when it runs c:\xymonclient.log, do you see that log file being written, does it contain any errors? > And in xymon are you seeing any of the data make it to your xymon server, you should see all the data in the clientlog column. > > > One thing I have done in the past when having issues is use xymonsend from http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/xymonsend.ps1 to confirm I can talk to the xymon server. You can dot source this into powershell and run something like > > XymonSend "config client-local.cfg" "xymonservername" > c:\temp\client-local.cfg > > At least then you can see if you can actually pull down the files on that server or not. > > Regards, > > > Brandon > > > -----Original Message----- > From: Colin Coe [mailto:colin.coe at gmail.com] > Sent: Tuesday, 15 December 2015 12:59 PM > To: Brandon Dale > Cc: xymon at xymon.com > Subject: Re: [Xymon] clientconfig.cfg not getting updated > > Hi Brandon > > Thanks for the reply. > > Yep, read through the doco a couple of times now trying to get this working. > > 1. Yep, c:\program files\xymon\xymonclient_config.xml exists (and > xymonclient.ps1 is in this directory) and contains: > --- > > > xxx.xx.106.11 xxx.xx.176.11 > > c:\xymonclient.log > c:\program files\xymon\clientconfig.cfg > > 0 > 1 > > 1 > > --- > > 2. On the server (RHEL6.7, Teribithia RPM 4.3.24), /etc/xymon/client-local.cfg contains: > --- > [powershell] > clientversion:2.04:http://http.url.to.file/pub/ > tssessions > adreplicaton > --- > > I've changed "[os=powershell]" to just "[powershell]" and removed all but the above (for the powershell client) > > 3. I've stopped/started the powershell client and waited for a while with no joy. > > I've confirmed that the clients can manually download the file. > > Not sure what I'm missing here... > > Thanks > > On Mon, Dec 14, 2015 at 12:30 PM, Brandon Dale > wrote: >> If you haven't already I would read through http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/XymonPSClient.doc it's pretty decent documentation. >> >> Try double checking this stuff: >> >> 1. Make sure you have copied the .xml file that contains the >> configuration for the client to the local machine into the same >> directory where the xymonclient.ps1 script lives >> http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/xymo >> nclient_config.xml and that this contains a path for the >> client-local.cfg file and has clientremotecfgexec set to 1 (this is >> already done by default in the .xml file in that link) >> >> 2. Put your settings into the client-local.cfg file on your xymon >> server, I have put an example below, the valid commands are listed in >> XymonPSClient.doc >> >> [powershell] >> eventlogswanted:*:250000:warning,critical,error >> ifstat:ipv4 >> clientversion:2.04:\\somepath\goes\here >> >> 3. Wait for or manually run the PowerShell client (by restarting the XymonPSClient Service in windows), you need to do this at least twice as the first time you run it, it will get the commands you have in your client-local.cfg file on your xymon server and write them to the clientconfig.cfg (or whatever you called it in the .xml file) the second time it runs it will start reading it. >> >> Note: make sure you read the documentation for the eventlog ignore rules, the syntax is different. You can still use the IGNORE PATTERN but the way you select which eventlogs to check has changed in the powershell client compared to bbwin. >> >> Personally I ignore eventlogs in the analysis.cfg on the xymon server rather the in client-local.cfg as you can use regex to match on eventid + Source rather than just the description. >> >> >> Regards, >> >> >> Brandon >> >> >> >> >> -----Original Message----- >> From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Colin Coe >> Sent: Monday, 14 December 2015 2:48 PM >> To: xymon at xymon.com >> Subject: [Xymon] clientconfig.cfg not getting updated >> >> Hi all >> >> I'm noticing that the Windows Powershell Xymon client isn't being updated to reflect changes in client-local.cfg. I had thought that changes on the Xymon server to client-local.cfg would result in changes on the Windows clients. Am I wrong here, and if so, what's the correct way to get these changes propagated out? >> >> I'm wanting the following to be pushed out to the clients: >> --- >> tail -n 2 /etc/xymon/client-local.cfg >> [os=powershell] >> clientversion:2.04:http://benmon1p.scada.horizonpower.com.au/pub/ >> --- >> >> clientlocal.cfg contains: >> --- >> eventlog:security >> ignore success >> ignore Success >> ignore "The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer" >> eventlog:system >> ignore "Contact the administrator to install the driver before you log in again" >> tssessions >> adreplicaton >> --- >> >> Thanks >> >> CC >> _______________________________________________ >> Xymon mailing list >> Xymon at xymon.com >> http://lists.xymon.com/mailman/listinfo/xymon -------------- next part -------------- An HTML attachment was scrubbed... URL: From colin.coe at gmail.com Tue Dec 15 08:16:47 2015 From: colin.coe at gmail.com (Colin Coe) Date: Tue, 15 Dec 2015 15:16:47 +0800 Subject: [Xymon] clientconfig.cfg not getting updated In-Reply-To: <96BCCCBE6729EC4AA7F7806640317F4F2811AF@KGexch01.kitchen-net.com.au> References: <96BCCCBE6729EC4AA7F7806640317F4F268F43@KGexch01.kitchen-net.com.au> <96BCCCBE6729EC4AA7F7806640317F4F26A78B@KGexch01.kitchen-net.com.au>

<96BCCCBE6729EC4AA7F7806640317F4F2811AF@KGexch01.kitchen-net.com.au> Message-ID: Yep, did this but forgot to include it in the list of things tried. On Tue, Dec 15, 2015 at 3:15 PM, Brandon Dale wrote: > Might be this xxx.xx.106.11 xxx.xx.176.11 then > > I know you can have more than 1 server here but I don’t know the syntax > just double check this, maybe try with just a single server listed here. > > > > Regards, > > > > Brandon. > > > > *From:* Colin Coe [mailto:colin.coe at gmail.com] > *Sent:* Tuesday, 15 December 2015 6:04 PM > *To:* Brandon Dale > > *Cc:* xymon at xymon.com > *Subject:* Re: [Xymon] clientconfig.cfg not getting updated > > > > OK, by adding heaps of debug "WriteLog"s, I believe I've found the problem. > > Version 2.04 of the script. > > 2474 function XymonClientConfig($cfglines) > 2475 { > 2476 if ($cfglines -eq $null -or $cfglines -eq "") { return } > 2477 WriteLog "DEBUG - " + $cfglines > > > > > > The above prints "DEBUG - " and nothing more, which tells me that it is > not successfully talking to the server. > > > > The XymonSend function worked though... > > > > > > On Tue, Dec 15, 2015 at 2:47 PM, Colin Coe wrote: > > HI Brandon > > I appreciate your help with this. > > The log file (c:\xymonclient.log) is being written to and I can see > "Using new remote config, saving locally" however the clientconfig.cfg > while the files time stamp updates, the content doesn't change. I > ended up putting that section of code in a try catch block but no > error was generated. > > Doing the XymonSend resulted in the whole file being downloaded being > downloaded from the Xymon server. > > I've done the Windows equiv of chmod 777 on the client-local.cfg to > run out permission problems. > > It looks > > > On Tue, Dec 15, 2015 at 1:12 PM, Brandon Dale > wrote: > > It should be writing a log file when it runs c:\xymonclient.log, do you > see that log file being written, does it contain any errors? > > And in xymon are you seeing any of the data make it to your xymon > server, you should see all the data in the clientlog column. > > > > > > One thing I have done in the past when having issues is use xymonsend > from > http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/xymonsend.ps1 > to confirm I can talk to the xymon server. You can dot source this into > powershell and run something like > > > > XymonSend "config client-local.cfg" "xymonservername" > > c:\temp\client-local.cfg > > > > At least then you can see if you can actually pull down the files on > that server or not. > > > > Regards, > > > > > > Brandon > > > > > > -----Original Message----- > > From: Colin Coe [mailto:colin.coe at gmail.com] > > Sent: Tuesday, 15 December 2015 12:59 PM > > To: Brandon Dale > > Cc: xymon at xymon.com > > Subject: Re: [Xymon] clientconfig.cfg not getting updated > > > > Hi Brandon > > > > Thanks for the reply. > > > > Yep, read through the doco a couple of times now trying to get this > working. > > > > 1. Yep, c:\program files\xymon\xymonclient_config.xml exists (and > > xymonclient.ps1 is in this directory) and contains: > > --- > > > > > > xxx.xx.106.11 xxx.xx.176.11 > > > > c:\xymonclient.log > > c:\program > files\xymon\clientconfig.cfg > > > > 0 > > 1 > > > > 1 > > > > --- > > > > 2. On the server (RHEL6.7, Teribithia RPM 4.3.24), > /etc/xymon/client-local.cfg contains: > > --- > > [powershell] > > clientversion:2.04:http://http.url.to.file/pub/ > > tssessions > > adreplicaton > > --- > > > > I've changed "[os=powershell]" to just "[powershell]" and removed all > but the above (for the powershell client) > > > > 3. I've stopped/started the powershell client and waited for a while > with no joy. > > > > I've confirmed that the clients can manually download the file. > > > > Not sure what I'm missing here... > > > > Thanks > > > > On Mon, Dec 14, 2015 at 12:30 PM, Brandon Dale < > BDale at kitchengroup.com.au> wrote: > >> If you haven't already I would read through > http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/XymonPSClient.doc > it's pretty decent documentation. > >> > >> Try double checking this stuff: > >> > >> 1. Make sure you have copied the .xml file that contains the > >> configuration for the client to the local machine into the same > >> directory where the xymonclient.ps1 script lives > >> http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/xymo > >> nclient_config.xml and that this contains a path for the > >> client-local.cfg file and has clientremotecfgexec set to 1 (this is > >> already done by default in the .xml file in that link) > >> > >> 2. Put your settings into the client-local.cfg file on your xymon > >> server, I have put an example below, the valid commands are listed in > >> XymonPSClient.doc > >> > >> [powershell] > >> eventlogswanted:*:250000:warning,critical,error > >> ifstat:ipv4 > >> clientversion:2.04:\\somepath\goes\here > >> > >> 3. Wait for or manually run the PowerShell client (by restarting the > XymonPSClient Service in windows), you need to do this at least twice as > the first time you run it, it will get the commands you have in your > client-local.cfg file on your xymon server and write them to the > clientconfig.cfg (or whatever you called it in the .xml file) the second > time it runs it will start reading it. > >> > >> Note: make sure you read the documentation for the eventlog ignore > rules, the syntax is different. You can still use the IGNORE PATTERN but > the way you select which eventlogs to check has changed in the powershell > client compared to bbwin. > >> > >> Personally I ignore eventlogs in the analysis.cfg on the xymon server > rather the in client-local.cfg as you can use regex to match on eventid + > Source rather than just the description. > >> > >> > >> Regards, > >> > >> > >> Brandon > >> > >> > >> > >> > >> -----Original Message----- > >> From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Colin Coe > >> Sent: Monday, 14 December 2015 2:48 PM > >> To: xymon at xymon.com > >> Subject: [Xymon] clientconfig.cfg not getting updated > >> > >> Hi all > >> > >> I'm noticing that the Windows Powershell Xymon client isn't being > updated to reflect changes in client-local.cfg. I had thought that changes > on the Xymon server to client-local.cfg would result in changes on the > Windows clients. Am I wrong here, and if so, what's the correct way to get > these changes propagated out? > >> > >> I'm wanting the following to be pushed out to the clients: > >> --- > >> tail -n 2 /etc/xymon/client-local.cfg > >> [os=powershell] > >> clientversion:2.04:http://benmon1p.scada.horizonpower.com.au/pub/ > >> --- > >> > >> clientlocal.cfg contains: > >> --- > >> eventlog:security > >> ignore success > >> ignore Success > >> ignore "The local computer may not have the necessary registry > information or message DLL files to display messages from a remote computer" > >> eventlog:system > >> ignore "Contact the administrator to install the driver before you log > in again" > >> tssessions > >> adreplicaton > >> --- > >> > >> Thanks > >> > >> CC > >> _______________________________________________ > >> Xymon mailing list > >> Xymon at xymon.com > >> http://lists.xymon.com/mailman/listinfo/xymon > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas at lienard.name Tue Dec 15 09:19:59 2015 From: nicolas at lienard.name (Nico) Date: Tue, 15 Dec 2015 09:19:59 +0100 Subject: [Xymon] FreeBSD [ifstat] processing In-Reply-To: References: Message-ID: <94E3A6B5-0993-4598-805E-926910A2F728@lienard.name> Sorry my mail was sent to early. There were also a missing column on the initial regexp. here the good one: --- do_ifstat.c 2015-10-01 16:42:42.000000000 +0200 +++ /root/do_ifstat.c.fix.freebsd.ifstat 2015-12-15 09:16:38.584712442 +0100 @@ -28,7 +28,7 @@ /* Name MTU Network IP Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll */ /* lnc0 1500 172.16.10.0/24 172.16.10.151 26 - 1818 26 - 1802 - */ static const char *ifstat_freebsd_exprs[] = { - "^([a-z0-9]+)\\s+\\d+\\s+[0-9.\\/]+\\s+[0-9.]+\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+[0-9- ]+" + "^([a-z0-9]+)\\s+\\d+\\s+\\s+[a-f0123456789.:]+\\s+\\d+\\s+[0-9-]+\\s+[0-9-]+\\s+(\\d+)\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+[0-9- //s+[a-f0123456789.:]+//s+//d+//s+[0-9-]+//s+[0-9-]+//s+(//d+)//s+//d+//s+[0-9-]+//s+(//d+)//s+[0-9->]+" }; /* Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll */ Now ifstat graphs are OK on my FreeBSD boxes. regards Nico > Le 14 déc. 2015 à 18:24, Nico > a écrit : > > Hello > > Having same issue with my FreeBSD 10.2 devices, i tried this patch on server side but it was not matching successfully all the interfaces due to bad regular expression matching on the mac addresses part. > > # netstat -ibn | egrep " Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll > em0 1500 00:22:4d:ad:fe:35 893691871 0 0 1135451821124 497735825 0 107868664606 0 > pflog 33160 0 0 0 0 697354 0 69531302 0 > tap0 1500 00:bd:c4:41:4e:00 448130087 0 0 584819922588 250814356 0 43739464436 0 > bridg 1500 02:f7:58:d9:cb:00 0 0 0 0 0 0 0 0 > vlan1 1496 00:bd:c4:41:4e:00 58827595 0 0 61939630719 46134046 3255 29559453921 0 > vlan2 1300 00:bd:c4:41:4e:00 450450 0 0 34627817 456686 110 36271656 0 > tap30 1500 00:bd:24:27:3a:1e 109129 0 0 7518832 171580 0 231138481 0 > bridg 1500 02:f7:58:d9:cb:1e 0 0 0 0 0 0 0 0 > vlan3 1496 00:bd:24:27:3a:1e 143 0 0 10409 73 0 3893 0 > > It was matching only pflog0 interface with the regexp where the mac address part is in bold : > > "^([a-z0-9]+)\\s+\\d+\\s+\\s+ //s+>[:0-9]+\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+[0-9- ]+" > }; > > Here a functional one (in bold the replacement) > > rrd/do_ifstat.c [line 31] > > /* Name MTU Network IP Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll */ > /* lnc0 1500 172.16.10.0/24 172.16.10.151 26 - 1818 26 - 1802 - */ > static const char *ifstat_freebsd_exprs[] = { > "^([a-z0-9]+)\\s+\\d+\\s+\\s+ //s+>[a-z0123456789.:]+\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+[0-9- ]+" > }; > > The part on client is working fine. > > Thanks and long life to Xymon ! > > > regards, > > Nico > > > > From: Xymon [mailto:xymon-bounces at xymon.com ] On Behalf Of Jeremy Laidman > Sent: Thursday, 20 February 2014 1:46 PM > To: xymon at xymon.com > Subject: Re: [Xymon] FreeBSD [ifstat] processing > > On 17 February 2014 23:24, Jeremy Laidman >> wrote: > On 17 February 2014 18:48, Jeremy Laidman >> wrote: > For this reason, it seems to make sense that the "link" lines are probably the best for this, as I would think that they would show packets contained only in physical frames (ethernet or some other medium). > > So I'm proposing that the FreeBSD client be adjusted from this: > > echo "[ifstat]" > netstat -i -b -n | egrep -v "^lo| > To this: > > echo "[ifstat]" > netstat -i -b -n | egrep " > Seem reasonable? Would anyone be adversely impacted by this suggested change? > > Anyone? Nobody else using FreeBSD? > > I've implemented a work-around that works for me, by using the following line in xymonclient-freebsd.sh: > > netstat -ibn|egrep ">; D=0.0.0.0; }; printf "%-5s %5s %-13s %-17s %12s %6s %14s %14s %6s %14s %6s\n" $A $B $C $D $E $F $G; done > > The output now only includes interface lines with "" and MAC address lines have been replaced with dummy values that parse correctly on the server. I now have useful interface graphs for my FreeBSD systems. > > This is an ugly hack, and I only want this in place until a proper solution can be implemented. > > So, I'm proposing that the xymonclient-freebsd.sh script be modified to use this line for [ifstat]: > > netstat -ibn | egrep " > (This could leave the loopback addresses in place, and I don't think anyone would mind.) > > Then, the following (untested) patch to do_ifstat.c. > > What say ye all? > > Cheers > Jeremy > > --- do_ifstat.c.orig 2014-02-20 13:35:33.000000000 +1100 > +++ do_ifstat.c 2014-02-20 13:42:32.000000000 +1100 > @@ -27,8 +27,10 @@ > > /* Name MTU Network IP Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll */ > /* lnc0 1500 172.16.10.0/24> 172.16.10.151 26 - 1818 26 - 1802 - */ > +/* Name MTU Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll */ > +/* em0 1500 00:11:22:33:44:55 26 - 1818 26 - 1802 - */ > static const char *ifstat_freebsd_exprs[] = { > - "^([a-z0-9]+)\\s+\\d+\\s+[0-9.\\/]+\\s+[0-9.]+\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+ [0-9-)\s+\d+\s+%5b0-9-%5d+\s+(\d+)\s+%5b0-9->]+" > + "^([a-z0-9]+)\\s+\\d+\\s+\\s+[:0-9]+\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+\\d+\\s+[0-9-]+\\s+(\\d+)\\s+ //s+[:0-9]+//s+//d+//s+[0-9-]+//s+(//d+)//s+//d+//s+[0-9-]+//s+(//d+)//s+>[0-9-)\s+\d+\s+%5b0-9-%5d+\s+(\d+)\s+%5b0-9->]+" > }; > > /* Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll */ > > > ********************************************************************** > This message is intended for the addressee named and may contain > privileged information or confidential information or both. If you > are not the intended recipient please delete it and notify the sender. > ********************************************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From zak.beck at accenture.com Tue Dec 15 09:57:07 2015 From: zak.beck at accenture.com (zak.beck at accenture.com) Date: Tue, 15 Dec 2015 08:57:07 +0000 Subject: [Xymon] clientconfig.cfg not getting updated In-Reply-To: References: <96BCCCBE6729EC4AA7F7806640317F4F268F43@KGexch01.kitchen-net.com.au> <96BCCCBE6729EC4AA7F7806640317F4F26A78B@KGexch01.kitchen-net.com.au>

<96BCCCBE6729EC4AA7F7806640317F4F2811AF@KGexch01.kitchen-net.com.au> Message-ID: Hi Your syntax for tssessions and adreplicaton is incorrect, but I would not expect this to stop the file updating. tssessions should be tssessions:: where and are the numbers of sessions free below which you will get the appropriate alert, e.g. tssessions:10:2 adreplicaton should be adreplicationcheck. As you have two servers, is the config for client-local.cfg the same on both – I think we just take the last one connected to. You could try it with just one server and see what happens. Zak Beck From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Colin Coe Sent: 15 December 2015 07:17 To: Brandon Dale Cc: xymon at xymon.com Subject: Re: [Xymon] clientconfig.cfg not getting updated Yep, did this but forgot to include it in the list of things tried. On Tue, Dec 15, 2015 at 3:15 PM, Brandon Dale > wrote: Might be this xxx.xx.106.11 xxx.xx.176.11 then I know you can have more than 1 server here but I don’t know the syntax just double check this, maybe try with just a single server listed here. Regards, Brandon. From: Colin Coe [mailto:colin.coe at gmail.com ] Sent: Tuesday, 15 December 2015 6:04 PM To: Brandon Dale > Cc: xymon at xymon.com Subject: Re: [Xymon] clientconfig.cfg not getting updated OK, by adding heaps of debug "WriteLog"s, I believe I've found the problem. Version 2.04 of the script. 2474 function XymonClientConfig($cfglines) 2475 { 2476 if ($cfglines -eq $null -or $cfglines -eq "") { return } 2477 WriteLog "DEBUG - " + $cfglines The above prints "DEBUG - " and nothing more, which tells me that it is not successfully talking to the server. The XymonSend function worked though... On Tue, Dec 15, 2015 at 2:47 PM, Colin Coe > wrote: HI Brandon I appreciate your help with this. The log file (c:\xymonclient.log) is being written to and I can see "Using new remote config, saving locally" however the clientconfig.cfg while the files time stamp updates, the content doesn't change. I ended up putting that section of code in a try catch block but no error was generated. Doing the XymonSend resulted in the whole file being downloaded being downloaded from the Xymon server. I've done the Windows equiv of chmod 777 on the client-local.cfg to run out permission problems. It looks On Tue, Dec 15, 2015 at 1:12 PM, Brandon Dale > wrote: > It should be writing a log file when it runs c:\xymonclient.log, do you see that log file being written, does it contain any errors? > And in xymon are you seeing any of the data make it to your xymon server, you should see all the data in the clientlog column. > > > One thing I have done in the past when having issues is use xymonsend from http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/xymonsend.ps1 to confirm I can talk to the xymon server. You can dot source this into powershell and run something like > > XymonSend "config client-local.cfg" "xymonservername" > c:\temp\client-local.cfg > > At least then you can see if you can actually pull down the files on that server or not. > > Regards, > > > Brandon > > > -----Original Message----- > From: Colin Coe [mailto:colin.coe at gmail.com ] > Sent: Tuesday, 15 December 2015 12:59 PM > To: Brandon Dale > Cc: xymon at xymon.com