Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #4199] multiple idomod modules: only first gets data from registered callback functions #1282
This issue has been migrated from Redmine: https://dev.icinga.com/issues/4199
Created by mfriedrich on 2013-05-18 17:45:50 +00:00
once a module gets loaded via dlopen() it registers its callback functions. if one loads multiple modules of the same binary, the exported symbol space is shared and only the first entry wins.
2013-05-18 18:51:17 +00:00 by (unknown) 5248386
2013-05-22 12:46:13 +00:00 by (unknown) a84cd3d
Updated by mfriedrich on 2013-05-18 18:18:22 +00:00
the root cause is the omd patch, removing the temporary copy of the neb module itsself. reverting the patch, and adding a revamped version of the original allows us to trick dlopen again into at least 2 different binaries, with 2 different symbol spaces and therefore having the registered callback functions for their own.
while having this fixed, 2 idomod modules loaded will not only cause 2 ido2db connections, but send actual data. the initial api handshake sending instance_name over to ido2db does not require any callback function symbol, but is done during neb module init!
i haven't seen much benefit from the direct dlopen loading (only some tmpfs permission issues), so i do not see a showstopper to fix that for 1.9.1 - marking this as CHANGE then ofc.
Considering this a bug, disabling a feature of Icinga - now that we have the socket queue in ido2db, loading more than one idomod module sounds like a good (backup) idea too.
What do others think?
Updated by mfriedrich on 2013-05-18 18:40:11 +00:00
Ok, some more details.
When the first idomod module gets loaded via dlopen, everything is fine. the symbol space gets registered and so on.
So, how does the initial handshake with ido2db and different instance_name's happen? Well, during neb_load_module() the neb module gets directly loaded, but the neb module's init function is still the first symbol registered. That does not hurt here, because for every module attemped to be loaded (even if symbols are ignored by dlopen!) the init function is passed with the module arguments.