eventhandlers running when a dependent service dependency is not satisfied

[John P. Rouillard]

In message <4399FDB0.4080000 at ilm.com>,
Eli Stair writes:
>Thanks a million for pointing out the 'SCHEDULE_FORCED_SVC_CHECK', I'm 
>now rewriting and testing the event handlers to take care of this.  If 
>only there were a macro/variable of the master service... looking for a 
>lightweight way to determine the <service_description> to pass to the 
>macro that is the direct parent of the check that just failed.

One problem is that there can be multiple parents. It's a many to many
relationship. Parsing it from the objects cache is pain, but it works.
You could run a script that inverts the object.cache file for faster
lookup. Then your plugin runs the script which updates the cache only
if it is older than the object.cache then you query the inverted cache
file.

>WRT the SSH/SNMP dependency issue, I have a feeling that I'm missing 
>something here altogether, or didn't include enough info in my initial 
>report, as both you and Hugo mentioned a possible issue with this.
>
>To be clear, I'm doing this only so that if a dependent service IS down 
>(Ganglia) and SNMP has been shown to be up (after 
>'SCHEDULE_FORCED_SVC_CHECK',) I need to (or want to) make sure that SSH 
>is running before attempting to connect.  There are enough failure modes 
>that occur causing SSH to die at the same time as other services that I 
>want to avoid a bunch of high-latency/timeout/CPU event handlers running 
>if they are bound to fail.

SSH isn't required to do the monitoring. Its required for the
response. I would just handle the error in the event handler and
submit an apropriate passive response. Make the service have no valid
polling time and be volatile reporting only on wanrin and
critical. This will make errors in the event handler be reported.

				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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