[dev.icinga.com #7354] Disable immediate hard state after first checkresult

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/7354

Created by arcade on 2014-10-08 11:53:54 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2016-08-04 15:30:04 +00:00)
Target Version: 2.5.0
Last Update: 2016-08-08 11:14:21 +00:00 (in Redmine)

Icinga Version: 2.4.10

---

It would be nice that when you configure a new service/hostcheck and this check returns something different than "OK/UP" for the first checkresult, the service/host should stay in a soft state and not switch to a hard state immediately as it does now.

The same behaviour as it already is in Icinga 1, even though the first checkresult fails, it has to reach the max_check_attempts before the service/host switch to a hard state.

Changesets

2016-08-04 14:16:58 +00:00 by mfriedrich 3f89a6d

Disable immediate hard state for first check result

fixes #7354

---

Relations:

• duplicates #7354

[icinga-migration]

Updated by mfriedrich on 2014-11-24 13:18:08 +00:00

• Target Version set to 2.3.0

[icinga-migration]

Updated by gbeutner on 2015-01-08 12:19:30 +00:00

• Target Version deleted 2.3.0

[icinga-migration]

Updated by mfriedrich on 2015-09-05 15:26:49 +00:00

• Category changed from Notifications to libicinga
• Status changed from New to Feedback
• Assigned to set to arcade

Does that still happen with 2.3.9?

[icinga-migration]

Updated by arcade on 2015-09-07 06:45:28 +00:00

Yes, this still happens with 2.3.9

[icinga-migration]

Updated by mfriedrich on 2015-09-07 08:34:02 +00:00

• Status changed from Feedback to Assigned
• Assigned to changed from arcade to mfriedrich

[icinga-migration]

Updated by mfriedrich on 2015-09-07 09:27:06 +00:00

I'll have a look, thanks.

[icinga-migration]

Updated by mfriedrich on 2016-03-04 15:30:32 +00:00

• Parent Id set to 11310

[icinga-migration]

Updated by mfriedrich on 2016-03-11 08:39:20 +00:00

        if (!old_cr) {
                SetStateType(StateTypeHard);

If we change that behaviour, we must

1. add it to the changelog
2. check whether this solves problems with passive check results and their first result for a !OK hard state notification

[icinga-migration]

Updated by mfriedrich on 2016-08-04 13:52:48 +00:00

• Tracker changed from Feature to Bug
• Target Version set to 2.5.0
• Icinga Version set to 2

Can be reproduced with max_check_attempts = 2 and a passive check result on a pending host check.

This immediately changes to a hard state, but does not trigger any notifications (it is not recognised as hardStateChange). Since this affects the way how users tend to interpret notifications from hard states (no notification was sent even if the web interface says "HARD 1/2") I'm changing this behaviour with 2.5.

I'm testing this as part of resolving the remaining notification issues, currently with #10363.

[icinga-migration]

Updated by mfriedrich on 2016-08-04 15:30:05 +00:00

• Status changed from Assigned to Resolved
• Done % changed from 0 to 100

Applied in changeset 3f89a6d.

[icinga-migration]

Updated by mfriedrich on 2016-08-08 11:14:22 +00:00

• Parent Id deleted 11310

[icinga-migration]

Updated by mfriedrich on 2016-08-08 16:01:33 +00:00

• Duplicated set to 11697