- Xymon - Xymon mailman web

Xymon Network Tests - Behaviour?
by mariov652＠gmail.com 25 Aug '11

25 Aug '11

Thank you for > Date: Wed, 24 Aug 2011 14:42:21 +0200 > From: <henrik at hswn.dk> > To: <xymon at xymon.com> > Subject: Re: [Xymon] Xymon Network Tests - Behaviour? > Message-ID: <04b91460cd235e5018e5179c06657153 at localhost> > Content-Type: text/plain; charset=UTF-8 > > On Wed, 24 Aug 2011 13:52:55 +0200, Mario Valetti <mariov652 at gmail.com> > wrote: >> Could someone please explain the exact behaviour when a host becomes >> unreachable? >> >> As I understand it, it works as follows... >> >> - Xymon pings each host only once, >> - if a reply is not received within a specified time (1sec), 3 ping >> requests are sent out, >> - from one of these three additional pings if a reply is received, the >> host is not indicated as being unavailable and things continue >> normally. If a reply is not received from these three additional >> requests, the host is marked as unavailable and four pings requests >> sent out every minute until a response is received. >> >> - Why do hosts show unavailable for 40s, 45s for example? Are the >> times above not fixed and rather work dynamically? > > Not quite, but the normal test and the extra test are scheduled > independently (they are two different tasks in tasks.cfg). The only > restriction is that they will not run simultaneously. So when the first > test detects that the host is down, the extra test may run anywhere from 0 > to 59 seconds after that. > >> Second question is regarding hosts that are shutdown for maintenance, >> for example... >> Usually, these are set to 'until ok' and the host marked blue with no >> alerts. However Xymon still sends an arp request / ping to check when >> the host becomes available. >> >> Is it possible to disable a host in a way that avoids Xymon checking >> for the host at all? > > No. How would Xymon detect that the host becomes OK without trying to ping > it ? > > > Regards, > Henrik

2 3

4.3.4 proxy to a 4.2.3 server
by Paul.Root＠CenturyLink.com 25 Aug '11

25 Aug '11

I have 2 proxy servers forwarding up to a main server. One has been upgraded to 4.3.4 and the other is still 4.2.3. I went to upgrade the second server today, and it went badly. I got a huge amount of purple faces. Mostly on conn for my devmon clients and ntp for my regular clients. The devmon clients are noconn on the server, for various reasons, and the regular servers have ntp in the proxy's hosts.cfg/bb-hosts file, but not in the servers bb-hosts file, due to firewalling issues. Anyway, I'm starting to think that my 4.3.4 proxy is not actually proxying up to the main server. It proxies to itself (on 1985) and a 4.3.4 test server just fine. Is there an issue with a 4.3.4 sending proxy data to an older server? I also just found some other information, on the 4.3.4 in the log files: rrd-data.log: 2011-08-24 14:20:52 Peer not up, flushing message queue 2011-08-24 14:20:52 Peer not up, flushing message queue xymond_rrd: error while loading shared libraries: librrd.so.4: cannot open shared object file: No such file or directory 2011-08-24 14:20:52 Peer at 0.0.0.0:0 failed: Broken pipe 2011-08-24 14:21:09 Peer not up, flushing message queue 2011-08-24 14:21:09 Peer not up, flushing message queue 2011-08-24 14:21:09 Peer not up, flushing message queue 2011-08-24 14:21:11 Peer not up, flushing message queue 2011-08-24 14:21:11 Peer not up, flushing message queue 2011-08-24 14:21:11 Peer not up, flushing message queue And rrd-status.log is the same. And so I look at the web of the 4.3.4 server and there are no graphs. There are graphs on the test server. Any ideas? Paul Root - Engineer III - Qwest is now CenturyLink 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.

2 6

MAXMSG_* limits
by Phil.Crooker＠orix.com.au 25 Aug '11

25 Aug '11

f course it works now ;-) I think I'd been making changes to xymonserver.cfg without restarting xymon. Sorry for the bother... cheers, Phil >>> On 25/08/2011 at 3:45 PM, in message <4E55E171.9020202 at hswn.dk>, Henrik Størner wrote: > On 25-08-2011 05:07, Phil Crooker wrote: >> I was having an issue with BBWin client messages being too large and >> getting truncated. In the xymonserver.cfg help file, eg: >> >> "MAXMSG_STATUS >> The maximum size of a "status" message in kB, default: 256. " >> >> I tried putting that variable in and enlarging it to 512 but still >> received the same error and no change to MAXMSG either. I found I had to >> use a value in bytes, not KB as stated - this was reported back in 2006: >> >> >> http://lists.xymon.com/oldarchive/2006/05/msg00196.html > > And I belive it was fixed back then. I just tried it with 4.3.4, and it > picks up the KB-value just fine. What version are you running? > 4.3.4. As it works for you, I'll do some homework and report back. > You can use the command "ipcs -m" to see the size of the shared memory > segments that Xymon uses (you must be logged in as root, or the xymon user). > >> I also found I had to restart xymon for it to pick up the changes. It >> may be possible to just kill -HUP or something, I didn't try. But I >> didn't expect this behaviour as the other config changes I've made have >> been picked up on the fly... > > Changing xymonserver.cfg usually requires a restart. All other config > changes are picked up automatically. Could that please be included in the xymonserver.cfg man page? thanks, Phil > > > Regards, > Henrik > _______________________________________________ > 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

1 0

MAXMSG_* limits
by Phil.Crooker＠orix.com.au 25 Aug '11

25 Aug '11

>>> On 25/08/2011 at 3:45 PM, in message <4E55E171.9020202 at hswn.dk>, Henrik Størner<henrik at hswn.dk> wrote: > On 25-08-2011 05:07, Phil Crooker wrote: >> I was having an issue with BBWin client messages being too large and >> getting truncated. In the xymonserver.cfg help file, eg: >> >> "MAXMSG_STATUS >> The maximum size of a "status" message in kB, default: 256. " >> >> I tried putting that variable in and enlarging it to 512 but still >> received the same error and no change to MAXMSG either. I found I had to >> use a value in bytes, not KB as stated - this was reported back in 2006: >> >> >> http://lists.xymon.com/oldarchive/2006/05/msg00196.html > > And I belive it was fixed back then. I just tried it with 4.3.4, and it > picks up the KB-value just fine. What version are you running? > 4.3.4. As it works for you, I'll do some homework and report back. > You can use the command "ipcs -m" to see the size of the shared memory > segments that Xymon uses (you must be logged in as root, or the xymon user). > >> I also found I had to restart xymon for it to pick up the changes. It >> may be possible to just kill -HUP or something, I didn't try. But I >> didn't expect this behaviour as the other config changes I've made have >> been picked up on the fly... > > Changing xymonserver.cfg usually requires a restart. All other config > changes are picked up automatically. Could that please be included in the xymonserver.cfg man page? thanks, Phil > > > Regards, > Henrik > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon

1 0

MAXMSG_* limits
by Phil.Crooker＠orix.com.au 25 Aug '11

25 Aug '11

I was having an issue with BBWin client messages being too large and getting truncated. In the xymonserver.cfg help file, eg: "MAXMSG_STATUS The maximum size of a "status" message in kB, default: 256. " I tried putting that variable in and enlarging it to 512 but still received the same error and no change to MAXMSG either. I found I had to use a value in bytes, not KB as stated - this was reported back in 2006: http://lists.xymon.com/oldarchive/2006/05/msg00196.html I assume this applies to all MAXMSG_* settings, I only had to deal with STATUS, DATA and CLIENT. I also found I had to restart xymon for it to pick up the changes. It may be possible to just kill -HUP or something, I didn't try. But I didn't expect this behaviour as the other config changes I've made have been picked up on the fly... But irrespective of this little issue, thanks everyone for a great system. cheers, Phil

2 1

Spec file for 4.3.4?
by tdiehl＠rogueind.com 25 Aug '11

25 Aug '11

On Tue, 23 Aug 2011, Buchan Milne wrote: > On Monday, 22 August 2011 21:34:34 Tom Diehl wrote: >> On Mon, 22 Aug 2011, Jason Kincl wrote: >>> Daniel, >>> >>> This issue has been discussed in another thread of the mailing list, see >>> link here: http://lists.xymon.com/archive/2011-April/031407.html >>> >>> If you follow the thread, I replied with a fix for the xymonmenu.css file >>> not found. As for the critical.cfg.bak file, I have just commented that >>> line out of the spec file with no problems. >>> >>> On Aug 22, 2011, at 11:51 AM, Daniel McDonald wrote: >>>> I tried to build 4.3.4 using the included spec file, and came up with a >>>> few errors: >>>> >>>> RPM build errors: >>>> File not found: /tmp/xymon-root/var/lib/xymon/www/menu/xymonmenu.css >>>> File not found: /tmp/xymon-root/etc/xymon/critical.cfg.bak >>>> File listed twice: /usr/lib/xymon/client/bin/clientupdate >>>> File listed twice: /usr/lib/xymon/client/bin/logfetch >>>> File listed twice: /usr/lib/xymon/client/ext >>>> >>>> Does anyone have a working specfile? I’d like to build this on >>>> Mandriva Enterprise Server 5.2 >> >> I do not know anything about Mandriva Enterprise Server 5.2 but I have an >> srpm at: >> http://yumrepo.tntechs.com/yum-repository/local/centos/tntechs-testing/6/SR >> PMS/xymon-4.3.4-1.el6.tnt.2.src.rpm that I am using for my CentOS 5 and 6 >> servers. >> >> It is modified from the original spec file included with xymon > > Which has multiple issues regarding most package quality compliance > guidelines. IMHO, it is a bad place to start ... Agreed but it was the quickest way for me to get a template to hack on. I have fixed a lot of the problems rpmlint shows when run against the srpm. When rpmlint is run against the rpm there are many errors. Most are things like the following: xymon.i386: W: manpage-not-compressed gz /var/lib/xymon/www/help/manpages/man8/xymonproxy.8.html xymon.i386: W: name-repeated-in-summary C Xymon xymon.i386: W: non-standard-uid /var/lib/xymon/www/gifs/blue-ack.gif xymon xymon.i386: E: non-standard-executable-perm /usr/lib/xymon/server/bin/xymon-mailack 0775L In the xymon context, I do not think the above warnings are valid. For the error, I need to understand what it is telling me. The permissions on the referenced files are 0775 I do not understand what 0775L is and more importantly how to fix it. The spec file says the permissions are 775. As I said above this is a work in progress. > >> and includes >> some selinux policy files that may or may not be correct. They were >> generated by audit2allow after running xymon with selinux in permissive >> mode. > > How about submitting a patch so these can be included in the source release? I am hesitant to do that because I am not sure that they are correct. If someone who understands selinux could review them then I do not have a problem. >> It is a work in progress and guaranteed to contain as yet unknown bugs. :-) >> Use it at your own risk or ignore it. Whatever you prefer. >> >> If someone finds errors/bugs, I would appreciate knowing about them. >> Especially if you know how to fix them as they relate to CentOS/RHEL. > > Well, I have discussed this many times, but there are a number of spec files > floating around, and most of them don't take upgrading (e.g. 4.2.3 to 4.3.x) > into account, and many fix different issues, but almost no-one seems to be > willing to discuss what must be fixed, and contribute to fixing the spec file > in svn. I would love to discuss what needs to be fixed to get a good set of rpms for RHEL/centos/fedora. The problem is that many people want rpms for other rpm based distros that I have no experience with. I have seen many attempts in the past to maintain distro agnostic rpms with very limited success. As to the upgrade issue, I have no real way of testing upgrades and there are a lot of variables that I am sure I would miss. The only thing I did in my srpm wrt upgrades was check to see if the old hobbit* config files existed and rename them to the xymon equivalents. > > Until such a time, there will continue to be multiple incompatible packages. Indeed. Regards, -- Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com

3 2

Bug: segfault in logfetch
by jlaidman＠rebel-it.com.au 25 Aug '11

25 Aug '11

Hi I've been hit with a problem whereby a certain combination of log messages and ignore/trigger settings cause logfetch to dump core during a memmove() operation. Same on both versions 4.3.4 and 4.3.3. It only seems to happen when I have an "ignore" clause (doesn't need to match anything) and a trigger clause that matches a line in the logfile. Backtrace from gdb: #0 0x00002acb0153cdaa in _wordcopy_fwd_dest_aligned () from /lib64/libc.so.6 #1 0x00002acb0153b1d0 in memmove () from /lib64/libc.so.6 #2 0x0000000000404030 in logdata (filename=0x5192d0 "./named.log", logdef=0x519268) at logfetch.c:315 #3 0x00000000004042cb in main (argc=<value optimized out>, argv=<value optimized out>) at logfetch.c:963 I've isolated the "logfetch.*" files from /tmp, and the 8 lines of log that trigger the problem for me, so it's easy to reproduce the fault with these files. In some cases I can avoid the problem by reducing the logfile down to less than the "maxbytes" setting in client-local.cfg, or increasing the "maxbytes" value to larger than the logfile size. Short of learning more C, I don't know what more I can do to find/fix the problem. Cheers Jeremy

1 0

Xymon Network Tests - Behaviour?
by malcolm.hunter＠gmx.com 24 Aug '11

24 Aug '11

> ----- Original Message ----- > From: Xymon User in Richmond > Sent: 08/24/11 05:32 PM > To: xymon at xymon.com > Subject: Re: [Xymon] Xymon Network Tests - Behaviour? > Duh. I seem either to be partially blind this morning, or ready for tea > with Pat Summitt. I always use time disablements for maintenance windows. > "Until OK" re-enables the server if it bounces during the window, not > desirable. Agreed, I only use "Until OK" if the service is already non-green (e.g. if I've just bounced a server and want to disable uptime until it goes green). Malcolm -- BBWin Development - The Windows client for Big Brother and Xymon http://bbwin.sourceforge.net http://xymon.sourceforge.net

1 0

Xymon Network Tests - Behaviour?
by malcolm.hunter＠gmx.com 24 Aug '11

24 Aug '11

> ----- Original Message ----- > From: Xymon User in Richmond > Sent: 08/24/11 02:11 PM > To: xymon at xymon.com > Subject: Re: [Xymon] Xymon Network Tests - Behaviour? > >> Is it possible to disable a host in a way that avoids Xymon checking > for the host at all? > > > > No. How would Xymon detect that the host becomes OK without trying to > ping it ? > > > > Why would Xymon care about whether a host disabled for a specific period > of time becomes OK during that time? But the original question started: Usually, these are set to 'until ok' and the host marked blue with no alerts. However Xymon still sends an arp request / ping to check when the host becomes available. i.e. No mention of "period of time". Malcolm -- BBWin Development - The Windows client for Big Brother and Xymon http://bbwin.sourceforge.net http://xymon.sourceforge.net

3 2

Xymon Network Tests - Behaviour?
by hobbit＠epperson.homelinux.net 24 Aug '11

24 Aug '11

On Wed, August 24, 2011 08:42, henrik at hswn.dk wrote: > On Wed, 24 Aug 2011 13:52:55 +0200, Mario Valetti <mariov652 at gmail.com> wrote: >> >> Is it possible to disable a host in a way that avoids Xymon checking for the host at all? > > No. How would Xymon detect that the host becomes OK without trying to ping it ? > Why would Xymon care about whether a host disabled for a specific period of time becomes OK during that time?

2 1