[dev.icinga.com #5671] Passive check result processing for host checks is not working

[icinga-migration]

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

Created by mhoyer on 2014-02-18 10:51:24 +00:00

Assignee: (none)
Status: Resolved (closed on 2014-03-03 19:36:54 +00:00)
Target Version: 1.11
Last Update: 2014-03-03 19:36:54 +00:00 (in Redmine)

Icinga Version: 1.10.3
OS Version: Scientific Linux 6.5

---

Hello,

I recently updated our testing environment from Icinga 1.10.1 to 1.10.3 and our integration tests came up with an error. Flagging a host as "Down" using passive check results is not working any more.

Issued in icinga classic gui the "submit passive check result for this host" button sets status_code to 1. This leads to a host-down state in icinga 1.10.1 but not in 1.10.3. Looking at the logs it seems as if the passive check result is lost on interpretation.

Icinga 1.10.1
[1392719577] EXTERNAL COMMAND: PROCESS_HOST_CHECK_RESULT;devfoo01;1;DOWN|
[1392719582] PASSIVE HOST CHECK: devfoo01;1;DOWN
[1392719582] HOST ALERT: devfoo01;DOWN;HARD;1;DOWN

Icinga 1.10.3
[1392719768] EXTERNAL COMMAND: PROCESS_HOST_CHECK_RESULT;devfoo01;1;DOWN|
[1392719774] PASSIVE HOST CHECK: devfoo01;0;DOWN

This behavior matches documentation at http://docs.icinga.org/latest/de/pluginapi.html in "11.1.3. Return-Code". But without changing anything at the parameter "use_aggressive_host_checking=0", the behavior changed on update.
I also don't unterstand the reason for this differenciated behavior. Why is warning state processed as down or up depending on this parameter?
Nevertheless it might be a good idea for icinga classic gui to use status_code 2 to flag a host as down using the gui tools.

Kind regards
Marco Hoyer

Changesets

2014-02-18 12:03:36 +00:00 by (unknown) edc4645

Revert "Fix host state translation for passive host check results."

This reverts commit bccaea83e6536f3ac8dcc24a8b9547b67ed5407e.

Refs #5575
Refs #5671

2014-03-03 19:33:46 +00:00 by (unknown) 91e5d6e

Revert "Fix host state translation for passive host check results."

This reverts commit bccaea83e6536f3ac8dcc24a8b9547b67ed5407e.

Refs #5575
Refs #5671

2014-03-03 21:34:07 +00:00 by (unknown) 2e60399

Update Changelog/THANKS.

Refs #5671
Refs #5687
Refs #5688
Refs #5687
Refs #5698
Refs #5684
Refs #5691

2014-03-27 22:53:44 +00:00 by (unknown) 4ae54be

Update Changelog.

Refs #5873
Refs #5698
Refs #5687
Refs #5671
Refs #5776
Refs #5777

---

Relations:

• relates #5575

[icinga-migration]

Updated by mhoyer on 2014-02-18 10:57:04 +00:00

this might result from the following change:
https://dev.icinga.org/issues/5575 ?

[icinga-migration]

Updated by mfriedrich on 2014-02-18 11:12:06 +00:00

• Project changed from Web to Core, Classic UI, IDOUtils
• Status changed from New to Feedback
• Priority changed from Urgent to Normal

I fail to see how that is not working. #5575 fixes a long lasting bug improperly handling passive check results for host checks allowing users to set "1" without re-interpretation for host check results by the core itself.

[icinga-migration]

Updated by mhoyer on 2014-02-18 11:25:37 +00:00

Hi dnsmichi,
a correlation with bug 5575 was only a guess.
As stated in the log output, a host-check passive result with statuscode 1 resulted in a host down state in 1.10.1 but not in 1.10.3. I don't unterstand the dependency to "use_aggressive_host_checking" and the different behavior at all. If this is necessary and useful at all, icinga classic gui should send statuscode 2 instead of 1 for host-down flagging. This feature is broken now.

[icinga-migration]

Updated by mfriedrich on 2014-02-18 12:07:47 +00:00

• Target Version set to 1.11

Ok. So the external commands are treated as passive checkresults, and they already provide the translated state. The plugin api reference is invalid, that's just true if the plugin is executed by the core itself.
Though the external command api documentation is correct when telling 0..UP, 1..DOWN, 2..UNREACHABLE as integers passed to the command sending passive check results to the core.
The initial origin of #5575 were wrongly provided passive checkresults by the mod_gearman dup_server feature and presumingly it's a bug in that addon then not providing already translated host states.
So you're right in terms of the change. I've reverted that patch in git next for further tests.

[icinga-migration]

Updated by mfriedrich on 2014-03-03 19:36:54 +00:00

• Category set to Passive Checks
• Status changed from Feedback to Resolved
• Done % changed from 0 to 100