[dev.icinga.com #12548] IDO: entry_time of all comments is set to the date and time when Icinga 2 was restarted (Regression)

[icinga-migration]

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

Created by elippmann on 2016-08-25 13:18:42 +00:00

Assignee: (none)
Status: New (closed on 2016-08-25 15:03:45 +00:00)
Target Version: (none)
Last Update: 2016-11-18 14:11:48 +00:00 (in Redmine)

Icinga Version: 2.5.3
Backport?: Not yet backported
Include in Changelog: 1

---

This should've been fixed w/ 2.5.0. Unfortunately this is not the case.

The entry_time of all comments is set to the date and time when Icinga 2 was restarted. This affects acks, comments and downtimes.

Steps to reproduce:

• Add a comment
• Wait some seconds
• Restart Icinga 2
• Notice that the entry_time of all comments has been reset

---

Relations:

• copied_to #12548

[icinga-migration]

Updated by elippmann on 2016-08-25 13:18:44 +00:00

• Copied From set to 11182

[icinga-migration]

Updated by elippmann on 2016-08-25 13:19:18 +00:00

• Done % changed from 100 to 0

[icinga-migration]

Updated by elippmann on 2016-08-25 15:03:45 +00:00

• Category deleted DB IDO
• Status changed from New to Rejected

I close this. The contents of /var/lib/icinga2/api/packages/_api/ were screwed somehow.

[icinga-migration]

Updated by tgelf on 2016-08-25 15:41:30 +00:00

• Status changed from Rejected to New

I'll reopen it, have more details with a similar problem. Nothing screwed here :p Environment details:

• RHEL 7, two masters, 2000+ Agents
• has been running 2.4.10, now 2.5.3
• currently there are about 4200 downtimes

After digging through /var/lib/icinga2/api/packages/_api I discovered that there are 30 downtimes with an entry_time in _api, 4100+ with no entry_time. Blind guess: the 30 "good" ones have been created after the upgrade, the others are legacy ones. It's IMO bad practice to manually fiddle with packages/_api, so the Icinga core should take care of fixing those files at startup time.

I also had a look at the IDO. At least the example I used when drilling down had two entries in icinga_scheduleddowntime, one with an older entry_time (not the correct one, btw) and no session_token (NULL), and one with an entry_time corresponding to the last core reload with a session_token.

My conclusion: we need to provide a mechanism that takes care of this. In the environment I'm currently working with there are many downtimes that will still last for a long time, they must somehow be fixed. And while I personally could live with shutting down all master nodes and fixing things with a small script, this is not what we should have to teach the average Icinga user.

[icinga-migration]

Updated by rdesanno on 2016-09-15 20:44:26 +00:00

I can easily reproduce this bug in our environment if you are looking for someone to test a fix or workaround.

[icinga-migration]

Updated by mfriedrich on 2016-11-18 14:11:48 +00:00

• Category set to DB IDO

[sbancal]

👍

[dnsmichi]

I haven't seen this for a year now and consider this resolved.