passive checks and check_command

[tvilliers]

Thanks Stanley --

With this:

> 
> However, there is a benefit in having a legitimate command defined for a
> passive service in that service states that cannot otherwise be reset, can
> be reset by scheduling the passive service check with a command like
> 'ping'.

 ... I presume that the passive service has the "check_freshness" option
enabled -- as this is the only way that the "check_command" will actually
execute (at the stated "freshness_threshold" time).

So let me rephrase then: why is a "check_command" required for a passive
service which does not check for freshness? 


Tielman de Villiers








On Sat, 11 Oct 2003 10:26:20 +1000, Stanley Hopcroft wrote:

> Dear Sir,
> 
> I am writing to thank you for your letter and say,
> 
> On Fri, Oct 10, 2003 at 02:27:31PM +0100, tvilliers wrote:
>> 
>> Nagios requires that "check_command" exists in any defined service. With
>> passive services, a "check_command" is an anomaly, as the checking is
>> really done by the main engine at the specified command_check_interval
>> in the main config file.
>>
>>
> That is my understanding too.
> 
> 
>> Setting the check_command to "" (ie, a blank raw command line) is one
>> way to circumvent the requirement, but this is not mentioned explicitly
>> in the docs. Is this correct, and more importantly, why have such a
>> requirement in the first place with passive services?
>> 
>> 
> It's hard to answer without being the developer, but requiring a command
> definition for a passive service be the same as for an actively checked
> service eliminates any extra parsing requirements of the command file.
> 
> However, there is a benefit in having a legitimate command defined for a
> passive service in that service states that cannot otherwise be reset, can
> be reset by scheduling the passive service check with a command like
> 'ping'.
> 
> Some trap services (eg newRoot [of spanning tree]) fall into this
> category.
> 
> Without this handly little feature one could either
> 
> . submit a service check result - entering some soothing message manually.
> 
> . hack the mib to accept a bogon trap that will cause your trap handler to
> send an Ok and then use snmptrap or similar to send that bogon trap.
> 
> Scheduling a service check is simpler and faster.
> 
> 
>> Tielman de Villiers
> 
> Yours sincerely.




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php