December 2015 - Xymon - Xymon mailman web

Possible Bug in Xymon Related to Purple Statuses
by matt1299＠gmail.com 03 Dec '15

03 Dec '15

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 <HOST> 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=<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 <HOST> cpu [image: green] [image: From -> To] <https://mon.crc.nd.edu/xymon-cgi/historylog.sh?HOST=jim.vectorbase.org&SERV…>[image: clear] Wed Dec 2 09:57:48 2015 <HOST> disk [image: green] [image: From -> To] <https://mon.crc.nd.edu/xymon-cgi/historylog.sh?HOST=jim.vectorbase.org&SERV…>[image: clear] Wed Dec 2 09:57:48 2015 <HOST> inode [image: green] [image: From -> To] <https://mon.crc.nd.edu/xymon-cgi/historylog.sh?HOST=jim.vectorbase.org&SERV…>[image: clear] Wed Dec 2 09:57:48 2015 <HOST> 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

2 3

error installing Terabithia rpm xymon-client-4.3.24-1.el6.x86_64
by andreas.kunberger＠itv-denkendorf.de 02 Dec '15

02 Dec '15

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

3 2

issues with new install
by cleaver＠terabithia.org 02 Dec '15

02 Dec '15

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

2 3

Bug in TRENDS handling?
by jlaidman＠rebel-it.com.au 02 Dec '15

02 Dec '15

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

2 2

journalctl log monitoring
by rs＠sys4.de 01 Dec '15

01 Dec '15

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

3 4

PID file for XYMOND_ALERT
by john.thurston＠alaska.gov 01 Dec '15

01 Dec '15

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

2 1

http error
by nmaharaj＠tcta.co.za 01 Dec '15

01 Dec '15

<html><bodyHi, 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://xymon.sourceforge.net/> 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.</body></html>

2 1

issues with new install
by sys1002＠yahoo.com 01 Dec '15

01 Dec '15

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.

1 0