Re: Monitor output size limitation

[Jim Trocki]

On Fri, 8 Apr 2005, David Nolan wrote:
This is a known bug with some regexps in perl's Text::ParseWords that is 
tickled by large input from mon.
well it's not really a bug, it's just that the default stack size is
inadequate for regexps in that module. bump up the stack allocation with
"uname -s" and you'll see the problem vanishes. but it's better to have
fixed the glitch with changing the code than expecting that people run
with a modified stack size :)
___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon

Re: trap received but not acted upon.

[Jim Trocki]

On Fri, 8 Apr 2005, Hans Fugal wrote:
Maybe I'm doing something wrong, because I see this in the logs but no
alert is ever sent:

watch default
   service default
   description Default trap service
   period
   alert mail.alert fugalh
you need to use a valid period definition, i.e. something that is
meaningful to Time::Period, such as "wd {Sun-Sat}". try this:
watch default
   service default
   description Default trap service
   period wd {Sun-Sat}
   alert mail.alert fugalh
___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon

trap received but not acted upon.

[Hans Fugal]

I followed the suggestion of writing a traphandler for snmptrapd to
send a mon trap. Here is the script:

#!/usr/bin/perl
use Mon::Client;

$mon = new Mon::Client(
host => "localhost",
port => 2583,
username => "mon",
password => "secret"
);

chomp($hostname = <>);
chomp($ipaddr = <>);
$detail = "";
while (<>) { $detail .= $_; }

$mon->send_trap( 
group => "snmp", 
service => "trap", 
retval => 1, 
opstatus => "unknown", 
summary => "SNMP trap from $hostname",
detail => $detail
);


Maybe I'm doing something wrong, because I see this in the logs but no
alert is ever sent:

Apr  8 16:44:51 gwythaint mon[19720]: trap trap 5 from 127.0.0.1 for
snmp trap, status 1
Apr  8 16:44:51 gwythaint mon[19720]: trap received from 127.0.0.1 for
undefined type trap 5 snmp

Here's the relevant config bit:

watch default
service default
description Default trap service
period
alert mail.alert fugalh

-- 
De gustibus non disputandum est.

___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon

Re: Monitor output size limitation

[Chris Hansen]

Hey thanks David,

That was very helpful info.  Probably would've spent days hunting that
down...  Upgraded to mon-1.1.0pre1 and everything's working beautifully.

Thanks again,
--
Chris

David Nolan wrote:

>
>
> --On Friday, April 08, 2005 1:12 PM -0500 Chris Hansen
> <[EMAIL PROTECTED]> wrote:
>
>> My question is, is anyone aware of a limitation in the expected output
>> of a monitor returned to mon?  I briefly looked through mon's source,
>> but didn't come across anything to give any clues.
>
>
> This is a known bug with some regexps in perl's Text::ParseWords that
> is tickled by large input from mon.  This is why the current mon code
> no longer uses Text::ParseWords.  I suggest upgrading to mon-1.1.0pre1
> from , or at least
> to mon-1.0.0pre5.  You'll also need to update the Mon::Client module,
> available from the same place as mon-client-1.0.0pre2
>
> -David
>
> David Nolan<*>[EMAIL PROTECTED]
> curses: May you be forced to grep the termcap of an unclean yacc while
>  a herd of rogue emacs fsck your troff and vgrind your pathalias!

___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon

Re: Monitor output size limitation

[David Nolan]

--On Friday, April 08, 2005 1:12 PM -0500 Chris Hansen 
<[EMAIL PROTECTED]> wrote:

My question is, is anyone aware of a limitation in the expected output
of a monitor returned to mon?  I briefly looked through mon's source,
but didn't come across anything to give any clues.
This is a known bug with some regexps in perl's Text::ParseWords that is 
tickled by large input from mon.  This is why the current mon code no 
longer uses Text::ParseWords.  I suggest upgrading to mon-1.1.0pre1 from 
, or at least to 
mon-1.0.0pre5.  You'll also need to update the Mon::Client module, 
available from the same place as mon-client-1.0.0pre2

-David
David Nolan<*>[EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
 a herd of rogue emacs fsck your troff and vgrind your pathalias!
___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon

Monitor output size limitation

[Chris Hansen]

Hello,

I have run into a problem where mon seg faults when the output of a
monitor exceeds a certain size.  Looks it's right around the 4 KB
limit.  I've written a quick-and-dirty bash script to check for free
space on the hosts in a hostgroup, and it works fine when the hostgroup
contains just a few hosts.  But when I attempt to test with a larger
hostgroup (9 or more), mon.cgi gives an Internal Server Error, and
monshow simply displays a segmentation fault.

Basically the script works by ssh'ing to the servers and running df -h,
then parses the output looking for a value in the Use field that is
greater than or equal to a specified value.  The monitor returns as
output a status message about which host/partition is near capacity, and
also the output of df -h for each host.  I have added an option to the
monitor script to suppress the df-per-host output, and if I activate
this option in the mon.cf file, everything works great: I still get
alerts if a server has an almost full partition, but of course the
detailed output is missing.  I wish to be able to use mon.cgi to quickly
check the disk usage on all of the hosts, so this output is very important.

I have found that when the output is over 4 KB, the problem occurs. 
After doing some testing, I was able to make it work by getting the
output down to about 3.5 KB or so.  I did this by removing the header
columns (Filesystem, Size, Used, etc) and the /dev/shm entry as these
rows are not critical.  However my concern is that once I begin to add
more hosts to the hostgroup, I will again run into this problem as the
output gets larger.  When running mon with debugging enabled, the debug
output started listing integers, one per line in sequential order, about
one per second, and never terminating or moving onto other monitors
until I stopped mon.  It was at this point that monshow displayed
segmentation fault.

My question is, is anyone aware of a limitation in the expected output
of a monitor returned to mon?  I briefly looked through mon's source,
but didn't come across anything to give any clues.

Thanks in advance ;-)

--
Chris

___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon