host checking logic

[Marc Powell]

> -----Original Message-----
> From: nagios-users-bounces at lists.sourceforge.net [mailto:nagios-users-
> bounces at lists.sourceforge.net] On Behalf Of Terry
> Sent: Thursday, October 11, 2007 10:54 AM
> To: Nagios Users mailinglist
> Subject: [Nagios-users] host checking logic
> 
> Hello,
> 
> I have a host that will not be reachable via icmp (check-host-alive).
> However, it will have services that are, check_tcp for example.


> I always assumed (ya, i know) that nagios assumed the host was up if
> it had services that were OK.  Obviously I am wrong or have something
> misconfigured.  How can I get around this issue?

It will assume the host is up if the very first check of a service on
that host is successful. After that, there are no further assumptions.
It would appear that you have had a service change state at some point,
forcing nagios to perform the failing host check. The service recovered
and nagios re-ran the host check to show proper host state, which again
failed. You end up with the service UP, host DOWN state. 

Your best option is to just change the host check_command to something
that does work, at least enough for you to be reasonably confident that
the host is up given your circumstances. check_tcp to a port you know to
be very reliable would be sufficient. Other options might be to use
check_dummy as the host check_command so that the state is always OK or
even to not perform host checks at all for this host.

--
Marc

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
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