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 #11129] Internal check for config problems #3919

Closed
icinga-migration opened this issue Feb 10, 2016 · 5 comments
Closed

[dev.icinga.com #11129] Internal check for config problems #3919

icinga-migration opened this issue Feb 10, 2016 · 5 comments
Labels
area/configuration DSL, parser, compiler, error handling enhancement New feature or request
Milestone

Comments

@icinga-migration
Copy link

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

Created by twidhalm on 2016-02-10 13:04:20 +00:00

Assignee: gbeutner
Status: Resolved (closed on 2016-05-11 14:10:04 +00:00)
Target Version: 2.4.8
Last Update: 2016-05-11 14:10:04 +00:00 (in Redmine)

Backport?: Not yet backported
Include in Changelog: 0

Hi,

A coworker of mine spent some time finding a way to determine if an icinga 2 slave / agent instance refused reloading because of configuration issues and his most practical solution was checking for the corresponding logentry.

I can imagine it would be fairly easy to implement an internal variable which indicates if the current configuration (on the filesystem on the master or the current synchronised version on other hosts) is valid and icinga 2 can reload. Whenever the log message about an aborted restart due to invalid config is written to the logfile this variable could be set to false. When a reload / restart succeeds the variable is set to true. It imagine it would be fairly easy to create an embedded check like icinga or cluster that checks the state of this variable.

This way we still don't know if a slave / agent received the current configuration from the config master but at least we could detect problems with instances not running the synced configuration due to errors in it

Cheers,
Thomas

Changesets

2016-05-11 14:07:28 +00:00 by gbeutner 1ad4d9c

Report failed reload attempts for the icinga check

fixes #9060
fixes #9997
fixes #11129

2016-05-12 09:11:03 +00:00 by gbeutner ff24863

Report failed reload attempts for the icinga check

fixes #9060
fixes #9997
fixes #11129

Relations:

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-02-24 20:05:59 +00:00

  • Relates set to 9060

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-02-24 20:06:30 +00:00

  • Category set to Configuration
  • Target Version set to Backlog

Partially a duplicate of #9060 but I'll leave this one open as well.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-02-24 23:32:07 +00:00

  • Relates set to 9997

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-05-11 14:08:54 +00:00

  • Status changed from New to Assigned
  • Assigned to set to gbeutner
  • Target Version changed from Backlog to 2.4.8
  • Include in Changelog changed from 1 to 0

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-05-11 14:10:04 +00:00

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

Applied in changeset 1ad4d9c.

@icinga-migration icinga-migration added enhancement New feature or request area/configuration DSL, parser, compiler, error handling labels Jan 17, 2017
@icinga-migration icinga-migration added this to the 2.4.8 milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/configuration DSL, parser, compiler, error handling enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant