Patch for Plugin "No Output"

[Thomas Guyot-Sionnest]

> -----Original Message-----
> From: nagios-devel-bounces at lists.sourceforge.net 
> [mailto:nagios-devel-bounces at lists.sourceforge.net] On Behalf 
> Of Thibault Genessay
> Sent: October 25, 2006 4:35
> Cc: nagios-devel at lists.sourceforge.net
> Subject: Re: [Nagios-devel] Patch for Plugin "No Output"
> 
> 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
> 

I fully agree with your position: Nagios should respect strict standards and
it's plug-ins that should be fixed.

I'm particularly worried in the case a nasty bug or unexpected exception
happen during the execution of a plug-in, and it end up printing empty lines
in an infinite loop (you talk about lazy programming, well lazy programming
CAN do that). If you must do this work in Nagios, then at least have a
maximum empty line number.

I'd personally prefer the solution of a wrapper plug-in that can takes some
options followed by the full check command line, run the check and then
return to Nagios one line of stdout and a valid return code. This as the
advantage of not modifying Nagios while having a great deal of flexibility.
For example you could have a parameter to say take only line x of STDOUT,
look only to STDERR of return some text in place of a No Output! Message.

Another option for such wrapper plug-in could be to limit the number of
characters, and could be very useful for running pager alerts when you don't
want big message to be split up as multiple SMS.

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3076 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20061025/0319c297/attachment.bin>
-------------- next part --------------
-------------------------------------------------------------------------
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
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel