Patch for Plugin "No Output"

[Thibault Genessay]

Hi

bobi at netshel.net wrote:
> Hi All,
> 
> Like everyone else, we've had our fair share of mysterious plugin "(No
> output!)" messages.
> 
> Sometimes this error is due to the plugin failing and only writing
> diagnostics to stderr (and nothing is written to stdout.)
> 
> Also, as everyone knows, Nagios only reads the first line of
> newline-terminated output from a plugin and throws the rest away.  But,
> what if the first line is just a new-line and the good stuff is on a
> subsequent line?

Then it's not good stuff; good stuff is on the first line of stdout *only*.

> Yes, I know - fix your plugin to output only to the first line.
> 
Exactly :)


> But being a lazy programmer, I am thinking, why not just have Nagios be a
> little more forgiving and inquisitive and keep searching stdout until it
> finds the first non-empty line?  Is that so bad?  Or is it a feature?
> 

Small scripts, writen once, executed once, can be lazily coded. However, 
applications running for a long time (e.g. daemons) should be very 
carefully coded.

> Well, you can be the judge.
> 
> Anyway, I put together this patch for checks.c - it modifies the plugin
> output handling logic in the following manner:
> 
> 1. As usual, it reads plugin output from stdout.
> 
> However, if the first line is empty, it keeps reading until it gets a
> non-empty line or EOF.
> 
> If it gets a non-empty line, then that first non-empty line becomes the
> plugin output.
> 
> 2. However, if it really gets no output from stdout (i.e., nothing or all
> empty lines,) then it reads the plugin's stderr and returns the first
> non-empty line it finds.
> 
> 3. If it gets nothing from stderr as well, then it finally returns
> everyone's favorite diagnostic: "(No output!)"
> 

Taking your approach, this is certainly a good algorithm.

> You know, we should really change that diagnostic to: "(No output!  Have a
> nice day!)"
> 

This would make our favorite admins' days easier sometimes :)

> 
> Anyway, I'd be very interested in any alternate suggestions, good
> comments, insightful observations or even witty reparte'.
> 
> BTW, in order to provide the ability to read both stdout and stderr from a
> plugin sub-process, I've written my own version of the standard C popen(3)
> function called pfopen().  I did this because this is the problem with the
> standard popen(3) function - it only return stdout to the parent process,
> which may only give you half the story since it ignores all potentially
> usefull diagnostic info from the stderr of the child process.
> 
That's an interesting piece of code. I'll keep it somewhere, just in case


Your patch would certainly work but I would not like it to be part of 
the tree as is. The basic idea (to help with plugin debugging) is good 
but the solution is, imho, not the best.

There is a specification. This specification states that the output of 
the plugin is the first line and only the first line of the standard 
output. This, and the return code of 0,1,2 or 3 is the only thing that a 
plugin should respect.
Any plugin that does not respect that is flawed, that's it. Fix it or 
throw it away, but it is not Nagios' responsibility to take care of the 
well-formedness of its output.

Programs and standards are like fluids in balloons. Grow the balloon and 
the fluid will expand (so you can't shrink it back). The entropy always 
grows.
See what happened with the web "standards". The browser tolerate 
incorrect pages, so designers don't worry, they feel free not to close 
tags and such -- and because the browser accepts, they sometimes don't 
even know they are doing wrong.
Now the web is the biggest headache producer among developers, because 
trying to get this div show the same under Firefox, IE and Opera takes 2 
hours where it should have taken 2 minutes if the W3C standards were 
respected.

If the standard is bad, change it. Otherwise rewrite the faulty plugin.

Otoh, it *is* useful to have the output of the following lines and that 
of stderr. This is where your patch should be patched. It should put an 
horrible warning, maybe even return code 3, and then display the nth 
line of stdout/stderr that it has found, like:

THINGY UNKNOWN - (Invalid output!) - blah blah

where blah blah is the said output.

This way, one can debug the plugin, but it is so awful in the interface 
that one is forced to fix the actual source of the problem. Everybody is 
happy, standards are enforced and smiles appear on all IT staff's faces.


-- 
Thibault GENESSAY
ALIADIS
www.aliadis.fr
Tel.  +33 4 72 13 90 40
Fax   +33 4 74 22 00 09

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642