Re: Monitor output size limitation

[Jim Trocki]

On Mon, 11 Apr 2005, Ed Ravin wrote:
On Fri, Apr 08, 2005 at 06:33:38PM -0700, Jim Trocki wrote:
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.
I think you meant to say "ulimit -s" :-)
yeah, one of those u.* commands. keep trying all of them until you find
one that works :)
___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon

Re: Monitor output size limitation

[Ed Ravin]

On Fri, Apr 08, 2005 at 06:33:38PM -0700, Jim Trocki wrote:
> 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.

I think you meant to say "ulimit -s" :-)

___
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 6:33 PM -0700 Jim Trocki <[EMAIL PROTECTED]> 
wrote:

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.
Ahh, that's what it was.  Back when I was seeing this problem I just 
remember seeing reports that it was a 'regexp bug', and didn't bother to 
track it down.  Still, you'd think perl could do a better job of detecting 
the approaching stack size limit and throwing an error in that case instead 
of segfaulting.

but it's better to have
fixed the glitch with changing the code than expecting that people run
with a modified stack size :)

True.  Even when Mon didn't segfault, the performance of those regexps on 
significant amounts of data was sometimes horrible.  I had occasions where 
mon.cgi's parsing of the opstatus output was taking a minute or more. 
Changing the encoding so a simple split could be used instead made my mon 
interface load almost instantly.

-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

[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: 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