On Tue, Sep 7, 2010 at 5:03 PM, nap <[email protected]> wrote:
>
>
> On Tue, Sep 7, 2010 at 4:58 PM, Hermann Lauer <
> [email protected]> wrote:
>
>> Hello,
>>
>> On Tue, Aug 24, 2010 at 08:35:53AM +0200, nap wrote:
>> > Hi,
>> >
>> > 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.
>>
>> Hi,
>
>
>> 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 :)
>
> Hi,
I just update the status module code. Can you test it? (cf
http://shinken.git.sourceforge.net/git/gitweb.cgi?p=shinken/shinken;a=blobdiff;f=shinken/modules/status_dat_broker/status_dat_broker.py;h=a05896cb290a7b2ce6b471e5a4b31d09dbd98fe2;hp=3d049fd993447235215fc54f3238326c4c7a892d;hb=270925252c2e7a66e657f7032740f819c3c3ecae;hpb=95c5f14183c684a635e3de1672c391a693133509
)
Now the module should see that a scheduler change conf and so will delete
previous hosts and service of this scheduler.
Thanks.
Jean
>
> Jean
>
>
>>
>> Hermann
>>
>> --
>> Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres
>> Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
>> IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
>> Email: [email protected]
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Shinken-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>>
>
>
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Shinken-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shinken-devel
