Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
icinga-migration opened this issue Oct 8, 2014 · 12 comments

Comments

Projects
None yet
1 participant
@icinga-migration
Copy link
Member

commented Oct 8, 2014

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:

@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Nov 24, 2014

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

  • Target Version set to 2.3.0
@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Jan 8, 2015

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

  • Target Version deleted 2.3.0
@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Sep 5, 2015

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

This comment has been minimized.

Copy link
Member Author

commented Sep 7, 2015

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

Yes, this still happens with 2.3.9

@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Sep 7, 2015

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

This comment has been minimized.

Copy link
Member Author

commented Sep 7, 2015

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

I'll have a look, thanks.

@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Mar 4, 2016

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

  • Parent Id set to 11310
@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Mar 11, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Aug 4, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Aug 4, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Aug 8, 2016

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

  • Parent Id deleted 11310
@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Aug 8, 2016

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

  • Duplicated set to 11697

@icinga-migration icinga-migration added this to the 2.5.0 milestone Jan 17, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.