On Tue, Sep 7, 2010 at 4:58 PM, Hermann Lauer <Hermann.Lauer@iwr.uni-heidelberg.de> wrote:
On Tue, Aug 24, 2010 at 08:35:53AM +0200, nap wrote:
> The configuration can be slitly changed when running, like changing
> command checks, but not a full reload (like with a HUP) or a new host.
> But the objects.dat is something strange, we can look for it. I fink
> it's not the file being read or something like it,but instead the
> broker module that do not recreate all objects (hosts, service) when
> there is a new configuration in the schedulers he get jobs for.
> For the bug hack, can you explain what you see to do not change when
> you restart the arbiter (and only it)? It's the objects.dat that is
> not changed or the status.dat with old values? Or both maybe.
Today I introduced a new service and a host into the configuration
and found the following:
1) object.cache before the config change is no longer overwritten, timestamp
did not change any more. Good.Ok.
2) restarting the arbiter with the new configuration garbles object.cache,
/usr/sbin/nagios3 -v checking shows some duplicate service entry.Outch. One bad point.
3) deleting object.cache and restarting the arbiter didn't help.
Deleting both retention.dat and object.cache and restarting arbiter
didn't help too.Ok, we can say good in fact ;)
4) restarting the broker and the arbiter helps - without deleting any
files. So indeed the config seems to be cached and mixed up in the
broker.Ok. So the problem is in the status.dat module that should add new objects without deleting old ones with the same name. I'm on it.
5) adding an additional command section (without using it) and restarting
the arbiter works as expected: object.cache changes and increases
only with the additional command section. Great.Cool :)
More to come, thanks for your help.Thanks for reporting this bug and help us to hunt him down :)
This SF.net Dev2Dev email is sponsored by:
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
Shinken-devel mailing list