Page 1 of 1

Blindfold attempt at fixing same-host dependencies - don't try this

Posted: Thu Sep 03, 2009 2:13 am
by Guest
This is a multi-part message in MIME format.
--------------030605000809070208020204
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/09/09 09:46 PM, Mathieu Gagné wrote:
> Hi,
>
> On 9/2/09 9:28 PM, Thomas Guyot-Sionnest wrote:
>> In the patch I'm talking about you would still need a host_name or
>> hostgroup_name directive - usually the same one that is defined on any
>> of your NRPE service definition. I don't see why you would want to take
>> it out either...
>>
>> i.e.:
>>
>> define service {
>> hostgroup_name linux-servers
>> service_description NRPE
>> blah blah blah...
>> }
>>
>> define service {
>> hostgroup_name linux-servers
>> service_description Load
>> servicegroups nrpe-services
>> blah blah blah...
>> }
>>
>> define servicedependency {
>> hostgroup_name linux-servers
>> service_description NRPE
>> dependent_servicegroup_name nrpe-services
>> execution_failure_criteria n
>> notification_failure_criteria c,u
>> }
>>
>> Then on each host, "Load" (and any other service in nrpe-services)
>> becomes dependent of NRPE on the same host. Is that working?
>
> I don't see any patch. I tried what you suggested with Nagios 3.0 and
> all NRPE based services are now depending on all NRPE services on ALL
> hosts. (ie. "Load" on host "hostA" would depends on "NRPE" on "hostA",
> "hostB", "hostC", etc.)

The patch I'm talking about is in Nagios 2.x, and is very much like the
one that made it for 3.0.0. The code has been refactored right after the
same-host patch got in and I haven't read it enough to fully understand
it, but it do work the same way at least for me:

define servicedependency {
hostgroup_name hg1,hg2,hg3
service_description NRPE Daemon
dependent_service_description svc1,svc2,scv3
notification_failure_criteria c,u
}


> You should try it and see the result on this page:
> /nagios/cgi-bin/config.cgi?type=servicedependencies

Works for me, but looking at the Nagios code it indeed looks like the
behaviour is not retained with servicegroup dependencies (only service
dependencies). That part looks odd and redundant to me, but there was
surely a reason for that.

Unfortunately since development wasn't test-driven at that time it will
be hard to figure out what was the issue and make sure any change do not
create regressions.

I attached a totally blindfolded attempt at fixing it; feel free to try
it out.

> I already tried all combination before asking the mailinglist and
> writing the patch.

> I also don't see the need to include a "host_name" or "hostgroup_name"
> directive for this purpose. The host the service is running on is
> already available in the service definition itself expanded from the
> "dependent_servicegroup_name" directive.

Well, that's how it was done... similarly I don't see the need to
*remove* both directive as only one of them is redundant.

More seriously, the single-host method has been around for some time, so
it will certainly not change now!

- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKnzRC6dZ+Kt5BchYRAkCmAKDvrQ5enmPA5hH0meaAbrucvIsIMQCcDCj1
cIPrSHNqiN9Efe7dGpLIyy8=
=y5CT
-----END PGP SIGNATURE-----

--------------030605000809070208020204
Content-Type: message/rfc822;
name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Attached Message"

X-Account-Key: account2
X-Mozilla-Keys:
Return-Path:
Delivered-To: [email protected]
Received: (qmail 26807 invoked by uid 89); 3 Sep 2009 03:06:25 -0000
Received: by simscan 1.2.0 ppid: 26796, pid: 26798, t: 0.6982s
scanners: regex: 1.2.0 attach: 1.2.0 clamav: 0.95.2/m: spam: 3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10)
X-Spam-Level:
X-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00 autolearn=disabled
version=3.2.

...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]