Icinga2: Scheduled-Downtime over midnight will not be scheduled

Created on 15 May 2017  路  11Comments  路  Source: Icinga/icinga2

Behavior

I have set a scheduled downtime before and after midnight but only the time before 00:00 will be scheduled.

vars.wiederkehrende_downtime= "20:00-24:00,00:00-04:00"

There should be a downtime for 20:00-24:00 and 00:00-04:00 but only the downtime for 20:00-24:00 appears. Switching the times ("00:00-04:00,20:00-24:00") will still only accept the 20:00-24:00 downtime.

More info: https://monitoring-portal.org/index.php?thread/40408-scheduled-downtime-%C3%BCber-mitternacht-wird-nicht-eingerichtet/

Steps to Reproduce (for bugs)

  1. add to downtimes.conf:
apply ScheduledDowntime "wiederkehrende-downtime" to Host {
comment = "Wiederkehrende Downtime fuer Host"
author = "icingaadmin"
 ranges = {
  monday = host.vars.wiederkehrende_downtime
  tuesday = host.vars.wiederkehrende_downtime
  wednesday = host.vars.wiederkehrende_downtime
  thursday = host.vars.wiederkehrende_downtime
  friday = host.vars.wiederkehrende_downtime
  saturday = host.vars.wiederkehrende_downtime
  sunday = host.vars.wiederkehrende_downtime
 }
 assign where host.vars.wiederkehrende_downtime != ""
}
  1. add to a host:
    vars.wiederkehrende_downtime= "20:00-24:00,00:00-04:00"
  2. _service icinga2 reload_
  3. check your GUI or "_icinga2 object list --type downtime_"

Context

How has this issue affected me?
I cant set scheduled downtimes for daily/weekly backups so everytime the backup is running, icinga2 might not be able to check the host/service so it will send out alerts (sms)

My Environment

_icinga2 --version_

icinga2 - The Icinga 2 network monitoring daemon (version: r2.6.3-1)

Copyright (c) 2012-2017 Icinga Development Team (https://www.icinga.com/)
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl2.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Application information:
  Installation root: /usr
  Sysconf directory: /etc
  Run directory: /run
  Local state directory: /var
  Package data directory: /usr/share/icinga2
  State path: /var/lib/icinga2/icinga2.state
  Modified attributes path: /var/lib/icinga2/modified-attributes.conf
  Objects path: /var/cache/icinga2/icinga2.debug
  Vars path: /var/cache/icinga2/icinga2.vars
  PID path: /run/icinga2/icinga2.pid

System information:
  Platform: Ubuntu
  Platform version: 14.04.5 LTS, Trusty Tahr
  Kernel: Linux
  Kernel version: 4.4.0-66-generic
  Architecture: x86_64

Build information:
  Compiler: GNU 4.8.4
  Build host: lgw01-43

_icinga2 feature list_

Disabled features: debuglog gelf graphite icingastatus influxdb livestatus opentsdb syslog
Enabled features: api checker command compatlog ido-mysql mainlog notification perfdata statusdata

_icinga2 daemon -C_

information/cli: Icinga application loader (version: r2.6.3-1)
information/cli: Loading configuration file(s).
information/ConfigItem: Committing config item(s).
information/ApiListener: My API identity: icinga2.domain.local
information/ConfigItem: Instantiated 1 ApiUser.
information/ConfigItem: Instantiated 1 ApiListener.
information/ConfigItem: Instantiated 3 Zones.
information/ConfigItem: Instantiated 1 FileLogger.
information/ConfigItem: Instantiated 2 Endpoints.
information/ConfigItem: Instantiated 6 NotificationCommands.
information/ConfigItem: Instantiated 5120 Notifications.
information/ConfigItem: Instantiated 210 CheckCommands.
information/ConfigItem: Instantiated 33 Downtimes.
information/ConfigItem: Instantiated 162 Hosts.
information/ConfigItem: Instantiated 1 IcingaApplication.
information/ConfigItem: Instantiated 15 HostGroups.
information/ConfigItem: Instantiated 2 Comments.
information/ConfigItem: Instantiated 55 Dependencies.
information/ConfigItem: Instantiated 4 UserGroups.
information/ConfigItem: Instantiated 8 Users.
information/ConfigItem: Instantiated 1800 Services.
information/ConfigItem: Instantiated 8 TimePeriods.
information/ConfigItem: Instantiated 27 ServiceGroups.
information/ConfigItem: Instantiated 20 ScheduledDowntimes.
information/ConfigItem: Instantiated 1 CompatLogger.
information/ConfigItem: Instantiated 1 StatusDataWriter.
information/ConfigItem: Instantiated 2 ExternalCommandListeners.
information/ConfigItem: Instantiated 1 CheckerComponent.
information/ConfigItem: Instantiated 1 IdoMysqlConnection.
information/ConfigItem: Instantiated 1 NotificationComponent.
information/ConfigItem: Instantiated 1 PerfdataWriter.
information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars'
information/cli: Finished validating the configuration file(s).

_icinga2 object list --type Endpoint_

Object 'icinga2-sat.domain.local' of type 'Endpoint':
  % declared in '/etc/icinga2/zones.conf', lines 20:1-20:49
  * __name = "icinga2-sat.domain.local"
  * host = "192.168.63.100"
    % = modified in '/etc/icinga2/zones.conf', lines 21:2-21:23
  * log_duration = 86400
  * name = "icinga2-sat.domain.local"
  * package = "_etc"
  * port = "5665"
  * templates = [ "icinga2-sat.domain.local" ]
    % = modified in '/etc/icinga2/zones.conf', lines 20:1-20:49
  * type = "Endpoint"
  * zone = ""

Object 'icinga2.domain.local' of type 'Endpoint':
  % declared in '/etc/icinga2/zones.conf', lines 10:1-10:40
  * __name = "icinga2.domain.local"
  * host = "10.124.16.100"
    % = modified in '/etc/icinga2/zones.conf', lines 11:2-11:22
  * log_duration = 86400
  * name = "icinga2.domain.local"
  * package = "_etc"
  * port = "5665"
    % = modified in '/etc/icinga2/zones.conf', lines 12:2-12:14
  * templates = [ "icinga2.domain.local" ]
    % = modified in '/etc/icinga2/zones.conf', lines 10:1-10:40
  * type = "Endpoint"
  * zone = ""

_icinga2 object list --type Zone_

Object 'global-templates' of type 'Zone':
  % declared in '/etc/icinga2/zones.conf', lines 6:1-6:30
  * __name = "global-templates"
  * endpoints = null
  * global = true
    % = modified in '/etc/icinga2/zones.conf', lines 7:3-7:15
  * name = "global-templates"
  * package = "_etc"
  * parent = ""
  * templates = [ "global-templates" ]
    % = modified in '/etc/icinga2/zones.conf', lines 6:1-6:30
  * type = "Zone"
  * zone = ""

Object 'SAT' of type 'Zone':
  % declared in '/etc/icinga2/zones.conf', lines 24:1-24:21
  * __name = "SAT"
  * endpoints = [ "icinga2-sat.domain.local" ]
    % = modified in '/etc/icinga2/zones.conf', lines 25:2-25:50
  * global = false
  * name = "SAT"
  * package = "_etc"
  * parent = "master"
    % = modified in '/etc/icinga2/zones.conf', lines 26:2-26:18
  * templates = [ "SAT" ]
    % = modified in '/etc/icinga2/zones.conf', lines 24:1-24:21
  * type = "Zone"
  * zone = ""

Object 'master' of type 'Zone':
  % declared in '/etc/icinga2/zones.conf', lines 15:1-15:20
  * __name = "master"
  * endpoints = [ "icinga2.domain.local" ]
    % = modified in '/etc/icinga2/zones.conf', lines 17:2-17:41
  * global = false
  * name = "master"
  * package = "_etc"
  * parent = ""
  * templates = [ "master" ]
    % = modified in '/etc/icinga2/zones.conf', lines 15:1-15:20
  * type = "Zone"
  * zone = ""
bug
Source
picture NRGYDrink

Most helpful comment

My solution over midnight is like this

ranges = {
  "monday" = "20:00-26:00"
}

in my scheduledDowntimes objects.

picture Mikesch-mp on 25 Apr 2018
👍2 ❤1

All 11 comments

I am not able to reproduce this issue, testing without IDO but the same host.vars style configuration. Also not using a wrap-around midnight timeframe (see below).

The downtimes for each perspective window are indeed created, although it could be in an unanticipated manner.

I ran icinga2 daemon -C before running icinga2 object list --type downtime.

vars.wiederkehrende_downtime = "13:40-13:45,13:45-13:50"

Sat Jun 24 13:38:37 EDT 2017

Object 'testhost-timeperiod-5261!testmaster-1498325916-0' of type 'Downtime':
  * start_time = 1498326000  # Saturday, June 24, 2017 1:40:00 PM
  * end_time = 1498326300    # Saturday, June 24, 2017 1:45:00 PM

Sat Jun 24 13:40:38 EDT 2017

Object 'testhost-timeperiod-5261!testmaster-1498325916-0' of type 'Downtime':
  * start_time = 1498326000  # Saturday, June 24, 2017 1:40:00 PM
  * end_time = 1498326300    # Saturday, June 24, 2017 1:45:00 PM
Object 'testhost-timeperiod-5261!testmaster-1498326036-3' of type 'Downtime':
  * start_time = 1498326300  # Saturday, June 24, 2017 1:45:00 PM
  * end_time = 1498326600    # Saturday, June 24, 2017 1:50:00 PM

Sat Jun 24 13:45:39 EDT 2017

Object 'testhost-timeperiod-5261!testmaster-1498326036-3' of type 'Downtime':
  * start_time = 1498326300  # Saturday, June 24, 2017 1:45:00 PM
  * end_time = 1498326600    # Saturday, June 24, 2017 1:50:00 PM
Object 'testhost-timeperiod-5261!testmaster-1498326336-4' of type 'Downtime':
  * start_time = 1498412400  # Sunday, June 25, 2017 1:40:00 PM
  * end_time = 1498412700    # Sunday, June 25, 2017 1:45:00 PM

Sat Jun 24 13:50:41 EDT 2017

Object 'testhost-timeperiod-5261!testmaster-1498326336-4' of type 'Downtime':
  * start_time = 1498412400  # Sunday, June 25, 2017 1:40:00 PM
  * end_time = 1498412700    # Sunday, June 25, 2017 1:45:00 PM

Test system:
CentOS Linux release 7.3.1611

commit 0e423df4a0e366680dd322af6ec3968f5e8790ab
Merge: 04757d1 c8b4fee
Author: Michael Friedrich <[email protected]>
Date:   Fri Jun 23 12:56:05 2017 +0200

I will set up a script to run overnight to test the edge-case specific to midnight, but wanted to provide these observations here.

While I can see how it can be observed as a bug (specifically the first iteration) and due to the caching of object list, there doesn't seem to be a functional issue here (unless running daemon -C circumvented an issue, but I haven't seen the issue in practice).

leeclemens picture leeclemens on 24 Jun 2017

The test overnight seems to have produced similar results, the second downtime is created but not until the first time window is entered.

vars.wiederkehrende_downtime = "20:00-24:00,00:00-04:00"

Sat Jun 24 19:59:01 EDT 2017

Object 'testhost-timeperiod-5261!icingadev.thebes.owl-1498344314-0' of type 'Downtime':
  * start_time = 1498348800  # Saturday, June 24, 2017 8:00:00 PM
  * end_time = 1498363200    # Sunday, June 25, 2017 12:00:00 AM

Sat Jun 24 20:01:01 EDT 2017

Object 'testhost-timeperiod-5261!icingadev.thebes.owl-1498344314-0' of type 'Downtime':
  * start_time = 1498348800  # Saturday, June 24, 2017 8:00:00 PM
  * end_time = 1498363200    # Sunday, June 25, 2017 12:00:00 AM
Object 'testhost-timeperiod-5261!icingadev.thebes.owl-1498348814-2' of type 'Downtime':
  * start_time = 1498363200  # Sunday, June 25, 2017 12:00:00 AM
  * end_time = 1498377600    # Sunday, June 25, 2017 4:00:00 AM

Sun Jun 25 00:01:01 EDT 2017

Object 'testhost-timeperiod-5261!icingadev.thebes.owl-1498348814-2' of type 'Downtime':
  * start_time = 1498363200  # Sunday, June 25, 2017 12:00:00 AM
  * end_time = 1498377600    # Sunday, June 25, 2017 4:00:00 AM
Object 'testhost-timeperiod-5261!icingadev.thebes.owl-1498363213-3' of type 'Downtime':
  * start_time = 1498435200  # Sunday, June 25, 2017 8:00:00 PM
  * end_time = 1498449600    # Monday, June 26, 2017 12:00:00 AM

Sun Jun 25 04:01:01 EDT 2017

Object 'testhost-timeperiod-5261!icingadev.thebes.owl-1498363213-3' of type 'Downtime':
  * start_time = 1498435200  # Sunday, June 25, 2017 8:00:00 PM
  * end_time = 1498449600    # Monday, June 26, 2017 12:00:00 AM
leeclemens picture leeclemens on 25 Jun 2017

This is still an issue, and it is very annoying that I cannot schedule a period across midnight.
monday = "00:00-1:00,21:30-24:00"
The above does not work.
To fix i had to create two separate ScheduledDowntime

jgrammen-agilitypr picture jgrammen-agilitypr on 19 Apr 2018

My solution over midnight is like this

ranges = {
  "monday" = "20:00-26:00"
}

in my scheduledDowntimes objects.

Mikesch-mp picture Mikesch-mp on 25 Apr 2018
👍2 ❤1

If this workaround works reliably we should document it at least as this question comes up a lot. I did not know about this.

Crunsher picture Crunsher on 25 Apr 2018

I found it once in an issue, but dont ask me which one :)

Mikesch-mp picture Mikesch-mp on 25 Apr 2018

If the "clock overflow" @Mikesch-mp shown works... I exactly know how to fix this one...

Al2Klimov picture Al2Klimov on 12 Mar 2019
👍1

Hello guys!

Please could you test the linked PR?

Best,
AK

Al2Klimov picture Al2Klimov on 12 Mar 2019
👍1

Just had the pleasure to encounter this bug as well. The clock overflow workaround works perfectly.

apply ScheduledDowntime "test-downtime" to Host {
  author = "icingaadmin"
  comment = "Scheduled downtime for test"

  ranges = {
    monday = "17:00-19:00,22:00-30:00"
    tuesday = "17:00-19:00,22:00-30:00"
    wednesday = "17:00-19:00,22:00-30:00"
    thursday = "17:00-19:00,22:00-30:00"
    friday = "17:00-19:00,22:00-30:00"
  }

  assign where host.name == "localhost"
}

What I noticed as well, is that what @leeclemens mentioned about subsequent time windows. The second time window above (22:00-30:00) is not planned by Icinga (not visible in Icinga Web 2) until the first is active. Kind of irritating, but it works.

nilmerg picture nilmerg on 14 Mar 2019
👍1

The unit tests are a bit sparse for the timeperiod class, I'll enhance them in order to test the PR.

dnsmichi picture dnsmichi on 7 May 2019

Unfortunately the PR doesn't work, see my comments there.

dnsmichi picture dnsmichi on 10 May 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

silenceJI picture silenceJI  路  5Comments
icinga-migration picture icinga-migration  路  6Comments
Thomas-Gelf picture Thomas-Gelf  路  5Comments
Duffkess picture Duffkess  路  6Comments
ak2766 picture ak2766  路  7Comments