Shinken scheduled_downtime_depth issue -1

[Torsten80]

we currently have a problem with downtimes for some hosts and services.
If we enter a downtime this will not be realized.
I have found that scheduled_downtime_depth has a value of -1 for these.
If you enter the downtime twice, the downtime is realized.

Apart from the fact that it is unclear to me how that happened, I think that should be caught in the program.
For example, a proposal by incrementing only if scheduled_downtime_depth is greater than 0.

Below is the patch that works for us.

--- /root/shinkentest1/downtime.py 2020-02-15 22:24:44.000000000 +0100
+++ downtime.py 2020-02-15 22:53:04.871194126 +0100
@@ -142,7 +142,8 @@
if self.is_in_effect is True:
# This was a fixed or a flexible+triggered downtime
self.is_in_effect = False

•        self.ref.scheduled_downtime_depth -= 1
  

•        if self.ref.scheduled_downtime_depth > 0:
  

•            self.ref.scheduled_downtime_depth -= 1
         if self.ref.scheduled_downtime_depth == 0:
             self.ref.raise_exit_downtime_log_entry()
             self.ref.create_notifications('DOWNTIMEEND')
  

@@ -164,7 +165,8 @@
def cancel(self):
res = []
self.is_in_effect = False

•    self.ref.scheduled_downtime_depth -= 1
  

•    if self.ref.scheduled_downtime_depth > 0:
  

•        self.ref.scheduled_downtime_depth -= 1
     if self.ref.scheduled_downtime_depth == 0:
         self.ref.raise_cancel_downtime_log_entry()
         self.ref.in_scheduled_downtime = False
  

If a negative value for scheduled downtime depth makes sense, I would be grateful for an explanation.

Regards,

Torsten

[geektophe]

I had the same issue, and I think there's a race condition during the retention data dump where the object state is saved before it's fully processed, then scheduled_downtime_depth corrupted when it's reloaded.

I did a pull request (#1990) that excludes scheduled_downtime_depth from retention data and forces its calculation after the retention data is loaded.

We didn't detect such a discrepancy since.

Could you have a test with this patch ?

[geektophe]

This issue should have been fixed by #1990.

Could you have a test with latest sources from master and let me know if this error is still happening ?

[Torsten80]

on CentOS Linux release 7.9.2009 (Core)
shinken update , I got:

_creating /usr/lib/python2.7/site-packages/Shinken-2.4.3-py2.7.egg

Extracting Shinken-2.4.3-py2.7.egg to /usr/lib/python2.7/site-packages

Adding Shinken 2.4.3 to easy-install.pth file

Installed /usr/lib/python2.7/site-packages/Shinken-2.4.3-py2.7.egg

Traceback (most recent call last):

File "setup.py", line 444, in

data_files=data_files,

File "/usr/lib64/python2.7/distutils/core.py", line 152, in setup

dist.run_commands()

File "/usr/lib64/python2.7/distutils/dist.py", line 953, in run_commands

self.run_command(cmd)

File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command

cmd_obj.run()

File "/usr/lib/python2.7/site-packages/setuptools/command/install.py", line 73, in run

self.do_egg_install()

File "/usr/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 655, in install_item

self.process_distribution(spec, dist, deps)

File "/usr/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 701, in process_distribution

distreq.project_name, distreq.specs, requirement.extras

TypeError: init() takes exactly 2 arguments (4 given)_
File "/usr/lib/python2.7/site-packages/setuptools/command/install.py", line 101, in do_egg_install

cmd.run()

File "/usr/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 380, in run

self.easy_install(spec, not self.no_deps)

File "/usr/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 604, in easy_install

return self.install_item(None, spec, tmpdir, deps, True)

_File "/usr/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 655, in install_item

self.process_distribution(spec, dist, deps)

File "/usr/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 701, in process_distribution

distreq.project_name, distreq.specs, requirement.extras

TypeError: init() takes exactly 2 arguments (4 given)__

but shinken is still running well

[geektophe]

I'll have a closer look at this message.