Nagios Support Forum

Your plugin should not have so much output. If you're using a custom plugin, please see the Nagios plugin development guidelines, particularly where it says to try to limit plugin output to a single short line of text.

Yeah, Nagios plugins need to be concise in their output, it wasn't designed to have output like this that spans multiple pages. Although nagios 3 will now support multi-line plugin output, the design of it is still intended that plugin output be MUCH shorter than what is displayed above.

http://nagiosplug.sourceforge.net/devel ... html#AEN33

2.1. Print only one line of text

Nagios will only grab the first line of text from STDOUT when it notifies contacts about potential problems. If you print multiple lines, you're out of luck (though this will be a feature of Nagios 3). Remember, keep your output short and to the point.

Excessively long plugin output like that will either crash functions or get cut off. ndoutils cuts it off after 8k. In the last update I cut it off after 6k, however it appears I should have cut it off shorter.

If you want you can test a fix in the following file (make a backup copy first):
/usr/local/nagiosxi/html/includes/utilsx.inc.php

line 64 Change to:

if($length > 1000)
{
//split huge string into 2 to prevent memory crashing errors in apache
$string1 = substr($string,0,1000);
$max = ($length > 2000) ? 2000 : $length; //set max length to 2k.
$string2 = substr($string,1000,$max); //ndoutils cuts off data after 1k

Output is from check_wmi_plus.pl. Actually took me two days to isolate what was causing XI to sit and spin. Would prefer error checking in php since you never know what crash debug gigo return could be coming in. Having XI not being able to even list the problem is a problem. The php crash was the service status list. This page only needs the first line so why read anything past the first line? Checking for buffer overflow and illegal chars is also good.

Looking at the xmlentities function I might suggest something cleaner. If preg_match_all crashes on large strings split the string into 1k pieces with a while loop, run regex on them and collect into another string.

Once able to identify what the problem was I solved it on that machine so the application log no longer contains those error messages which also got XI working again.

I am putting in your current fix hoping to avoid what was happening for the last couple of days.

The crash happens before it gets to be processed for the service status page. The same backend data call is made for both the service status table and the individual service status details page. We have users who wish to have longer plugin output displayed (log monitoring for example).

What you're describing is a better fix for this issue. I'll add it to my TODO list. I had it splitting at 3k, but it looks like I need to break it down smaller.

I am curious what that regex actually does? Seems interesting but my regular expessions are so rusty?

In my morning bathroom mediation on the matter splitting on linebreak or maxline len so as not to split any multibyte matches. Having a maxbuffersize (to limit regex pasing) and maxreturnsize (to crop output at idk 8K).

That horrible and excessively long regular expression is to protect against characters outside of the ASCII table. We had that issue last fall where plugins were returning bad characters and breaking the XML. : )

If that regex is a complicated pattern match used restrict to ascii and it's causing the segment fault maybe something simpler would work.
Don't know php so excuse my syntax

function simplyclean(buf)
tmpbuf=""
for i = 1 to len(buf)
c=asc(substr(buf,i,1))
if c > 31 and c < 127 then
tmpbuf = tmpbuf + c
end if
next i
simplyclean=tmpbuf
end function

Most of the character-level cleaning tricks I'm finding still require the use of one of the preg_match functions. I'll do some poking around on it though.