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.

Sign up for GitHub

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

Jump to bottom

[dev.icinga.com #6959] Scheduled start time will be ignored if the host or service is already in a problem state #1899

Closed
icinga-migration opened this issue Aug 19, 2014 · 13 comments
Closed

[dev.icinga.com #6959] Scheduled start time will be ignored if the host or service is already in a problem state #1899

icinga-migration opened this issue Aug 19, 2014 · 13 comments
Labels
bug Something isn't working
Milestone
2.3.0

Comments

@icinga-migration
Copy link

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

Created by jmeyer on 2014-08-19 12:49:36 00:00

Assignee: gbeutner
Status: Resolved (closed on 2015-02-25 14:25:04 00:00)
Target Version: 2.3.0
Last Update: 2015-02-25 14:25:04 00:00 (in Redmine)

Icinga Version: v2.2.0-480-g3c6ca29
Backport?: No

When sending a command to schedule a downtime in the future while a host or service is currently in problem state, causes icinga2 to put the respective host or service instantly into downtime. I'd expect icinga2 to respect the start time given as parameter in the command, which it doesn't.

Sent command:

[1408451333] SCHEDULE_HOST_DOWNTIME;test-down-3;1408453200;1408456800;1;0;0;jdoe;test

1408451333: 2014-08-19 12:28:53 (test-down-3 was DOWN at this time.)
1408453200: 2014-08-19 13:00:00
1408456800: 2014-08-19 14:00:00

Result:

The host was put in downtime by icinga2 just after the command has been accepted. (Note the value of the column "actual_start_time"!)

select object_id, is_in_effect, scheduled_start_time, actual_start_time from icinga_scheduleddowntime;

 ----------- -------------- ---------------------- --------------------- 
| object_id | is_in_effect | scheduled_start_time | actual_start_time   |
 ----------- -------------- ---------------------- --------------------- 
|        54 |            1 |  2014-08-19 13:00:00 | 2014-08-19 12:32:06 |
 ----------- -------------- ---------------------- ---------------------

Note: The column icinga_hoststatus.scheduled_downtime_depth has not been updated.

Changesets

2015-02-25 14:19:50 00:00 by (unknown) c86b171

Make sure that the scheduled start time for downtimes isn't ignored

fixes #6959
@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-02-09 09:35:29 00:00

  • Status changed from New to Feedback
  • Assigned to set to jmeyer

Can you re-test this with the current git master?

@icinga-migration
Copy link
Author

Updated by jmeyer on 2015-02-09 13:02:17 00:00

  • Status changed from Feedback to New
  • Assigned to changed from jmeyer to mfriedrich

I've successfully reproduced it with version v2.2.0-367-g173f524. I was unable to test the current release due to #8398 though.

@icinga-migration
Copy link
Author

Updated by jmeyer on 2015-02-17 09:26:18 00:00

  • Description updated
  • Priority changed from Normal to High
  • Icinga Version changed from 2 to v2.2.0-480-g3c6ca29

@icinga-migration
Copy link
Author

Updated by jmeyer on 2015-02-17 09:26:39 00:00

  • Assigned to deleted mfriedrich

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-02-20 09:15:16 00:00

  • Priority changed from High to Normal

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-02-20 09:16:18 00:00

  • Status changed from New to Feedback
  • Assigned to set to mfrosch

lazyfrosch: Is this something we want for 2.3?

@icinga-migration
Copy link
Author

Updated by mfrosch on 2015-02-23 08:50:41 00:00

  • Status changed from Feedback to Assigned
  • Assigned to changed from mfrosch to gbeutner
  • Target Version set to 2.3.0
  • Backport? changed from __ to Yes

Well this seems like an odd bug.

Any problem with fixing this?

Pls backport if possible, at least so it is in the branch.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-02-23 08:51:44 00:00

What exactly do you mean by backport? There aren't currently any plans for another 2.2.x version (i.e. 2.2.5).

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-02-23 08:59:21 00:00

  • Status changed from Assigned to New
  • Assigned to deleted gbeutner

Please don't assign issues, we'll deal with that ourselves :)

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-02-25 11:54:18 00:00

  • Status changed from New to Assigned
  • Assigned to set to mfriedrich

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-02-25 14:19:15 00:00

  • Assigned to changed from mfriedrich to gbeutner

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-02-25 14:19:36 00:00

  • Backport? changed from Yes to No

Setting backport to 'No' because there's no 2.2.5.

@icinga-migration
Copy link
Author

Updated by Anonymous on 2015-02-25 14:25:04 00:00

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

Applied in changeset c86b171.

@icinga-migration icinga-migration added bug Something isn't working libicinga labels Jan 17, 2017
@icinga-migration icinga-migration added this to the 2.3.0 milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
2.3.0
Development

No branches or pull requests
1 participant
@icinga-migration