Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #4155] objects.cache does not get updated on (re)start, but config verify #1276

Closed
icinga-migration opened this issue May 8, 2013 · 10 comments
Labels
Milestone

Comments

@icinga-migration
Copy link

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

Created by Enfileyb on 2013-05-08 18:19:30 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2013-05-22 07:31:44 +00:00)
Target Version: 1.9.1
Last Update: 2013-05-22 07:31:44 +00:00 (in Redmine)

Icinga Version: 1.9.0
OS Version: CentOS 6.3

Hallo zusammen,

ich bin mir imo nicht sicher, ob das Problem wirklich das neue Classic UI ist, aber hier taucht es auf..

Seit dem Update auf 1.9 habe ich in der Testumgebung mit dem neuen Classic UI folgendes Problemchen:

Wenn ich etwas an der Konfiguration ändere, also einen neuen Host oder Service hinzufüge und Icinga über External Command restarte, dann ist die neue Konfig in den CGIs nicht zu sehen. Auch z.B. ein Kommentar vom neuen Host wird nicht angezeigt.

Der Core kennt den neuen Host:
In der Tactical Overview oder Performance Info ist zu sehen, das ein Host mehr überwacht wird als vorher.
Die Host- und Service-Checks werden ausgeführt usw.; auch in Icinga-Web (damit in der DB) ist der neue Host vorhanden und sichtbar.

Sobald ich über das Init-Script ein reload/restarte/stop&start veranlasse, tauchen die neuen Hosts/Services im Classic UI auf.

Da bei jeder Aktion über das Init-Scipt auch die objects.cache neu aufgebaut wird, vermute ich das hier der Hund begraben liegt?

Noch ein Hinweis, der vielleicht hilft:

  1. Host A ist im Classic UI sichtbar
  2. Host A wird aus Konfig entfernt, Host B wird hinzugefügt & Restart über External Command

Host A ist im Classic UI weg, Host B ist nicht zu sehen.

  1. Host A wird wieder hinzugefügt (Host B unverändert) & Restart über External Command

Host A ist im Classic UI wieder sichtbar.
----> War ein Host zuvor bekannt (objects.cache?) taucht er auch wieder auf..

Dieses Problem ist in unserer (quasi identisch konfigurierten) Produktiv-Umgebung mit Icinga 1.8.3 nicht vorhanden; wenn ich dort einen Restart über External Command auslöse, ist die neue Konfig im Classic UI so wie erwartet sichtbar.

Ich hoffe dieses Phenomen ist auch von anderen nachvollziehbar..
Pfade in der neuen cgi.cfg habe ich natürlich inzwischen doppelt und dreifach geprüft ;-)

Ich hoffe ich habe hier nichts übersehen..
Falls Ihr noch Informationen braucht, werde ich natürlich versuchen diese zu liefern.

MfG.

Enfileyb

Attachments

Changesets

2013-05-12 10:37:43 +00:00 by (unknown) bad1155

update Changelog for #4155

refs #4155
@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-05-08 19:24:44 +00:00

This is an international project, so English, please.

@icinga-migration
Copy link
Author

Updated by Enfileyb on 2013-05-08 19:57:15 +00:00

Im sorry..

Should we delete / close this Bug and open a new one with English subject?

If not here the English version:

Subject: New configuration / New objects are not visible in Classic UI after "RESTART_PROGRAM" by external command

Hi,

im not sure if this is really a bug with Classic UI, but it only happens with Classic UI.

After updating our test environment to Icinga 1.9, we recognized the following problem:

If you add a new object (host or service) to the configuration and restart Icinga by external command, the new objects will not be visible in Classic UI.

The Core knows about the new objects:
In tactical overview or performance info, the new object is counted with the total objects.
Host and service checks for the new objects are executed and the objects are visible in Icinga-Web (therefore they are in the database).

If you restart Icinga using the init-script (reload/restart/stop&start) the new objects become visible in Classic UI.

As objects.cache gets rebuild when restarting with the init-script, i guess this issue may be related to objects.cache.

Another hint:

  1. host A is visible in Classic UI
  2. host A is removed and host B is added to configuration & Icinga restarted by external command

host A is no longer visible, host B is not visible

  1. host A is readded to configuration (host B stays unchanged) & Icinga restarted by external command

host A is visible again, host B still not visible
----> if a host was known (objects.cache?) he becomes visible again.

I checked this behavoiour with our Icinga 1.8.3 production environment. If i add new objects and schedule a restart by external command, the new objects become visible.

Of course i have checked the paths to objects.cache and status.dat in the new cgi.cfg :-)

If you need any further information, i will try to supply them asap.

Best regards,

Enfileyb

@icinga-migration
Copy link
Author

Updated by idl0r on 2013-05-11 22:31:52 +00:00

  • File added 0001-Fix-writing-the-objects.cache-file.patch

Hi Enfileyb,

please try the attached patch.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-05-11 23:54:43 +00:00

  • Project changed from 19 to Core, Classic UI, IDOUtils
  • Subject changed from Aktualisierte Konfig /neue Objekte (nach RESTART_PROGRAM als External Command) nicht sichtbar in den "cgis" to objects.cache only updated with -v enabled
  • Status changed from New to Assigned
  • Assigned to set to mfriedrich
  • Target Version set to 1.9.1

thx looks valid.

@icinga-migration
Copy link
Author

Updated by Enfileyb on 2013-05-12 00:16:07 +00:00

Hi,

i will test the patch on monday and report back.

Just for my understanding:
Classic UI before 1.9 didn't use objects.cache file, but only status file?

Many thanks,

Enfileyb

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-05-12 10:32:21 +00:00

  • Subject changed from objects.cache only updated with -v enabled to objects.cache does not get updated on (re)start, but config verify

it's hard to track down as the initscript always invokes -v before actually (re)starting the core. thanks for the fix, will redirect that into 1.9.1

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-05-12 10:34:02 +00:00

@Enfileyb

classic ui uses both, but the status counting of tac.cgi (also used in the status header) does only count the status objects from status.dat, and does not take the objects.cache config items into account. this is also why the regression was not that obvious.

@icinga-migration
Copy link
Author

Updated by Enfileyb on 2013-05-13 15:10:25 +00:00

Hi again!

I have tested the patch (changed line 255 in config.c) and now objects.cache is updated again, when a restart is triggered by external command.

Works for me..

Thx,

Enfileyb

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-05-13 19:48:17 +00:00

thanks for testing.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-05-22 07:31:44 +00:00

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

merged to r1.9

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant