[Nagiosplug-devel] max_state logic?

[Thomas Guyot-Sionnest]

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

On 19/09/07 06:55 AM, John P. Rouillard wrote:
> In message <C310E149-07FF-4BFE-B0E5-2173A5D55E59 at altinity.com>,
> Ton Voon writes:
>> On 19 Sep 2007, at 08:13, Thomas Guyot-Sionnest wrote:
>>> I was trying to replicate max_state from utils.c in Perl, but the  
>>> logic there seems broken:
>>>
>>> int
>>> max_state (int a, int b)
>>> [...]
>>> Given that, OK + UNKNOWN or OK + DEPENDENT will always return OK. Is
>>> that right? IMO the OK test should be moved at the end.
>>>
>> Yes, that does look broken. I think DEPENDENT was a really old state,
>> which I don't think should be used anymore, though I can see it is
>> used in check_http and check_snmp. Anyone know the history of this?
> 
> Is state dependent = 4? 

Correct.

> IIRC in nagios, there are 5 states 0-4. State 4 was the code that was
> used for B when host A is the parent of B and A is down
> (I.E. reachability of B depended on A). But I think the state was
> called unreachable or some such. I am not sure if a plugin can return
> that, or if it was an internal nagios only thingy.

It is an "internal" thingy, though it could end up in checks like
check_cluster which re-use Nagios status codes! I think the safest
option is not to narrow our use_case to only know cases and keep it.

Also I wasn't thinking about the other non-0 values. At the end it takes
the max value of both parameters. If I remove the "OK" check then it'll
do like the Perl example I sent (return higher non-0 before OK) while
leaving the "OK" check before it will make it use out-of-bound values
only if there's no OK state. A conservative thinking dictates me that
any non-0 value is worse than OK so we're better let Nagios complain
about it than ignore it (in other words we'd let max(a,b) deal with OK
states).

Any objections?

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

iD8DBQFG8QdO6dZ+Kt5BchYRAsMjAKDtqYAduPJZAwl8PIguZk2GbYk21QCfeybl
S/cggnTKxyH4sFtlxY5n89s=
=erD5
-----END PGP SIGNATURE-----