leaking memory, alerts.cfg problems
Our organization is one of I'd assume many that are evaluating our options now that Dell no longer supports BigBrother.
We had a fairly smooth transition to Xymon (we compiled form source on Ubuntu 14.04.1 LTS x86-64).
The problem that we're having is that we can't find a sane way to remove a service check from our switches/routers, specifically TELNET.
We removed the column from displaying on our webpage, but we were still receiving alerts on it.
We've made customization to our alerts, but now no matter what we try, we can't get alerts to fire and sometimes see messages like:
someuser at somehost:~$ sudo vi /etc/xymon/alerts.cfg
[sudo] password for someuser: no talloc stackframe at ../source3/param/loadparm.c:4864, leaking memory
I've scoured the internet to no avail. Any insight? If we can get the product running reliably we're sure to use it for years to come. :)
-Tres
- Tres.Finocchiaro at gmail.com
On 9 September 2014 23:57, Tres Finocchiaro <tres.finocchiaro at gmail.com> wrote:
no talloc stackframe at ../source3/param/loadparm.c:4864, leaking memory
This is a bug in Samba. Refer: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1257186
This is entirely unrelated to Xymon.
If you don't have "telnet" listed for a host/device in hosts.cfg, or in the ".default." entry, then Xymon should not include it in its service checks.
J
@Jeremy,
This is a bug in Samba. Refer: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1257186
This is entirely unrelated to Xymon.
Terrific, thank you.
If you don't have "telnet" listed for a host/device in hosts.cfg, or in the ".default." entry, then Xymon should not include it in its service checks.
OK, this is where I'm struggling. We have a separate host group for our switches:
group-sorted UFIRST Switches
0.0.0.0 .default. # NOCOLUMNS:telnet 192.168.0.5 SWITCH1 # ssh
But originally had had:
192.168.0.5 SWITCH1 # telnet
We followed the instructions for purging the history:
xymon 127.0.0.1 "drop SWITCH1 telnet"
But we still received alerts.
red Wed Sep 3 09:26:38 2014 telnet NOT ok
Service telnet on SWITCH1 is not OK : Service unavailable (Connection refused) Seconds: 0.00
So I tried filtering it in the alerts.cfg:
HOST=%* SERVICE=%*
MAIL tres at company.local EXSERVICE=telnet
But now we aren't receiving any alerts at all.
To verify it's not an email settings:
mail -s "Test Email" tres at company.local < /dev/null
Which succeeds.
The only part I did not mention is that some of our hosts were renamed from lowercase to uppercase for aesthetics.
The manpage says “column is one of cpu, disk, files, memory, msgs, ports, procs.” – it doesn’t mention “telnet” as an option to drop.
Regards,
Carl
From: Tres Finocchiaro [mailto:tres.finocchiaro at gmail.com] Sent: 10 September 2014 13:50 To: Carl Inglis Cc: xymon at xymon.com Subject: RE: [Xymon] leaking memory, alerts.cfg problems
That suggests to me that your “NOCOLUMNS: telnet” is invalid
How so? My usage matches the manpage, no?
Carl Inglis AMBCS Systems Administrator
Rakon UK Limited Dowsett House, Sadler Road, Lincoln LN6 3RS, United Kingdom Tel: +44 1522 812630 | Fax: +44 1522 812664 | Mob: +44 7786 552915 Carl.Inglis at rakon.com | www.rakon.com
[The Queens Awards for Enterprise 2012]
[Rakon Logo]
This message together with any attachments contains confidential information and may be subject to privilege. If you are not the intended recipient you may not distribute it in any way, you must notify the sender immediately and delete any copies of the message along with its attachments.
Rakon UK Ltd is a limited company registered in England and Wales. Registered Office: Antell House, Windsor Place, Harlow, Essex, England, CM20 2GQ Company Registration Number: 5128090.
Please be aware that Rakon UK Limited may monitor email traffic data including the date, time, subject line, sender and recipients for the purposes of security and usage monitoring. Automated monitoring systems may also be applied to ascertain whether incoming/outgoing emails are likely to contain viruses, other destructive devices or inappropriate content.
The manpage says “*column* is one of *cpu*, *disk*, *files*, *memory*, *msgs*, *ports*, *procs*.” – it doesn’t mention “telnet” as an option to drop.
Well, then the manpage should be updated.
Here is the page normally:
And here is the page with "0.0.0.0 .default. # NOCOLUMNS:telnet" added.
To entertain the suggestion, I've commented out the .default. line too but still no alerts... I'm not sure where else to look.
Maybe I’m confused, but what’s the point of using NOCOLUMMS for something that’s not one of the statuses that is sent by the client? If you want to omit telnet, simply don’t list it in hosts.cfg for the host. If you want to drop an existing column, look into “Tips and Tricks” under the Help menu, and navigate to “How do I delete a test status?”.
NOCOLUMNS is for something that the client will continue to send, and you can’t turn off, but don’t want to display.
glauber
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Tres Finocchiaro Sent: Wednesday, September 10, 2014 09:31 To: Carl Inglis Cc: xymon at xymon.com Subject: Re: [Xymon] leaking memory, alerts.cfg problems
The manpage says “column is one of cpu, disk, files, memory, msgs, ports, procs.” – it doesn’t mention “telnet” as an option to drop.
Well, then the manpage should be updated.
Here is the page normally:
And here is the page with "0.0.0.0 .default. # NOCOLUMNS:telnet" added.
To entertain the suggestion, I've commented out the .default. line too but still no alerts... I'm not sure where else to look.
@Ribeiro,
Thanks kindly for the reply. Please see my responses below.
Maybe I’m confused, but what’s the point of using NOCOLUMMS for something that’s not one of the statuses that is sent by the client?
I agree. I mentioned in my second post that I ran the "drop" statement per instructions. I've done this several time, but telnet keeps coming back. Hiding it using NOCOLUMNS is the only way to keep the page from going purple.
If you want to omit telnet, simply don’t list it in hosts.cfg for the host.
As aforementioned, we don't list in in hosts.cfg, we list # ssh instead. I'm not sure why it keeps coming back.
If you want to drop an existing column, look into “Tips and Tricks” under the Help menu, and navigate to “How do I delete a test status?”.
As aforementioned, we did this.
NOCOLUMNS is for something that the client will continue to send, and you can’t turn off, but don’t want to display.
Since the client is a switch, I'm not sure we have the ability to alter anything from the "send" side of the fence. Let me know if this assumption is incorrect.
@Carl,
I just saw your reply come in. I'll try your recommendations now.
-Tres
- Tres.Finocchiaro at gmail.com
On Wed, Sep 10, 2014 at 10:46 AM, Ribeiro, Glauber < glauber.ribeiro at experian.com> wrote:
Maybe I’m confused, but what’s the point of using NOCOLUMMS for something that’s not one of the statuses that is sent by the client? If you want to omit telnet, simply don’t list it in hosts.cfg for the host. If you want to drop an existing column, look into “Tips and Tricks” under the Help menu, and navigate to “How do I delete a test status?”.
NOCOLUMNS is for something that the client will continue to send, and you can’t turn off, but don’t want to display.
glauber
*From:* Xymon [mailto:xymon-bounces at xymon.com] *On Behalf Of *Tres Finocchiaro *Sent:* Wednesday, September 10, 2014 09:31 *To:* Carl Inglis *Cc:* xymon at xymon.com *Subject:* Re: [Xymon] leaking memory, alerts.cfg problems
The manpage says “*column* is one of *cpu*, *disk*, *files*, *memory*, *msgs*, *ports*, *procs*.” – it doesn’t mention “telnet” as an option to drop.
Well, then the manpage should be updated.
Here is the page normally:
And here is the page with "0.0.0.0 .default. # NOCOLUMNS:telnet" added.
To entertain the suggestion, I've commented out the .default. line too but still no alerts... I'm not sure where else to look.
@Carl,
Thank, I believe that corrected the lingering telnet. It has not reappeared, thank you.
But I'm still not receiving alerts. We've intentionally left SSH disabled on this switch to trigger an alert, but emails don't seem to be going through.
What is the command to trigger a test email from xymon? I found this in the archives:
$ xymoncmd xymon_alert --test SWITCH1 ssh
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
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.
-Tres
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 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
As Paul pointed out, use “xymond_alert” rather than “xymon_alert”. One of the most useful debug tools I’ve found for alerting is:
Add --cfid to the CMD in the [alerts] section of tasks.cfg
It means that when you *do* get your alerts working, you’ll get the line number of test line that fired in the subject of the message; this allows you to identify exactly which rule triggered the message.
Good luck. ☺
From: Tres Finocchiaro [mailto:tres.finocchiaro at gmail.com] Sent: 10 September 2014 16:22 To: Ribeiro, Glauber Cc: Carl Inglis; xymon at xymon.com Subject: Re: [Xymon] leaking memory, alerts.cfg problems
@Carl,
Thank, I believe that corrected the lingering telnet. It has not reappeared, thank you.
But I'm still not receiving alerts. We've intentionally left SSH disabled on this switch to trigger an alert, but emails don't seem to be going through.
What is the command to trigger a test email from xymon? I found this in the archives: $ xymoncmd xymon_alert --test SWITCH1 ssh
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
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.
-Tres
Carl Inglis AMBCS Systems Administrator
Rakon UK Limited Dowsett House, Sadler Road, Lincoln LN6 3RS, United Kingdom Tel: +44 1522 812630 | Fax: +44 1522 812664 | Mob: +44 7786 552915 Carl.Inglis at rakon.com | www.rakon.com
[The Queens Awards for Enterprise 2012]
[Rakon Logo]
This message together with any attachments contains confidential information and may be subject to privilege. If you are not the intended recipient you may not distribute it in any way, you must notify the sender immediately and delete any copies of the message along with its attachments.
Rakon UK Ltd is a limited company registered in England and Wales. Registered Office: Antell House, Windsor Place, Harlow, Essex, England, CM20 2GQ Company Registration Number: 5128090.
Please be aware that Rakon UK Limited may monitor email traffic data including the date, time, subject line, sender and recipients for the purposes of security and usage monitoring. Automated monitoring systems may also be applied to ascertain whether incoming/outgoing emails are likely to contain viruses, other destructive devices or inappropriate content.
AH! You have a purple status – looks to me like the “drop” command didn’t work.
Perhaps try dropping it with the hostname in lower case?
I’ve found in the past that drop can be temperamental and I’ve on occasion ended up dropping the whole host to check that I’ve got it right.
Regards.
Carl
From: Tres Finocchiaro [mailto:tres.finocchiaro at gmail.com] Sent: 10 September 2014 15:31 To: Carl Inglis Cc: xymon at xymon.com Subject: Re: [Xymon] leaking memory, alerts.cfg problems
The manpage says “column is one of cpu, disk, files, memory, msgs, ports, procs.” – it doesn’t mention “telnet” as an option to drop.
Well, then the manpage should be updated.
Here is the page normally:
And here is the page with "0.0.0.0 .default. # NOCOLUMNS:telnet" added.
To entertain the suggestion, I've commented out the .default. line too but still no alerts... I'm not sure where else to look.
Carl Inglis AMBCS Systems Administrator
Rakon UK Limited Dowsett House, Sadler Road, Lincoln LN6 3RS, United Kingdom Tel: +44 1522 812630 | Fax: +44 1522 812664 | Mob: +44 7786 552915 Carl.Inglis at rakon.com | www.rakon.com
[The Queens Awards for Enterprise 2012]
[Rakon Logo]
This message together with any attachments contains confidential information and may be subject to privilege. If you are not the intended recipient you may not distribute it in any way, you must notify the sender immediately and delete any copies of the message along with its attachments.
Rakon UK Ltd is a limited company registered in England and Wales. Registered Office: Antell House, Windsor Place, Harlow, Essex, England, CM20 2GQ Company Registration Number: 5128090.
Please be aware that Rakon UK Limited may monitor email traffic data including the date, time, subject line, sender and recipients for the purposes of security and usage monitoring. Automated monitoring systems may also be applied to ascertain whether incoming/outgoing emails are likely to contain viruses, other destructive devices or inappropriate content.
participants (5)
-
Carl.Inglis＠rakon.com
-
glauber.ribeiro＠experian.com
-
jlaidman＠rebel-it.com.au
-
Paul.Root＠CenturyLink.com
-
tres.finocchiaro＠gmail.com