passive checks and check_command
tvilliers
tvilliers at lastminute.com
Mon Oct 13 11:51:38 CEST 2003
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
More information about the Developers
mailing list