Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dev.icinga.com #11688] Outdated downtime/comments not removed from IDO database (restart) #4171

Closed
icinga-migration opened this issue Apr 27, 2016 · 21 comments
Labels
area/db-ido Database output blocker Blocks a release or needs immediate attention bug Something isn't working
Milestone

Comments

@icinga-migration
Copy link

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

Created by mhein on 2016-04-27 10:31:11 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2016-06-03 12:45:03 +00:00)
Target Version: 2.5.0
Last Update: 2016-08-08 11:21:02 +00:00 (in Redmine)

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

Hi,

Icinga Web 2 tries to remove downtime 459, native interface tries to remove downtime 468. The native interface wins because this is the real downtime. If you try to delete the downtime in Icinga Web 2, nothing happens.

Kind regards,
Marius

Changesets

2016-06-03 12:40:37 +00:00 by mfriedrich 0ce4139

DB IDO: Ensure to delete outdated comments/downtimes for host/service objects

fixes #11688

Relations:

@icinga-migration
Copy link
Author

Updated by mhein on 2016-04-27 11:06:35 +00:00

This happens if dangling downtimes present in the table.

@icinga-migration
Copy link
Author

Updated by mhein on 2016-04-27 11:40:00 +00:00

There are also dangling api configuration packages creating expired downtimes

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-05-02 07:13:06 +00:00

  • Status changed from New to Assigned
  • Assigned to set to mfriedrich
  • Parent Id set to 11312

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-05-02 07:16:57 +00:00

  • Target Version set to 2.4.8

@icinga-migration
Copy link
Author

Updated by mnardin on 2016-05-02 09:59:10 +00:00

Hi,
we have as well old (already outside time window) downtime objects piling up. Should I create a dedicated issue for that?

Best regards
Mirko

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-05-02 13:35:26 +00:00

I've been investigating on that issue since Friday, I've opened an issue for referencing the fixed commit - #11711. Though I'm not sure if this is the same issue over here but maybe a side-effect.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-05-02 13:35:36 +00:00

  • Relates set to 11711

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-05-06 14:49:14 +00:00

  • Priority changed from Normal to High

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-05-11 12:30:35 +00:00

  • Target Version changed from 2.4.8 to 2.4.9

We cannot reproduce the issue currently but maybe a fix scheduled for 2.4.8 fixes the problem already. Rescheduled for 2.4.9 now.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-05-19 05:07:17 +00:00

  • Target Version changed from 2.4.9 to 2.4.10

Moved to 2.4.10 because we're going to release 2.4.9 today and there's no patch yet.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-05-19 11:29:36 +00:00

  • Target Version changed from 2.4.10 to 307

@icinga-migration
Copy link
Author

Updated by Anonymous on 2016-05-31 04:43:15 +00:00

As michi requestet, relatet to https://monitoring-portal.org/index.php?thread/36215-object-scheduleddowntime-wird-mehrfach-angelegt/&postID=229752#post229752

When creating a scheduled downtime via object and not via apply rule, this object is newly-created everytime, when Icinga2 restarts. It follows, that you have one downtime multiple times in Icingaweb, in the DB and in /var/lib/icinga2/api/packages/_api/XXX-1459918973-1/conf.d/downtimes/

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-06-03 12:30:51 +00:00

Hm I think I found a way to reproduce this issue while looking into #11890:

  • Define a host
  • Start Icinga 2
  • Add a new comment/downtime via Icinga Web 2 / command pipe / api
  • Remove the host config
  • kill -HUP $(pidof icinga2)

Now the comment/downtime object has no host reference anymore, the config file will be deleted.

  • Add the host again
  • kill -HUP $(pidof icinga2)

Comment/downtime still visible in

  • status.dat (Classic UI)
  • DB IDO

Sending in a manual delete has no effect (Icinga 2 doesn't know about the comment/downtime id, and does nothing)

  • status.dat is written in a defined interval (afaik 30s) and will just dump the entire list of comments/downtimes again (the removed one is gone automatically)
  • DB IDO does not get any core update - the comment/downtime will stay there as the core does not know anything about it

So there is no guarantee with inserting a new host/service object into the database and purging old comments/downtimes.

AddComments() and AddDowntimes() will return silently if there are no comments/downtimes found in core memory. Although they will never be purged from the database then.

I'm currently testing a fix.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-06-03 12:33:57 +00:00

The issue with ScheduledDowntime objects is a different one, please collect all the information into a new issue.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-06-03 12:36:12 +00:00

  • Subject changed from Internal downtime id in ido differs from internal id to Outdated downtime/comments not removed from IDO database (restart)

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-06-03 12:45:03 +00:00

  • Status changed from Assigned to Resolved
  • Done % changed from 0 to 100

Applied in changeset 0ce4139.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-06-16 08:11:38 +00:00

  • Target Version changed from 307 to 2.5.0

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-08-02 12:32:42 +00:00

  • Relates set to 12258

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-08-02 12:40:22 +00:00

  • Relates set to 12288

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-08-08 11:21:03 +00:00

  • Parent Id deleted 11312

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-08-08 14:22:50 +00:00

  • Relates set to 12039

@icinga-migration icinga-migration added blocker Blocks a release or needs immediate attention bug Something isn't working area/db-ido Database output labels Jan 17, 2017
@icinga-migration icinga-migration added this to the 2.5.0 milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/db-ido Database output blocker Blocks a release or needs immediate attention bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant