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 #13725] Scheduled downtimes and comments through API/frontend lost after reload #4891

Closed
icinga-migration opened this issue Dec 22, 2016 · 4 comments
Labels
area/api REST API bug Something isn't working

Comments

@icinga-migration
Copy link

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

Created by gvde on 2016-12-22 06:49:36 +00:00

Assignee: (none)
Status: Closed (closed on 2017-01-09 15:44:10 +00:00)
Target Version: (none)
Last Update: 2017-01-09 15:44:10 +00:00 (in Redmine)

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

I had the problem that after a reload/restart of the icinga2 server all scheduled downtimes and comments which were set up through icingaweb2 or through the API where gone.

There were similar bug reports but that problem was supposedly fixed with 2.5.4 while I still had it with 2.5.4. So I looked deeper and found that on CentOS 7 the downtimes are added to the /var/lib/icinga2/api/packages/_api/icinga-1459342026-1/conf.d/downtimes/ directory which contained everything as it should.

Eventually I have noticed that 'icinga2 daemon -C' never loads the files from there. After comparing with other packages I found that the include.conf file was missing in the stage directory, i.e. the file /var/lib/icinga2/api/packages/_api/icinga-1459342026-1/include.conf was missing.

After I manually created the file similar to the ones in other packages the server now loads all downtimes again and everything is working fine.

So I am not sure whether this is a bug or more a feature request: When checking configuration I think it would be could if there was a "sanity" check for the stage directories to include that include.conf file (or at least the one which is in active stage). Otherwise this goes completely unnoticed unless you really know what to look for.

Of course, in the same course checking for the other files in the package directory (active.conf, include.conf, and maybe active-stage?) might be helpful as well.

Technically, the include.conf and active.conf files could just be automatically recreated. If not, there should be at least a warning message during configuration check/startup to point the user into the right direction. Right now, it's quite confusing if you don't reload/restart the server for a while and everything is working fine until all of a sudden it stops because there was a reload...

Unfortunately, I don't know why the include.conf file went missing which obviously should have never happened in the first place...


Relations:

@icinga-migration
Copy link
Author

Updated by vaisov on 2017-01-05 15:09:50 +00:00

Had the same issue. Would be great to have a check and automatically generated file.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2017-01-09 15:43:07 +00:00

  • Relates set to 10638

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2017-01-09 15:44:10 +00:00

  • Status changed from New to Closed

We already have an open issue for that (#10638), thanks though.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2017-01-09 15:44:28 +00:00

  • Relates set to 11012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api REST API bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant