HOST max_check_attempts set to 1 goes SOFT and then HARD, extra check is performed about nagioscore HOT 8 CLOSED

Hi @tmcnag ,

We develop a monitoring solution and we have about 2 thousand nagios servers in production with a centralized configuration UI . We are updating from nagios 3.5 to nagios 4.2.1. The change that @box293 is talking about isn't written in any release note (at least I don't see it...). So, the change have silently modified the behavior of all updated nagios servers already in production.

Can you please explain in more details why we have to wait for a major version (5.0?)?
Those updating from nagios 3.5 would have a bad surprise when they discover this. Our configuration UI is now incoherent with the updated behavior (it is now impossible to disable retry attempt even if we set the max_check_attemps to 1. In that case there should be only one attempt without retry).

I think it should be modified soon in a minor version. Or at least, please "make this a configuration option" to keep the nagios 3.5 behavior.

Thank you.

from nagioscore.

This was never addressed, just closed by jfrickson

I believe this forum post is directly related and @tmcnag's fix would solve the issue
tmcnag@2f26316

from nagioscore.

Implemented and tested the fix in 4.1, but observed that the buggy behavior was present in both 4.0.8 and 4.1 so it made no sense fixing it for 4.0.8. Didn't notice any side effects, but it was on a toy system so there might be some interesting ramifications e.g. notifications and event handlers.

from nagioscore.

In discussion with tmcnag and scottwilkerson, we decided that this change has potential wide-ranging effects, so it should go in (if at all) with a major release, such as 5.0. The issue will remain open, but the pull request has been closed.

from nagioscore.

To clarify, the changes would mostly be related to escalation and event handler logic. Implementing my change would potentially introduce an off-by-one situation with certain installs that use the aforementioned features. Someone expecting the HARD state to come after the SOFT state might have implemented an event handler that deals with the SOFT state in a certain way, and this change would prevent that from ever happening.

In keeping this issue open, if anyone is interested I can always make this a configuration option. This would increase config file bloat a bit, but if there is enough interest it might be worth discussing.

from nagioscore.

@tmcnag if you need any assistance from us for this issue, we are at your disposal.

from nagioscore.

@Coservit For clarification, the changes I made were to my own repo and were never merged into Core proper. I never even made the pull request. Memory did not serve me well. The request was made but never accepted. If you are experiencing the described behavior, you must be running my fork of Core.

from nagioscore.

This has been fixed in 4.4.0. I forget the commit exactly, but you can see it in base/checks.c in the function host_state_or_hard_state_type_change.

from nagioscore.