Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #4734] Wrongly calculated last_hard_state on service if host ist down #1342

Closed
icinga-migration opened this issue Sep 24, 2013 · 4 comments

Comments

@icinga-migration
Copy link

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

Created by tgelf on 2013-09-24 12:27:36 +00:00

Assignee: (none)
Status: New
Target Version: Backlog
Last Update: 2015-05-18 12:17:49 +00:00 (in Redmine)

Icinga Version: 1.7.2
OS Version: Any

A service state is immediately HARD in case it's host is not UP. It doesn't matter whether the host is in a soft or hard state. In such a situation (happens all the time when a host goes down) last_hard_state is wrong and shows the current_hard_state instead of the last one.

I tried to simulate this with passive check results:

Given that:

Host 'host' is UP (hard state)
Service 'PING' is OK (hard state)

...I'm sending passive check results:

EXTERNAL COMMAND: PROCESS_HOST_CHECK_RESULT;host;1;Fake Host DOWN
EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;host;PING;2;Fake Service CRIT

I check the statehistory in the IDO:

+------+-------+------------+-----------------+--------------------+
| type | state | last_state | last_hard_state | output             |
+------+-------+------------+-----------------+--------------------+
| hard |     2 |          0 |               2 | Fake Service CRIIT |
| hard |     1 |          0 |               0 | Fake Host DOWN     |

And the current state:

icinga_servicestatus:
           output: Fake Service UNKNOWN
    current_state: 2
  last_hard_state: 2

Expected last_hard_state would be 0. It behaves correct in case the host is NOT down and the service regularly reaches it's max_check_attempts. Please note that while showing IDO data in my believes this is a core issue.

IMHO core behaviour is clearly wrong here. This has severe impacts on availability reports and leads to ugly workarounds.

Regards,
Thomas

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2014-03-12 22:34:55 +00:00

  • Category set to Check Results
  • Status changed from New to Assigned
  • Assigned to set to mfriedrich

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2014-07-19 12:14:49 +00:00

  • Status changed from Assigned to Feedback
  • Assigned to deleted mfriedrich
  • Priority changed from High to Normal

No idea how to fix it. Leaving it open for proposed patches, if none, I'll close it.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-03-12 19:11:58 +00:00

  • Status changed from Feedback to New

@icinga-migration
Copy link
Author

Updated by berk on 2015-05-18 12:17:49 +00:00

  • Target Version set to Backlog

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants