patch for nagios 3rc1 - update

John Calcote john.calcote at gmail.com
Mon Jan 21 04:21:35 CET 2008


Hello again.

I'm sorry to do this, as it's rather embarrassing, but I've got a small 
update to the patch I submitted earlier. This version has two 
differences from the first patch I sent:

1. Most of the check_results_info structure initialization has been 
moved back above the broker INITIATE call. I found that I needed to use 
some of the fields in that global structure from within my INITIATE 
handler - mostly this is data that a proper handler needs to track for 
final results submission, but it's not passed any other way. I'll send 
another message later to discuss this in more detail.

2. I actually fixed the minor memory leaks that I mentioned in my 
previous note. ;) I guess I forgot to put those in before creating the 
patch.

Thanks for your patience,
John

John Calcote wrote:
> Hi!
>
> I've recently joined the Distributed Nagios eXecutor (DNX) team (Oct 
> '07), and have just gotten around to porting DNX over to Nagios 3.
>
> I've been looking at nagios-3.0rc1, and I can see that a new type of 
> NEBCALLBACK event has been added - 
> NEBTYPE_SERVICECHECK_ASYNC_PRECHECK. I also note that the run-time 
> semantics of NEBTYPE_SERVICECHECK_INITIATE have been modified between 
> Nagios 2.x and 3.x. That is, the INITIATE check no longer honors the 
> handler's return code.
>
> I have a small wish in the form of a patch to nagios-3.0rc1 that I 
> would like to suggest. I hope you'll find this change reasonable. The 
> patch simply moves the call to broker_service_check( 
> NEBTYPE_SERVICECHECK_INITIATE, ... ) above the code that configures 
> the temporary check output file and check_results_info structure. This 
> puts the broker call in a similar relative position in 3.x code as in 
> 2.x code, except for the check_result_info structure initialization, 
> which didn't really have to be done before the broker call anyway. In 
> addition, I moved the code that honors the CALLBACKOVERRIDE return 
> value down to the INITIATE check, but left the code that honors the 
> newer CALLBACKCANCEL in the ASYNC_PRECHECK check.
>
> This grants two advantages that I can see:
>
> 1. It makes Nagios 2.x modules more portable because Nagios 3.x would 
> honor the same NEB module return values they did in Nagios 2.x code 
> for the INITATE check. In addition, it provides the useful ability for 
> Nagios 3.x modules to cancel a check in the PRECHECK handler where it 
> makes sense to do very little preprocessing before canceling the 
> check; cancelling the check in the INITIATE handler is less efficient.
>
> 2. NEB modules that want to handle the check themselves with the 
> CALLBACKOVERRIDE return value are going to have trouble processing 
> macros the same way that Nagios does, unless Nagios provides some API 
> routines to do it for them. It makes more sense (IMHO) to have the 
> CALLBACKOVERRIDE honored by the INITIATE check, rather than the 
> ASYNC_PRECHECK check.
>
> I'm hoping (if you all approve of this change), that we can get it 
> into the Nagios 3.0 code base before 3.0 ships. Would it be too late 
> for that?
>
> Regards,
> John
>
> PS. The patch also fixes a minor error path memory leak, where the 
> raw_command string was not being freed in case of an out-of-memory 
> condition while allocating the processed_command buffer.
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: nagios-3.0rc1-dnx.patch
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20080120/fa61e77c/attachment.ksh>
-------------- 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-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel


More information about the Developers mailing list