Timeperiod exclusions doesn't work as expected #7398

darkweaver87 · 2019-08-06T11:19:28Z

Describe the bug

In our config, we use two timeperiods, one one excluding the other one and it doesn't seem to work when a time period contains multiple sub-timeperiod.

To Reproduce

Here is a configuration sample:

object TimePeriod "24x7" {
 ranges = {
     tuesday = "00:00-23:59"
 }
}

object TimePeriod "onDuty" {
   // object attributes
   excludes = []
   ranges = {
     tuesday = "09:00-09:30"
   }
}

object TimePeriod "offDuty" {
 excludes = ["onDuty"]
 ranges = {
     tuesday = "00:00-23:59"
 }
}

object User "me" {
   email = "me@me.com"
   enable_notifications = true
   groups = []
   period = "24x7"
}

object Host "test" {
   address = "127.0.0.1"
   zone = "fr"

   check_command = "check_host_alive"
   check_interval = 20s
   check_period = "offDuty"
   enable_active_checks = 1
   enable_event_handler = 0
   enable_flapping = 0
   enable_notifications = 0
   enable_passive_checks = 0
   max_check_attempts = 3
   retry_interval = 5s
}

apply Service "test-me" {
 host_name = "test"

 display_name = "test"

 check_command = "dummy"

 check_interval = 20s
 retry_interval = 5s
 check_period = "offDuty"

 enable_notifications = 1

 vars.dummy_state = 2
 vars.dummy_text = "TEST KO"
 vars.is_test = "True"
 vars.notification_interval = 60
 vars.notification_options_states = [Critical, Unknown, Warning]
 vars.notification_options_types = [Problem, Recovery]
 vars.notification_period = "offDuty"

 assign where host.name == "test"
}

apply Notification "service-bysms" to Service {
 // object attributes
 command = "notify-service-by-sms"
 period = "24x7"

 users = ["me"]

 states = service.vars.notification_options_states
 types = service.vars.notification_options_types
 if (service.vars["notification_interval"]) {
         interval = service.vars["notification_interval"]
 }  else  {
     interval = 1800
 }

 if (service.vars["notification_period"]) {
         period = service.vars["notification_period"]
 }

 assign where host.name == "test"
}

Expected behavior

To me, in this example, the offDuty period should be 00:00-09:00,09:30-00:00

Your Environment

Include as many relevant details about the environment you experienced the problem in

Version used (icinga2 --version):

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

Copyright (c) 2012-2019 Icinga GmbH (https://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.

System information:
  Platform: Debian GNU/Linux
  Platform version: 9 (stretch)
  Kernel: Linux
  Kernel version: 4.14.119
  Architecture: x86_64

Build information:
  Compiler: GNU 6.3.0
  Build host: cb654124b660

Application information:

General paths:
  Config directory: /etc/icinga2
  Data directory: /var/lib/icinga2
  Log directory: /var/log/icinga2
  Cache directory: /var/cache/icinga2
  Spool directory: /var/spool/icinga2
  Run directory: /run/icinga2

Old paths (deprecated):
  Installation root: /usr
  Sysconf directory: /etc
  Run directory (base): /run
  Local state directory: /var

Internal paths:
  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

Operating System and version:

# lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 9.9 (stretch)
Release:	9.9
Codename:	stretch

Enabled features (icinga2 feature list):

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

Config validation (icinga2 daemon -C):

...
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 5293 Services.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 2 LivestatusListeners.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 1 IcingaApplication.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 2070 Hosts.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 1 EventCommand.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 1 FileLogger.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 6 NotificationCommands.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 22087 Notifications.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 1 NotificationComponent.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 154 HostGroups.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 1 ApiListener.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 1 CheckerComponent.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 4 Zones.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 6 Endpoints.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 4 ApiUsers.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 15 Users.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 247 CheckCommands.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 1 IdoPgsqlConnection.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 94 UserGroups.
[2019-08-06 12:51:25 +0200] information/ConfigItem: Instantiated 14 TimePeriods.
[2019-08-06 12:51:25 +0200] information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars'
[2019-08-06 12:51:25 +0200] information/cli: Finished validating the configuration file(s).

Thanks !

The text was updated successfully, but these errors were encountered:

dnsmichi · 2019-08-07T13:06:50Z

Do you have the debug logs from Thursday 09:00 til 10:00 to help mitigate the problem? Obviously the TimePeriod object is used as check_period, not notification period, so trace the scheduled checks and their results.

darkweaver87 · 2019-08-08T06:30:38Z

Thanks for your reply.
Hum unfortunately no. I will try to get some logs today but I will have to spaw a dedicated instance.
The timeperiod is used as check and notification period, look at period = service.vars["notification_period"] in the notification apply rule. By the way, do you have a smarter way of migrating notification_period, notification_interval and notification_options from a nagios object (I mean something that can be automated) ?

darkweaver87 · 2019-08-08T07:51:20Z

Here is a configuration which reproduce the problem on a fresh icinga install on debian stretch and v2.10.5-1 (same environment as my production):

# cat /etc/icinga2/conf.d/test.conf 
/*object TimePeriod "24x7" {
 ranges = {
     monday = "00:00-23:59"
     tuesday = "00:00-23:59"
     wednesday = "00:00-23:59"
     thursday = "00:00-23:59"
     friday = "00:00-23:59"
     saturday = "00:00-23:59"
     sunday = "00:00-23:59"
 }
}*/

object TimePeriod "onDuty" {
   // object attributes
   excludes = []
   ranges = {
     monday = "09:00-10:00"
     tuesday = "09:00-10:00"
     wednesday = "09:00-10:00"
     thursday = "09:00-10:00"
     friday = "09:00-10:00"
     saturday = "09:00-10:00"
     sunday = "09:00-10:00"
   }
}

object TimePeriod "offDuty" {
 excludes = ["onDuty"]
 ranges = {
     monday = "00:00-23:59"
     tuesday = "00:00-23:59"
     wednesday = "00:00-23:59"
     thursday = "00:00-23:59"
     friday = "00:00-23:59"
     saturday = "00:00-23:59"
     sunday = "00:00-23:59"
 }
}

object User "me" {
   email = "me@me.com"
   enable_notifications = true
   groups = []
   period = "24x7"
}

object Host "test" {
   address = "127.0.0.1"

   check_command = "hostalive"
   check_interval = 20s
   check_period = "offDuty"
   enable_active_checks = 1
   enable_event_handler = 0
   enable_flapping = 0
   enable_notifications = 0
   enable_passive_checks = 0
   max_check_attempts = 3
   retry_interval = 5s
}

apply Service "test-me" {
 host_name = "test"

 display_name = "test"

 check_command = "dummy"

 check_interval = 20s
 retry_interval = 5s
 check_period = "offDuty"

 enable_notifications = 1

 vars.dummy_state = 2
 vars.dummy_text = "TEST KO"
 vars.is_test = "True"
 vars.notification_interval = 60
 vars.notification_options_states = [Critical, Unknown, Warning]
 vars.notification_options_types = [Problem, Recovery]
 vars.notification_period = "offDuty"

 assign where host.name == "test"
}

apply Notification "service-bysms" to Service {
 // object attributes
 command = "mail-service-notification"
 period = "24x7"

 users = ["me"]

 states = service.vars.notification_options_states
 types = service.vars.notification_options_types
 if (service.vars["notification_interval"]) {
         interval = service.vars["notification_interval"]
 }  else  {
     interval = 1800
 }

 if (service.vars["notification_period"]) {
         period = service.vars["notification_period"]
 }

 assign where host.name == "test"
}

Logs:

[2019-08-08 09:41:04 +0200] debug/CheckerComponent: Scheduling info for checkable 'test!test-me' (2019-08-08 09:41:04 +0200): Object 'test!test-me', Next Check: 2019-08-08 09:41:04 +0200(1.56525e+09).
[2019-08-08 09:41:04 +0200] debug/CheckerComponent: Executing check for 'test!test-me'
[2019-08-08 09:41:04 +0200] debug/Checkable: Update checkable 'test!test-me' with check interval '20' from last check time at 2019-08-08 09:40:43 +0200 (1.56525e+09) to next check time at 2019-08-08 09:41:22 +0200(1.56525e+09).
[2019-08-08 09:41:04 +0200] debug/Checkable: Update checkable 'test!test-me' with check interval '20' from last check time at 2019-08-08 09:41:04 +0200 (1.56525e+09) to next check time at 2019-08-08 09:41:22 +0200(1.56525e+09).
[2019-08-08 09:41:04 +0200] debug/DbEvents: add checkable check history for 'test!test-me'
[2019-08-08 09:41:04 +0200] debug/CheckerComponent: Check finished for object 'test!test-me'
[2019-08-08 09:41:05 +0200] notice/NotificationComponent: Attempting to send reminder notification 'test!test-me!service-bysms'
[2019-08-08 09:41:05 +0200] notice/Notification: Attempting to send reminder notifications for notification object 'test!test-me!service-bysms'.
[2019-08-08 09:41:05 +0200] information/Notification: Sending reminder 'Problem' notification 'test!test-me!service-bysms' for user 'me'
[2019-08-08 09:41:05 +0200] debug/DbEvents: add notification history for 'test!test-me'
[2019-08-08 09:41:05 +0200] debug/DbEvents: add contact notification history for service 'test!test-me' and user 'me'.
[2019-08-08 09:41:05 +0200] notice/Process: Running command '/etc/icinga2/scripts/mail-service-notification.sh' '-4' '127.0.0.1' '-6' '' '-b' '' '-c' '' '-d' '2019-08-08 09:41:05 +0200' '-e' 'test-me' '-l' 'test' '-n' 'test' '-o' 'TEST KO' '-r' 'me@me.com' '-s' 'CRITICAL' '-t' 'PROBLEM' '-u' 'test': PID 8820
[2019-08-08 09:41:05 +0200] debug/DbEvents: add log entry history for 'test!test-me'
[2019-08-08 09:41:05 +0200] information/Notification: Completed sending 'Problem' notification 'test!test-me!service-bysms' for checkable 'test!test-me' and user 'me'.
[2019-08-08 09:41:05 +0200] notice/Process: PID 8820 ('/etc/icinga2/scripts/mail-service-notification.sh' '-4' '127.0.0.1' '-6' '' '-b' '' '-c' '' '-d' '2019-08-08 09:41:05 +0200' '-e' 'test-me' '-l' 'test' '-n' 'test' '-o' 'TEST KO' '-r' 'me@me.com' '-s' 'CRITICAL' '-t' 'PROBLEM' '-u' 'test') terminated with exit code 0

The notification period through service vars is working correctly:

# icinga2 object list --type Notification --name 'test!test-me!service-bysms'
Object 'test!test-me!service-bysms' of type 'Notification':
  % declared in '/etc/icinga2/conf.d/test.conf', lines 86:1-86:45
  * __name = "test!test-me!service-bysms"
  * command = "mail-service-notification"
    % = modified in '/etc/icinga2/conf.d/test.conf', lines 88:2-88:38
  * command_endpoint = ""
  * host_name = "test"
    % = modified in '/etc/icinga2/conf.d/test.conf', lines 86:1-86:45
  * interval = 60
    % = modified in '/etc/icinga2/conf.d/test.conf', lines 96:10-96:57
  * name = "service-bysms"
  * package = "_etc"
    % = modified in '/etc/icinga2/conf.d/test.conf', lines 86:1-86:45
  * period = "offDuty"
    % = modified in '/etc/icinga2/conf.d/test.conf', lines 89:2-89:16
    % = modified in '/etc/icinga2/conf.d/test.conf', lines 102:10-102:53
  * service_name = "test-me"
    % = modified in '/etc/icinga2/conf.d/test.conf', lines 86:1-86:45
  * source_location
    * first_column = 1
    * first_line = 86
    * last_column = 45
    * last_line = 86
    * path = "/etc/icinga2/conf.d/test.conf"
  * states = [ "Critical", "Unknown", "Warning" ]
    % = modified in '/etc/icinga2/conf.d/test.conf', lines 93:2-93:50
  * templates = [ "service-bysms" ]
    % = modified in '/etc/icinga2/conf.d/test.conf', lines 86:1-86:45
  * times = null
  * type = "Notification"
  * types = [ "Problem", "Recovery" ]
    % = modified in '/etc/icinga2/conf.d/test.conf', lines 94:2-94:48
  * user_groups = null
  * users = [ "me" ]
    % = modified in '/etc/icinga2/conf.d/test.conf', lines 91:2-91:15
  * vars = null
  * zone = ""

To me, in this example, the notification should not have occurred between 9h and 10h.
I also tried to play with the prefer_includes attribute but it doesn't change anything :-/

dnsmichi · 2019-08-08T07:51:56Z

I'm a friend of keeping the details inside the notification objects and apply rules, I don't like the old way of stashing everything into hosts and services for notifications. That's also why the notification objects exist, I am one of the architects of that feature. Anyhow, your approach looks sufficient to me, I didn't understand its intention up until now though.

Logs will help to mitigate further. You can also create a dummy TimePeriod configuration with the above excludes and then query the REST API at /v1/objects/timeperiods for the is_inside attribute at that very moment, e.g. with a loop checking that every second.

darkweaver87 · 2019-08-08T10:10:17Z

Yes I understand :-) For now I need my old prod to work along with Icinga in order to validate everything is working as expected. That's why I did this "bad thing" to make my migration script working. Once Icinga will have replaced my old monitoring infrastructure I'll rewrite my config the Icinga-way :-)
OK for the is_inside test, will do.

darkweaver87 · 2019-08-08T12:12:44Z

OK so very stange :-) I manage to reproduce it serveral times.
Here is the scenario:

add the above configuration (change onDuty timeperiod times for the test purpose)
start Icinga -> it won't work
enable API and restart Icinga
it works! I have the following logs:

[2019-08-08 14:03:32 +0200] notice/CheckerComponent: Skipping check for object 'test!test-me': not in check period 'offDuty'
[2019-08-08 14:03:32 +0200] debug/CheckerComponent: Checks for checkable 'test!test-me' are disabled. Rescheduling check.
[2019-08-08 14:03:32 +0200] debug/Checkable: Update checkable 'test!test-me' with check interval '20' from last check time at 2019-08-08 14:01:39 +0200 (1.56527e+09) to next check time at 2019-08-08 14:03:51 +0200(1.56527e+09).

Timeperiod logs:

with API disabled:

[2019-08-08 14:00:23 +0200] debug/TimePeriod: Removing segment 'Thu Aug  8 14:00:23 2019' <-> 'Fri Aug  9 14:00:23 2019' from TimePeriod '24x7'
[2019-08-08 14:00:23 +0200] debug/TimePeriod: Adding segment 'Thu Aug  8 00:00:00 2019' <-> 'Fri Aug  9 00:00:00 2019' to TimePeriod '24x7'
[2019-08-08 14:00:23 +0200] debug/TimePeriod: Adding segment 'Fri Aug  9 00:00:00 2019' <-> 'Sat Aug 10 00:00:00 2019' to TimePeriod '24x7'
[2019-08-08 14:00:23 +0200] debug/TimePeriod: Removing segment 'Thu Aug  8 14:00:23 2019' <-> 'Fri Aug  9 14:00:23 2019' from TimePeriod 'never'
[2019-08-08 14:00:23 +0200] debug/TimePeriod: Removing segment 'Thu Aug  8 14:00:23 2019' <-> 'Fri Aug  9 14:00:23 2019' from TimePeriod 'offDuty'
[2019-08-08 14:00:23 +0200] debug/TimePeriod: Adding segment 'Thu Aug  8 00:00:00 2019' <-> 'Thu Aug  8 23:59:00 2019' to TimePeriod 'offDuty'
[2019-08-08 14:00:23 +0200] debug/TimePeriod: Adding segment 'Fri Aug  9 00:00:00 2019' <-> 'Fri Aug  9 23:59:00 2019' to TimePeriod 'offDuty'
[2019-08-08 14:00:23 +0200] debug/TimePeriod: Merge TimePeriod 'offDuty' with 'onDuty' Method: exclude
[2019-08-08 14:00:23 +0200] debug/TimePeriod: Removing segment 'Thu Aug  8 12:35:00 2019' <-> 'Thu Aug  8 13:00:00 2019' from TimePeriod 'offDuty'
[2019-08-08 14:00:23 +0200] debug/TimePeriod: Removing segment 'Fri Aug  9 09:00:00 2019' <-> 'Fri Aug  9 10:00:00 2019' from TimePeriod 'offDuty'
[2019-08-08 14:00:23 +0200] debug/TimePeriod: Removing segment 'Thu Aug  8 14:00:23 2019' <-> 'Fri Aug  9 14:00:23 2019' from TimePeriod 'onDuty'
[2019-08-08 14:00:23 +0200] debug/TimePeriod: Adding segment 'Thu Aug  8 12:35:00 2019' <-> 'Thu Aug  8 14:05:00 2019' to TimePeriod 'onDuty'
[2019-08-08 14:00:23 +0200] debug/TimePeriod: Adding segment 'Fri Aug  9 09:00:00 2019' <-> 'Fri Aug  9 10:00:00 2019' to TimePeriod 'onDuty'

with API enabled:

[2019-08-08 14:03:14 +0200] debug/TimePeriod: Removing segment 'Thu Aug  8 14:03:14 2019' <-> 'Fri Aug  9 14:03:14 2019' from TimePeriod 'onDuty'
[2019-08-08 14:03:14 +0200] debug/TimePeriod: Adding segment 'Thu Aug  8 12:35:00 2019' <-> 'Thu Aug  8 14:05:00 2019' to TimePeriod 'onDuty'
[2019-08-08 14:03:14 +0200] debug/TimePeriod: Adding segment 'Fri Aug  9 09:00:00 2019' <-> 'Fri Aug  9 10:00:00 2019' to TimePeriod 'onDuty'
[2019-08-08 14:03:14 +0200] debug/TimePeriod: Removing segment 'Thu Aug  8 14:03:14 2019' <-> 'Fri Aug  9 14:03:14 2019' from TimePeriod 'never'
[2019-08-08 14:03:14 +0200] debug/TimePeriod: Removing segment 'Thu Aug  8 14:03:14 2019' <-> 'Fri Aug  9 14:03:14 2019' from TimePeriod 'offDuty'
[2019-08-08 14:03:14 +0200] debug/TimePeriod: Adding segment 'Thu Aug  8 00:00:00 2019' <-> 'Thu Aug  8 23:59:00 2019' to TimePeriod 'offDuty'
[2019-08-08 14:03:14 +0200] debug/TimePeriod: Adding segment 'Fri Aug  9 00:00:00 2019' <-> 'Fri Aug  9 23:59:00 2019' to TimePeriod 'offDuty'
[2019-08-08 14:03:14 +0200] debug/TimePeriod: Merge TimePeriod 'offDuty' with 'onDuty' Method: exclude
[2019-08-08 14:03:14 +0200] debug/TimePeriod: Removing segment 'Thu Aug  8 12:35:00 2019' <-> 'Thu Aug  8 14:05:00 2019' from TimePeriod 'offDuty'
[2019-08-08 14:03:14 +0200] debug/TimePeriod: Removing segment 'Fri Aug  9 09:00:00 2019' <-> 'Fri Aug  9 10:00:00 2019' from TimePeriod 'offDuty'
[2019-08-08 14:03:14 +0200] debug/TimePeriod: Removing segment 'Thu Aug  8 14:03:14 2019' <-> 'Fri Aug  9 14:03:14 2019' from TimePeriod '24x7'
[2019-08-08 14:03:14 +0200] debug/TimePeriod: Adding segment 'Thu Aug  8 00:00:00 2019' <-> 'Fri Aug  9 00:00:00 2019' to TimePeriod '24x7'
[2019-08-08 14:03:14 +0200] debug/TimePeriod: Adding segment 'Fri Aug  9 00:00:00 2019' <-> 'Sat Aug 10 00:00:00 2019' to TimePeriod '24x7'
[2019-08-08 14:08:14 +0200] debug/TimePeriod: Removing segment 'Fri Aug  9 14:03:14 2019' <-> 'Fri Aug  9 14:08:14 2019' from TimePeriod 'never'
[2019-08-08 14:08:14 +0200] debug/TimePeriod: Removing segment 'Fri Aug  9 14:03:14 2019' <-> 'Fri Aug  9 14:08:14 2019' from TimePeriod 'onDuty'

If you grep 12:35 for instance it seems that segments addition/removal order is not the same.
So it has something to deal with API. In my production case I have a distributed architecture so probably another case.

PS: timeperiod in this example:

object TimePeriod "onDuty" {
   // object attributes
   excludes = []
   ranges = {
     monday = "09:00-10:00"
     tuesday = "09:00-10:00"
     wednesday = "09:00-10:00"
     thursday = "12:35-14:05"
     friday = "09:00-10:00"
     saturday = "09:00-10:00"
     sunday = "09:00-10:00"
   }
}

dnsmichi · 2019-08-08T12:29:03Z

Sounds like #7239 if you always need to restart twice.

darkweaver87 · 2019-08-08T14:05:28Z

You're right, the double restart did the trick but in a distributed architecture it seems that is_inside is always to true. I tried to restart both masters twice but it doesn't work :-/

dnsmichi · 2019-08-08T16:18:29Z

We're a bit busy with RC testing, so debugging this may take a while. Writing from my ipad here. Meanwhile, I'd suggest to analyse in the debug logs if there's an update between the masters on TimePeriods. I doubt it, but why should it be true all the time. Also, check that the TimePeriod object has paused=false being active. Not sure why that would influence segment calculation, but that's code I am not familiar with.

If you're brave, use the centos7-dev vagrant box, compile icinga2 and add breakpoints in gdb for these calculations. The development docs have more insights.

darkweaver87 · 2019-08-13T05:26:49Z

OK I understand, no problem. I actually have a workaround by defining a timeperiod by manually computing offDuty periods :-)
The paused value is true. Here is the complete output of the console:

<1> => DateTime()
{
   type = "DateTime"
   value = 1565673496.336826
}
<2> => get_time_period("offDuty")
{
   __name = "offDuty"
   active = true
   display_name = "offDuty"
   excludes = [ "onDuty" ]
   extensions = {
   	DbObject = {
   		type = "Object"
   	}
   }
   ha_mode = 0.000000
   includes = [ ]
   is_inside = true
   name = "offDuty"
   original_attributes = null
   package = "shinken_migration"
   pause_called = false
   paused = true
   prefer_includes = true
   ranges = {
   	friday = "00:00-23:59"
   	monday = "00:00-23:59"
   	thursday = "00:00-23:59"
   	tuesday = "00:00-23:59"
   	wednesday = "00:00-23:59"
   }
   resume_called = false
   segments = [ {
   	begin = 1565647200.000000
   	end = 1565733540.000000
   }, {
   	begin = 1565733600.000000
   	end = 1565819940.000000
   } ]
   source_location = {
   	first_column = 1.000000
   	first_line = 93.000000
   	last_column = 27.000000
   	last_line = 93.000000
   	path = "/var/lib/icinga2/api/packages/shinken_migration/35629376-2ba1-476b-8dd6-173084a7a540/zones.d/global-templates/timeperiods.conf"
   }
   start_called = true
   state_loaded = true
   stop_called = false
   templates = [ "offDuty", "legacy-timeperiod" ]
   type = "TimePeriod"
   update = {
   	arguments = [ "tp", "begin", "end" ]
   	deprecated = false
   	name = "Internal#LegacyTimePeriod"
   	side_effect_free = false
   	type = "Function"
   }
   valid_begin = 1565647200.000000
   valid_end = 1565819940.000000
   vars = null
   version = 0.000000
   zone = "global-templates"
}
<3> => get_time_period("onDuty")
{
   __name = "onDuty"
   active = true
   display_name = "onDuty"
   excludes = [ ]
   extensions = {
   	DbObject = {
   		type = "Object"
   	}
   }
   ha_mode = 0.000000
   includes = [ ]
   is_inside = true
   name = "onDuty"
   original_attributes = null
   package = "shinken_migration"
   pause_called = false
   paused = true
   prefer_includes = true
   ranges = {
   	"2018-05-10" = "00:00-23:59"
   	"2019-01-01" = "00:00-23:59"
   	"2019-05-01" = "00:00-23:59"
   	"2019-05-08" = "00:00-23:59"
   	"2019-05-30" = "00:00-23:59"
   	"2019-07-14" = "00:00-23:59"
   	"2019-08-15" = "00:00-23:59"
   	"2019-11-01" = "00:00-23:59"
   	"2019-11-11" = "00:00-23:59"
   	"2019-12-25" = "00:00-23:59"
   	"2020-01-01" = "00:00-23:59"
   	"2020-04-13" = "00:00-23:59"
   	"2020-05-01" = "00:00-23:59"
   	"2020-05-08" = "00:00-23:59"
   	"2020-05-21" = "00:00-23:59"
   	"2020-07-14" = "00:00-23:59"
   	"2020-08-15" = "00:00-23:59"
   	"2020-11-01" = "00:00-23:59"
   	"2020-11-11" = "00:00-23:59"
   	"2020-12-25" = "00:00-23:59"
   	"2021-01-01" = "00:00-23:59"
   	"2021-04-05" = "00:00-23:59"
   	"2021-05-01" = "00:00-23:59"
   	"2021-05-08" = "00:00-23:59"
   	"2021-05-13" = "00:00-23:59"
   	"2021-07-14" = "00:00-23:59"
   	"2021-08-15" = "00:00-23:59"
   	"2021-11-01" = "00:00-23:59"
   	"2021-11-11" = "00:00-23:59"
   	"2021-12-25" = "00:00-23:59"
   	"2022-04-18" = "00:00-23:59"
   	"2022-05-26" = "00:00-23:59"
   	"2023-04-10" = "00:00-23:59"
   	"2023-05-18" = "00:00-23:59"
   	"2024-04-01" = "00:00-23:59"
   	"2024-05-09" = "00:00-23:59"
   	"2025-04-21" = "00:00-23:59"
   	"2025-05-29" = "00:00-23:59"
   	"2026-04-06" = "00:00-23:59"
   	"2026-05-14" = "00:00-23:59"
   	"2027-03-29" = "00:00-23:59"
   	"2027-05-06" = "00:00-23:59"
   	"2028-04-17" = "00:00-23:59"
   	"2028-05-25" = "00:00-23:59"
   	"2029-04-02" = "00:00-23:59"
   	"2029-05-10" = "00:00-23:59"
   	"2030-04-22" = "00:00-23:59"
   	"2030-05-30" = "00:00-23:59"
   	"2031-04-14" = "00:00-23:59"
   	"2031-05-22" = "00:00-23:59"
   	"august 15" = "00:00-23:59"
   	"december 25" = "00:00-23:59"
   	friday = "00:00-09:59,18:01-23:59"
   	"january 1" = "00:00-23:59"
   	"july 14" = "00:00-23:59"
   	"may 1" = "00:00-23:59"
   	"may 8" = "00:00-23:59"
   	monday = "00:00-09:59,18:01-23:59"
   	"november 1" = "00:00-23:59"
   	"november 11" = "00:00-23:59"
   	saturday = "00:00-23:59"
   	sunday = "00:00-23:59"
   	thursday = "00:00-09:59,18:01-23:59"
   	tuesday = "00:00-09:59,18:01-23:59"
   	wednesday = "00:00-09:59,18:01-23:59"
   }
   resume_called = false
   segments = [ {
   	begin = 1565647200.000000
   	end = 1565683140.000000
   }, {
   	begin = 1565712060.000000
   	end = 1565733540.000000
   }, {
   	begin = 1565733600.000000
   	end = 1565769540.000000
   }, {
   	begin = 1565798460.000000
   	end = 1565819940.000000
   } ]
   source_location = {
   	first_column = 1.000000
   	first_line = 116.000000
   	last_column = 26.000000
   	last_line = 116.000000
   	path = "/var/lib/icinga2/api/packages/shinken_migration/35629376-2ba1-476b-8dd6-173084a7a540/zones.d/global-templates/timeperiods.conf"
   }
   start_called = true
   state_loaded = true
   stop_called = false
   templates = [ "onDuty", "legacy-timeperiod" ]
   type = "TimePeriod"
   update = {
   	arguments = [ "tp", "begin", "end" ]
   	deprecated = false
   	name = "Internal#LegacyTimePeriod"
   	side_effect_free = false
   	type = "Function"
   }
   valid_begin = 1565647200.000000
   valid_end = 1565819940.000000
   vars = null
   version = 0.000000
   zone = "global-templates"
}

Unfortunately I won't have the time to debug this for the moment :-/

dnsmichi · 2019-08-13T06:37:17Z

It might be related to serializer fixes with the segments, discussed and fixed with @Elias481 earlier. Though I'm in the midst of 2.11 testing and Icinga meetup Linz preparations, so it will take a while.

darkweaver87 · 2019-08-20T07:34:31Z

OK no problem I understand :-)

Elias481 · 2019-08-24T20:48:34Z

I don't think is related to serializer fixes in this case, at least I don't see any connection.
And I have no idea how it could be in "start_called" state without beeing intiaielized and have started a time to refresh them. Also I do not exactly see what paused mean (but as far as I see it cannot have the effect that start_called is the state but timeranges not initializes).
I don't have a HA setup for testing in place and no time currenlty.

refs #7398

…t UpdateRegion() refs #7398

refs #7398

Al2Klimov · 2020-02-27T09:06:38Z

@darkweaver87 Please could you test whether the snapshot packages are still affected. If yes, please also test the packages from here – pick your OS from the "binary" column and then "Download" the "Job artifacts".

darkweaver87 · 2020-02-27T12:23:36Z

@Al2Klimov: OK I will do but I won't have the time in the next 2 months (at least) unfortunatelly.
May it be better to include this in a unit test suite ?

Al2Klimov · 2020-02-27T12:30:49Z

Don't worry, we have time. 🙂

darkweaver87 · 2020-02-27T12:37:48Z

OK anyway thanks for trying to fix it :-)

Al2Klimov · 2020-02-27T13:14:59Z

If the "Job artifacts" are already gone while you're going to test them, please let me know – I'll re-create them.

Al2Klimov · 2021-08-10T19:19:15Z

PING @darkweaver87

darkweaver87 · 2021-10-19T06:44:47Z

Hello,

Sorry but I don't work for my previous company anymore, thus I don't have a working environment to validate/invalidate this.

Rémi

jinowolski · 2022-05-17T09:23:26Z

@darkweaver87 Please could you test whether the snapshot packages are still affected. If yes, please also test the packages from here – pick your OS from the "binary" column and then "Download" the "Job artifacts".

I am experiencing the same issue in icinga2 2.10.3-2+deb10u1 (Debian Buster). Could I verify the fix?

refs #7398

…t UpdateRegion() refs #7398

refs #7398

Al2Klimov · 2022-05-19T08:23:50Z

Yes, with these packages:

https://git.icinga.com/packaging/deb-icinga2/-/jobs/153741/artifacts/download

refs #7398

…t UpdateRegion() refs #7398

refs #7398

…t UpdateRegion() refs #7398

refs #7398

Al2Klimov · 2023-02-22T14:51:10Z

ref/IP/44756

refs #7398

…t UpdateRegion() refs #7398

refs #7398

…t UpdateRegion() refs #7398

refs #7398

…t UpdateRegion() refs #7398

refs #7398

icinga-probot · 2024-08-20T08:06:09Z

Someone closed this issue just now, but due to a missing feature in the GitHub API and the high amount of comments here I can't figure out whether this issue was closed due to a PR merge. Please check by yourself whether this issue is on the correct milestone.

dnsmichi added area/configuration DSL, parser, compiler, error handling needs feedback We'll only proceed once we hear from you again labels Aug 7, 2019

dnsmichi added the bug Something isn't working label Aug 8, 2019

Al2Klimov self-assigned this Feb 25, 2020

Al2Klimov added a commit that referenced this issue Feb 26, 2020

Drop TimePeriod#FindNextTransition()

405809a

refs #7398

Al2Klimov added a commit that referenced this issue Feb 26, 2020

TimePeriod: consult GetIncludes() and GetExcludes() in IsInside(), no…

2145a57

…t UpdateRegion() refs #7398

Al2Klimov mentioned this issue Feb 26, 2020

TimePeriod: consult GetIncludes() and GetExcludes() in IsInside(), not UpdateRegion() #7855

Open

Al2Klimov added a commit that referenced this issue Feb 26, 2020

Drop TimePeriod#Merge()

810df35

refs #7398

Al2Klimov assigned darkweaver87 and unassigned Al2Klimov Feb 27, 2020

Al2Klimov added a commit that referenced this issue May 18, 2022

Drop TimePeriod#FindNextTransition()

83badc6

refs #7398

Al2Klimov added a commit that referenced this issue May 18, 2022

TimePeriod: consult GetIncludes() and GetExcludes() in IsInside(), no…

624148d

…t UpdateRegion() refs #7398

Al2Klimov added a commit that referenced this issue May 18, 2022

Drop TimePeriod#Merge()

d415b76

refs #7398

Al2Klimov added a commit that referenced this issue Jun 7, 2022

Drop TimePeriod#FindNextTransition()

e813632

refs #7398

Al2Klimov added a commit that referenced this issue Jun 7, 2022

TimePeriod: consult GetIncludes() and GetExcludes() in IsInside(), no…

f6f5fd5

…t UpdateRegion() refs #7398

Al2Klimov added a commit that referenced this issue Jun 7, 2022

Drop TimePeriod#Merge()

3164a45

refs #7398

yhabteab pushed a commit that referenced this issue Jun 22, 2022

Drop TimePeriod#FindNextTransition()

441e25f

refs #7398

yhabteab pushed a commit that referenced this issue Jun 22, 2022

TimePeriod: consult GetIncludes() and GetExcludes() in IsInside(), no…

769de8d

…t UpdateRegion() refs #7398

yhabteab pushed a commit that referenced this issue Jun 22, 2022

Drop TimePeriod#Merge()

cef46e5

refs #7398

Al2Klimov added the ref/IP label Feb 22, 2023

Al2Klimov added a commit that referenced this issue Apr 11, 2023

Drop TimePeriod#FindNextTransition()

272e798

refs #7398

Al2Klimov added a commit that referenced this issue Apr 11, 2023

TimePeriod: consult GetIncludes() and GetExcludes() in IsInside(), no…

e93f632

…t UpdateRegion() refs #7398

Al2Klimov added a commit that referenced this issue Apr 11, 2023

Drop TimePeriod#Merge()

50cd84e

refs #7398

Al2Klimov added a commit that referenced this issue Apr 11, 2023

Drop TimePeriod#FindNextTransition()

0cfcc9d

refs #7398

Al2Klimov added a commit that referenced this issue Apr 11, 2023

TimePeriod: consult GetIncludes() and GetExcludes() in IsInside(), no…

8fd91e9

…t UpdateRegion() refs #7398

Al2Klimov added a commit that referenced this issue Apr 11, 2023

Drop TimePeriod#Merge()

5c20af2

refs #7398

Al2Klimov added a commit that referenced this issue Apr 13, 2023

Drop TimePeriod#FindNextTransition()

329f4ae

refs #7398

Al2Klimov added a commit that referenced this issue Apr 13, 2023

TimePeriod: consult GetIncludes() and GetExcludes() in IsInside(), no…

8f9c769

…t UpdateRegion() refs #7398

Al2Klimov added a commit that referenced this issue Apr 13, 2023

Drop TimePeriod#Merge()

611d408

refs #7398

This was referenced May 31, 2023

Icinga Timeperiod exclusion exceeded to next day #8741

Closed

Timeperiod broken - not allowed segment for the next day are added #9781

Closed

yhabteab mentioned this issue Jan 29, 2024

Fix broken TimePeriod/ScheduledDowntimes #9983

Merged

yhabteab added this to the 2.15.0 milestone Jan 29, 2024

Al2Klimov removed their assignment Apr 25, 2024

Al2Klimov assigned yhabteab May 28, 2024

julianbrost closed this as completed in #9983 Aug 20, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Timeperiod exclusions doesn't work as expected #7398

Timeperiod exclusions doesn't work as expected #7398

darkweaver87 commented Aug 6, 2019 •

edited

Loading

dnsmichi commented Aug 7, 2019

darkweaver87 commented Aug 8, 2019 •

edited

Loading

darkweaver87 commented Aug 8, 2019

dnsmichi commented Aug 8, 2019

darkweaver87 commented Aug 8, 2019

darkweaver87 commented Aug 8, 2019 •

edited

Loading

dnsmichi commented Aug 8, 2019

darkweaver87 commented Aug 8, 2019

dnsmichi commented Aug 8, 2019

darkweaver87 commented Aug 13, 2019 •

edited

Loading

dnsmichi commented Aug 13, 2019

darkweaver87 commented Aug 20, 2019

Elias481 commented Aug 24, 2019

Al2Klimov commented Feb 27, 2020

darkweaver87 commented Feb 27, 2020

Al2Klimov commented Feb 27, 2020

darkweaver87 commented Feb 27, 2020

Al2Klimov commented Feb 27, 2020

Al2Klimov commented Aug 10, 2021

darkweaver87 commented Oct 19, 2021

jinowolski commented May 17, 2022

Al2Klimov commented May 19, 2022

Al2Klimov commented Feb 22, 2023

icinga-probot bot commented Aug 20, 2024

Timeperiod exclusions doesn't work as expected #7398

Timeperiod exclusions doesn't work as expected #7398

Comments

darkweaver87 commented Aug 6, 2019 • edited Loading

Describe the bug

To Reproduce

Expected behavior

Your Environment

dnsmichi commented Aug 7, 2019

darkweaver87 commented Aug 8, 2019 • edited Loading

darkweaver87 commented Aug 8, 2019

dnsmichi commented Aug 8, 2019

darkweaver87 commented Aug 8, 2019

darkweaver87 commented Aug 8, 2019 • edited Loading

dnsmichi commented Aug 8, 2019

darkweaver87 commented Aug 8, 2019

dnsmichi commented Aug 8, 2019

darkweaver87 commented Aug 13, 2019 • edited Loading

dnsmichi commented Aug 13, 2019

darkweaver87 commented Aug 20, 2019

Elias481 commented Aug 24, 2019

Al2Klimov commented Feb 27, 2020

darkweaver87 commented Feb 27, 2020

Al2Klimov commented Feb 27, 2020

darkweaver87 commented Feb 27, 2020

Al2Klimov commented Feb 27, 2020

Al2Klimov commented Aug 10, 2021

darkweaver87 commented Oct 19, 2021

jinowolski commented May 17, 2022

Al2Klimov commented May 19, 2022

Al2Klimov commented Feb 22, 2023

icinga-probot bot commented Aug 20, 2024

darkweaver87 commented Aug 6, 2019 •

edited

Loading

darkweaver87 commented Aug 8, 2019 •

edited

Loading

darkweaver87 commented Aug 8, 2019 •

edited

Loading

darkweaver87 commented Aug 13, 2019 •

edited

Loading