Re: Monitor output size limitation
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
--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
Monitor output size limitation
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
Re: Monitor output size limitation
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 ftp://ftp.kernel.org/pub/software/admin/mon/devel/, 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
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
