Oh, it’s xymond_alert not xymon_alert.
From: Root, Paul T Sent: Wednesday, September 10, 2014 10:38 AM To: 'Tres Finocchiaro'; 'Ribeiro, Glauber' Cc: 'xymon at xymon.com' Subject: RE: [Xymon] leaking memory, alerts.cfg problems
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Tres Finocchiaro Sent: Wednesday, September 10, 2014 10:22 AM To: Ribeiro, Glauber Cc: xymon at xymon.com<mailto:xymon at xymon.com> Subject: Re: [Xymon] leaking memory, alerts.cfg problems
But I get this: 2014-09-10 11:14:01 Using default environment file /usr/lib/xymon/client/etc/xymonserver.cfg 2014-09-10 11:14:01 execvp() failed: No such file or directory
This is a problem. Xymoncmd couldn’t find xymon_alert. So it’s not in your path, you need to give the full path.
I assume xymon doesn't stop sending alerts after a timeout period, right? We chose to use the SSH service since it doesn't affect our environment. We can add a fake hostname/ip as well. I fear may have something misconfigured since alerts won't go through at all.
No. xymon sends alerts by what you define for it to send. There are no alerts by default.
-Tres
Oh, it’s xymond_alert not xymon_alert.
Fantastic, that gets me further. So it appears to be breaking on my Perl-compatible percent-asterisk (%*) in the alert.cfg. Apparently my wildcard is invalid.
I change the line from *HOST=%** to *HOST=** and alerts are working great.
Should I use *HOST=**, is this the recommended method? I would assume the alert.cfg to have a basic example for "all hosts" but the best I could find was the Perl example.
-Tres
- Tres.Finocchiaro at gmail.com
On Wed, Sep 10, 2014 at 11:40 AM, Root, Paul T <Paul.Root at centurylink.com> wrote:
Oh, it’s xymond_alert not xymon_alert.
*From:* Root, Paul T *Sent:* Wednesday, September 10, 2014 10:38 AM *To:* 'Tres Finocchiaro'; 'Ribeiro, Glauber' *Cc:* 'xymon at xymon.com' *Subject:* RE: [Xymon] leaking memory, alerts.cfg problems
*From:* Xymon [mailto:xymon-bounces at xymon.com <xymon-bounces at xymon.com>] *On Behalf Of *Tres Finocchiaro *Sent:* Wednesday, September 10, 2014 10:22 AM *To:* Ribeiro, Glauber *Cc:* xymon at xymon.com *Subject:* Re: [Xymon] leaking memory, alerts.cfg problems
But I get this:
2014-09-10 11:14:01 Using default environment file /usr/lib/xymon/client/etc/xymonserver.cfg 2014-09-10 11:14:01 execvp() failed: No such file or directory
This is a problem. Xymoncmd couldn’t find xymon_alert. So it’s not in your path, you need to give the full path.
I assume xymon doesn't stop sending alerts after a timeout period, right? We chose to use the SSH service since it doesn't affect our environment. We can add a fake hostname/ip as well. I fear may have something misconfigured since alerts won't go through at all.
No. xymon sends alerts by what you define for it to send. There are no alerts by default.
-Tres
On 11 September 2014 01:50, Tres Finocchiaro <tres.finocchiaro at gmail.com> wrote:
Fantastic, that gets me further. So it appears to be breaking on my Perl-compatible percent-asterisk (%*) in the alert.cfg. Apparently my wildcard is invalid.
That's because "%*" is invalid. The "%" means what follows is a perl-compatible regular expression (PCRE). An asterisk in a PCRE means "zero or more of the preceding symbol". If there's no preceding symbol, then the PCRE is invalid. What you probably mean is "%.*", where the dot means "any character" and so ".*" means "zero or more of any character".
I change the line from *HOST=%** to *HOST=** and alerts are working great.
This works because you're no longer using an RE, but are matching due to a special case in the host-matching code, where an asterisk means to match everything. But the effect is the same as if you did "%.*".
Should I use *HOST=**, is this the recommended method? I would assume the
alert.cfg to have a basic example for "all hosts" but the best I could find was the Perl example.
Given that "HOST=*" is an undocumented feature, and that it looks like a glob pattern but isn't, I would recommend you use "HOST=%.*".
J
participants (3)
-
jlaidman＠rebel-it.com.au
-
Paul.Root＠CenturyLink.com
-
tres.finocchiaro＠gmail.com