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 #10843] DB IDO: downtime is not in effect after restart #3780

Closed
icinga-migration opened this issue Dec 15, 2015 · 14 comments

Comments

@icinga-migration
Copy link
Member

@icinga-migration icinga-migration commented Dec 15, 2015

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

Created by mhein on 2015-12-15 10:46:29 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2016-03-23 12:45:03 +00:00)
Target Version: 2.4.5
Last Update: 2016-04-20 08:15:51 +00:00 (in Redmine)

Icinga Version: 2.3.11
Backport?: Already backported
Include in Changelog: 1

Icinga Web 2 shows downtimes with time periods in the past as not running. The classic interface shows 'in effect'.

mysql> select * from icinga_scheduleddowntime where object_id=17214\G
*************************** 1. row ***************************
 scheduleddowntime_id: 30499
          instance_id: 1
        downtime_type: 1
            object_id: 17214
           entry_time: 2015-12-14 14:03:31
          author_name: k284323
         comment_data: Außer Betrieb
 internal_downtime_id: 2692
      triggered_by_id: 0
             is_fixed: 1
             duration: 0
 scheduled_start_time: 2015-12-14 14:02:18
   scheduled_end_time: 2015-12-21 10:02:18
          was_started: 0
    actual_start_time: 0000-00-00 00:00:00
actual_start_time_usec: 0
         is_in_effect: 0
         trigger_time: 0000-00-00 00:00:00
   endpoint_object_id: 1
1 row in set (0.00 sec)

Kind regards,

Marius

Attachments

Changesets

2016-03-23 12:42:00 +00:00 by mfriedrich 98e1d70

DB IDO: Fix that downtime is not in effect after restart

fixes #10843

2016-04-20 08:07:22 +00:00 by mfriedrich 1b69a7f

DB IDO: Fix that downtime is not in effect after restart

fixes #10843
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Dec 15, 2015

Updated by mhein on 2015-12-15 10:46:47 +00:00

Hello again,

this is a SHKS issue.

Cheers,

Marius

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Dec 16, 2015

Updated by mfriedrich on 2015-12-16 15:53:49 +00:00

  • Category set to DB IDO
  • Target Version set to Backlog
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Dec 16, 2015

Updated by mfriedrich on 2015-12-16 18:05:25 +00:00

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

@jean

Please try to reproduce the issue on 2.4.x and report its state here. Thanks :)

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Jan 4, 2016

Updated by jflach on 2016-01-04 10:43:56 +00:00

@michi

I could reproduce this.

$ icinga2 --version                                                                                                                                       
icinga2 - The Icinga 2 network monitoring daemon (version: v2.4.1; debug)

Created a downtime

curl -k -s -u root:baum -H 'Accept: application/json' \
-X POST 'https://localhost:5665/v1/actions/schedule-downtime?type=Service&filter=service.name==%22ping4%22' \
-d "{\"start_time\": `date --date=\"yesterday\" \"+%s\"`, \"end_time\": `date --date=\"tomorrow\" \"+%s\"`, \"fixed\": true, \"duration\": 1, \"author\": \"jflach\", \"comment\": \"bug 10843\"}"
#creates a fixed downtime that starts yesterday and ends tomorrow

is_in_effect: 0

select * from icinga_scheduleddowntime\G
*************************** 1. row ***************************
  scheduleddowntime_id: 1
           instance_id: 1
         downtime_type: 1
             object_id: 92
            entry_time: 2016-01-04 11:29:00
           author_name: jflach
          comment_data: bug 10843
  internal_downtime_id: 1
       triggered_by_id: 0
              is_fixed: 1
              duration: 1
  scheduled_start_time: 2016-01-03 11:29:00
    scheduled_end_time: 2016-01-05 11:29:00
           was_started: 0
     actual_start_time: 0000-00-00 00:00:00
actual_start_time_usec: 0
          is_in_effect: 0
          trigger_time: 0000-00-00 00:00:00
                  name: app!ping4!jfws-1451903340-0
    endpoint_object_id: 3

It also shows up as not-in-effect in icingaweb2. I will investigate this a bit further but currently I have no idea how or why this happens.

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Jan 11, 2016

Updated by mfriedrich on 2016-01-11 09:43:37 +00:00

  • Priority changed from Normal to High
  • Target Version changed from Backlog to 2.5.0
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Jan 25, 2016

Updated by mfriedrich on 2016-01-25 10:34:41 +00:00

  • Assigned to changed from jflach to mfriedrich
  • Target Version changed from 2.5.0 to 2.4.2
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Feb 4, 2016

Updated by mfriedrich on 2016-02-04 13:40:09 +00:00

  • File added icinga2_downtime_triggered_10843.png

I'm unable to reproduce this issue with the current git master.

  • Add a new dummy host
  • Send in an UP checkresult
  • Schedule a downtime
  • Send in a DOWN checkresult
  • Check the Downtime tab in Icinga Web 2

icinga2_downtime_triggered_10843.png

*************************** 12. row ***************************
  scheduleddowntime_id: 52
           instance_id: 1
         downtime_type: 2
             object_id: 1996
            entry_time: 2016-02-04 14:33:17
           author_name: icingaadmin
          comment_data: ffdsfsdfsfsd
  internal_downtime_id: 12
       triggered_by_id: 0
              is_fixed: 1
              duration: 0
  scheduled_start_time: 2016-02-04 14:33:13
    scheduled_end_time: 2016-02-04 15:33:13
           was_started: 1
     actual_start_time: 2016-02-04 14:34:36
actual_start_time_usec: 573839
          is_in_effect: 1
          trigger_time: 2016-02-04 14:34:36
                  name: passive!mbmif.int.netways.de-1454592797-0
    endpoint_object_id: 89
12 rows in set (0.00 sec)
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Feb 4, 2016

Updated by mfriedrich on 2016-02-04 13:42:49 +00:00

  • File added icinga2_downtime_triggered_10843_02.png

Scheduling a downtime on an already !OK state also works in triggering it immediately.

icinga2_downtime_triggered_10843_02.png

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Feb 4, 2016

Updated by mfriedrich on 2016-02-04 13:43:57 +00:00

  • Status changed from Assigned to Closed
  • Target Version deleted 2.4.2

Probably this issue exists in 2.3.x but has been fixed either in 2.4.0 or with the latest changes applied for the next version. I'm therefore closing this issue.

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Mar 23, 2016

Updated by mfriedrich on 2016-03-23 12:41:44 +00:00

  • Subject changed from Relation icinga_scheduleddowntime not updated to DB IDO: downtime is not in effect after restart
  • Status changed from Closed to Assigned
  • Target Version set to 2.4.5

I think I found a similar behaviour today. When the downtime is added once, and then triggered, everything is fine. Once you restart the core the downtime is not necessarily triggered again. The condition for checking 'is_in_effect' was different in statusdatawriter and ido*connection. Furthermore such "loaded" downtimes do not update the scheduled_downtime_depth similar to what TriggerDowntime does.

AddDowntime:

  • is_in_effect -> downtime->IsActive()
  • was_started -> downtime->GetStartTime() <= Utility::GetTime()
  • trigger_time was missing too

RemoveDowntime

  • is_in_effect = 0

TriggerDowntime

  • is_in_effect -> downtime->IsActive()
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Mar 23, 2016

Updated by mfriedrich on 2016-03-23 12:42:27 +00:00

  • Parent Id set to 11312
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Mar 23, 2016

Updated by mfriedrich on 2016-03-23 12:45:03 +00:00

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

Applied in changeset 98e1d70.

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Mar 24, 2016

Updated by mfriedrich on 2016-03-24 09:42:00 +00:00

  • Parent Id deleted 11312
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Apr 20, 2016

Updated by gbeutner on 2016-04-20 08:15:51 +00:00

  • Backport? changed from Not yet backported to Already backported
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.