passive checks and check_command

[Stanley Hopcroft]

Dear Sir,

I am writing to thank you for your letter and say,

On Mon, Oct 13, 2003 at 10:51:38AM +0100, tvilliers wrote:
> 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).
> 

that unfortunately I am not being as clear as necessary here.

I hope after one last more attempt at doing so that someone else will
provide a more comprehensible response.

The command is _never_ scheduled by Nagios; freshness checking is
concerned with the age of the last passive check result and in some
cases (traps especially) is completely unecessary (freshness checking is
only useful if you expect your passive service check result to arrive,
perhaps periodically in the case of backup checks).

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

The check command is required for Nagios to acept the command
definition. Without the check command your configuration will be
rejected. 

As I tried to indicate formerly, I think the requirement simplifies the
Nagios coding at the expense of confusing some of those who use passive
service checks.

However, having a check command is useful for passive service checks
that are aperiodic (asynchronous or may not happen at all. I will
delighted to never see a newRoot trap for example or a 'Backup PSU
failed' trap) because it allows the CGI displays to be reset by an
operator without waiting for what may be a non existent event (such as a
trap indicating that the former root of the Spanning Tree [of a network
of Layer 2 switches] is now the current root).

However, as you point out there is no semantic requirement that the
check command be meaningfull.

If the parser will accept a string of blanks or a not very helpful
check_command (eg check_dummy) and you have no requirement to reset the
check result other than by manually submitting a passive service check
result from the CGIs (this takes longer than reecheduling a service
check), then go ahead and use a null or dummy check command.

To sum up, if you have passive services that represent asynchronous
events, defining a check command facilitates resetting the CGI
displays. 

> 
> 
> Tielman de Villiers

Yours sincerely.


-- 
------------------------------------------------------------------------
Stanley Hopcroft
------------------------------------------------------------------------

'...No man is an island, entire of itself; every man is a piece of the
continent, a part of the main. If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friend's or of thine own were. Any man's death diminishes
me, because I am involved in mankind; and therefore never send to know
for whom the bell tolls; it tolls for thee...'

from Meditation 17, J Donne.


-------------------------------------------------------
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