most of the values in logsys.h are very useful for non logsys library
API users.
Allow to import them without sucking the whole lib.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2248 fd59a12c-fef9-0310-b244-a6a79926bd2f
LOGSYS_LEVEL_SECURITY is specific to corosync/openais and it
is used only in the totem configuration.
Drop the special case from logsys that's meant to be a generic
logging library and specify the correct equivalent for totem config.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2245 fd59a12c-fef9-0310-b244-a6a79926bd2f
In LCR, global variable g_component_handle is used to keep handle of loaded
component. If this variable has magic value (0xFFFFFFFF) it means,
"we loaded library, but that library doesn't have any component_register
call -> don't try to destroy interfaces list).
If this variable has other value, it means "we loaded library, it registers,
but it exports some interface, what we currently don't need, so we can delete
that handle from libraries/interfaces list" and variable is set to magic value,
or "we loaded library, it registers and exports what we need -> great return some
nice value", but nobody resets variable to it's magic value.
Sadly, if you have loaded some component (needed), then try to load component,
which don't have component_register function, previously loaded component handle
is destroyed.
This problem happened to clm and quorum services, and cause, that loaded
clm handle was destroyed, so EVT (which need clm) just falls.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2234 fd59a12c-fef9-0310-b244-a6a79926bd2f
This is needed as the objdb order will change as modules are loaded/unloaded and is
also set up to unload non-default services last (which is the opposite of what
something like Pacemaker needs).
In the worst case, the current behavior leads to cluster services (dlm, ocfs2, etc)
failing during shutdown. This patch also ensures that if, for example, cpg is unloaded
then anything that depends on it is unloaded first.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2224 fd59a12c-fef9-0310-b244-a6a79926bd2f
This could probably be more tidy to detect those OS platforms which don't do this instead of hardcoding
to a specific platform we intend to port to.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2221 fd59a12c-fef9-0310-b244-a6a79926bd2f
Fixes rhbz#499918
Functions from ckpt library (like aCkptCheckpointOpen,
saCkptSectionIterationInitialize, ...) internally uses corosync functions
reply_receive, reply_receive_in_buf, ... This functions are included in
coroipcc.c source file and uses global static variable ipc_hdb.
Without patch, coroipcc is linked to shared library (libcoroipcc.so) AND linked
with every corosync libraries (like cpg, ....), so global variable ipc_hdb is
included not only in libcoroipcc.so, but also in libcpg.so, ...
dlm_controld has function retrieve_plocks, and whole binary is linked with
libcoroipcc and libcpg. So ipc_hdb is included TWICE (so has TWO addresses).
Main problem causing the bug was, that reply_receive uses address from one
library, and reply_receive_in_buf uses other. This confuses check of hdb_get
function.
After removing linking of coroipcc.o to cpg, and rather use of dynamic version,
(this means, there is only one instance of ipc_hdb) problem disappeared.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2203 fd59a12c-fef9-0310-b244-a6a79926bd2f
