Determining the success or failure of externalcommands

Scott Sanders lists at jssjr.com
Thu Jan 24 18:01:23 CET 2008


I have been digging though commands.c to see what I can find out. One thing
that stands out is that Nagios 2.x calls process_external_command() which
has a void return, and Nagios 3.x calls process_external_command1() which
returns an int. It seems the 3.x implementation is, in fact, checking for
errors in the command its attempting to process and will return -2 if it
encounters any problems. This would be quite helpful in determining the
status of a submitted command, but unfortunately the return value of both
check_external_command1() and check_external_command2() is never considered
by the calling function. Because of this, commands that are malformed or
have other issues are silently ignored and check_for_external_commands()
will always return OK. It seems like some effort was put into better error
handling in the external command algorithm, but the changes don't seem to
actually have any effect. I'm curious as to why this is, as it affects the
code I am adding to track the progress of an external command from
submission to completion.

Thanks,

-Scott

On 1/23/08, Marc Powell <marc at ena.com> wrote:
>
>
>
> > -----Original Message-----
> > From: nagios-users-bounces at lists.sourceforge.net [mailto:nagios-users-
> > bounces at lists.sourceforge.net] On Behalf Of Scott Sanders
> > Sent: Wednesday, January 23, 2008 8:39 AM
> > To: nagios-users at lists.sourceforge.net
> > Subject: Re: [Nagios-users] Determining the success or failure of
> > externalcommands
> >
>
>
> > nagios.cmd pipe. In order for the external command functionality to
> work
> > the way I intend, I need to obtain a response from nagios so my server
> can
> > respond back to the client with the results of processing the external
> > command. I am really hoping there is an easy way to do this, as
> replacing
> > the nagios.cmd file with something besides a FIFO pipe requires
> > modification to the nagios source and is something I was trying to
> avoid.
>
> Nagios was never designed to provide status back to a script submitting
> a command to the external command pipe because it is not a real-time
> operation and the commands should always succeed (why wouldn't they?).
> The command may not be read for quite some time after it's submitted,
> depending on what nagios is doing at the time.
>
> As for logging, Nagios assumes that all external commands succeed and
> logs nothing unless the command is malformed. There is additional
> logging that is available by running nagios in DEBUG3 but that still
> doesn't indicate success or failure. commands.c handles external
> commands. I'd suggest you start there and add in what additional logging
> you feel you need.
>
> --
> Marc
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS when
> reporting any issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20080124/9133b7b4/attachment.html>
-------------- next part --------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null


More information about the Users mailing list