Impossible to load 2 times the module on same Nagios instance
Created by: william-p
Only one instance of Canopsis receive events.
conf:
broker_module=/opt/icinga/lib/neb2amqp.o name=Central kvm09.
broker_module=/opt/icinga/lib/neb2amqp.o name=Central kvm21.
log:
[1360597234] neb2amqp: NEB2amqp 0.3-rc by Capensis. (connector: nagios)
[1360597234] neb2amqp: Please visit us at http://www.canopsis.org/
[1360597234] neb2amqp: CACHE: stat: No such file or directory
[1360597234] neb2amqp: CACHE: /usr/local/nagios/var/canopsis.cache: No such file or directory
[1360597234] neb2amqp: AMQP: Successfully connected
[1360597234] neb2amqp: successfully finished initialization
[1360597234] Event broker module '/opt/icinga/lib/neb2amqp.o' initialized successfully.
[1360597234] neb2amqp: NEB2amqp 0.3-rc by Capensis. (connector: nagios)
[1360597234] neb2amqp: Please visit us at http://www.canopsis.org/
[1360597234] neb2amqp: CACHE: stat: No such file or directory
[1360597234] neb2amqp: CACHE: /usr/local/nagios/var/canopsis.cache: No such file or directory
[1360597234] neb2amqp: successfully finished initialization
Imported comments:
By ziirish on 2013-02-11 16:11:32 UTC
Actually this limitation is due to the way the shared objects work.
In C there is no 'namespace' so every object (function) loaded by a module is "public". This means if you load the same module twice, there might be some conflicts.
As a workaround we could implement a list of AMQP servers handled by the neb.
We could use an ini file to store the differents credentials.
By william-p on 2013-06-26 12:13:08 UTC
Ok, can't fix it.
By linkdd on 2014-11-21 14:00:13 UTC
The problem is not the absence of namespace.
In fact, we store many data in the global scope. It would be OK if we were just reading them. But we write to them.
In a multi-threaded context, the code, and the static data will be loaded once, every thread will share the same memory space for the code and the static data.
Since in C, all variables declared in the global space are stored in the static data space, there won't be any copy-on-write algorithm here.
Loading twice the broker will make the two threads write to the same shared data with no locking, or lock-free algorithm.
TL;DR: Variables in global scope are not easily thread-safe.
So this can be fixed with a better design in the source code. Unfortunately, there will be some time before refactoring.