On Wed, May 25, 2011 at 4:38 PM, Markus Elger <markus.elger@unister.de> wrote:
Hi @all,

Hi :)
 
we've tested our configuration with shinken the last days and we found
some bugs or at least nice to have features. ;)
Ok, lets see this :)



A very very short description of our configuration:

- a shinken master
- some satellites with scheduler and poller


1
When I add the module Status-Dat to my broker (on the master, with a
single broker) and restart shinken, the status.dat is created, but not
filled with data (should be updated every 15 seconds). It seems that the
module simple-log has problems with archiving old logs (directory
'archives' not found). After I created the directory archives, deleted
status.dat and objects.cache I restarted shinken and everything worked.
I think it would be nice if the simple-log wouldn't block the other
modules from running?
[...]
IOError: [Errno 2] No such file or directory:
u'archives/nagios-05-24-2011-00.log'
 
The internal modules are not dependent each other, so I don't understand this problem. Can you try to reproduce it without the log module? I think it's a pure status.dat bug, because the broker is giving the brok to all modules, and if one die, it's just put in another queue but still give the brok to the other modules (or at least it should).

 


2
I have some hosts with 'parents' which are not in the same realm. During
the configcheck the following error was thrown --> Error : the realm
configuration of your hosts is not good because there a more than one
realm in one pack (host relations).
But at the end the configcheck says that everything looks good (Things
look okay - No serious problems were detected during the pre-flight
check). But Shinken doesn't check and process the Host.
It would be nice, if such an Error could be mentioned at the end of the
configcheck. So I have to search the whole checkconfig output, because
there 'maybe' is a mistake which is not mentioned in the summary at the
end.
It's a real problem here for sure. I'll have a look at it. (ticket https://sourceforge.net/apps/trac/shinken/ticket/263)


3
When I start shinken, the arbiter splits the configuration and send it
to the schedulers. They begin to work (I watched this in the logs). But
in Thruk the number of hosts and services is changing repeatedly in the
[...] 
showed up. This is important, because together with my bug report number
2 I have to make sure that shinken is checking all hosts and services.

No in fact it's a problem in the LiveStatus module. We put some fixes on this part some days ago for the 0.6.4, is your version ok? I think there is still some problems here for the "object creation pass" that give us some bad length of list, we will hunt this :)
 

4
When I create a realm and assign a scheduler and poller to it, but
don't make him a member of the default realm I get no error message.
The scheduler and poller in the created realm get their configuration
from the arbiter, but no broker will output data, because none is
assigned to the new realm?

Isn't it better if there is any warning/error message during
configcheck?
It do not have to be a member of the "default" realm. But the fact that they will have no broker can be a reason to raise a warning it's true :)
Another ticket :) (https://sourceforge.net/apps/trac/shinken/ticket/264)


5
The configcheck incorrectly counts the number of hosts in a realm.
Well...I think it's better when I show you an example, instead of
describing it ;)
[...]


You see i've got 574 hosts which are in realms. But where are they after
'Creating packs for realms'?  The realm test8 with it's 58 Hosts is the
server with the realm, where the shinken master runs, and from where I
run the configcheck (only on the master checkconfig counted correct).
As I see the hosts are put to their realms correctly, because when I run
shinken everything works fine. But it would be nice if this summary will
be accurate, too ;)
Oh, still another ticket :) should be the easier of all :) (https://sourceforge.net/apps/trac/shinken/ticket/265)


So, that's it for now. ;)
Ok thanks for all theses bugs reports :)

The first one and the thruk count aside, others should be quickly fixed :)

Regards,


Jean
 


Markus Elger
Linux-Systemadministrator

Unister GmbH
Barfußgässchen 11 | 04109 Leipzig

Telefon: +49 (0)341 49288 4537
markus.elger@unister.de
www.unister.de

Vertretungsberechtigter Geschäftsführer: Thomas Wagner
Amtsgericht Leipzig, HRB: 19056