[dev.icinga.com #10843] DB IDO: downtime is not in effect after restart

[icinga-migration]

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

• IMG_20151215_113741.jpg mhein - 2015-12-15 10:45:45 +00:00
• icinga2_downtime_triggered_10843.png mfriedrich - 2016-02-04 13:37:48 +00:00
• icinga2_downtime_triggered_10843_02.png mfriedrich - 2016-02-04 13:42:39 +00:00

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]

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

Hello again,

this is a SHKS issue.

Cheers,

Marius

[icinga-migration]

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

• Category set to DB IDO
• Target Version set to Backlog

[icinga-migration]

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]

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]

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]

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]

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

*************************** 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]

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.

[icinga-migration]

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]

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]

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

• Parent Id set to 11312

[icinga-migration]

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]

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

• Parent Id deleted 11312

[icinga-migration]

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

• Backport? changed from Not yet backported to Already backported