Pacemaker should define LOG_DOMAIN internally and use g_log_set_handler() instead of g_log_set_default_handler().
This would allow external apps to link with Pacemaker libraries and still be able to use their own default glib log handler.
Description
Description
Revisions and Commits
Revisions and Commits
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T840 Improve Pacemaker API initialization | ||
| Merged | clumens | T837 Use glib logging domain |
Event Timeline
Comment Actions
Related, we have this in logging.c:
/* and for good measure... - this enum is a bit field (!) */ g_log_set_always_fatal((GLogLevelFlags) 0); /*value out of range */
However, the glib docs say this:
Libraries should not call this function, as it affects all messages logged by a process, including those from other libraries.
Which leads me to believe we should remove this from logging.c and if our command line tools want to do this, they should add the call themselves. I'm not sure if there would be unintended consequences, however.
Comment Actions
This disables glib aborting after an error message.
Which leads me to believe we should remove this from logging.c and if our command line tools want to do this, they should add the call themselves. I'm not sure if there would be unintended consequences, however.
It looks like we can replace it with g_log_set_fatal_mask() once we define our own log domain.
Comment Actions
This disables glib aborting after an error message.
Right, hence the unintended consequences if suddenly messages can be fatal.
It looks like we can replace it with g_log_set_fatal_mask() once we define our own log domain.
This is probably a good way to do it. We can still avoid aborting from all pacemaker logging, but if the tool links against some other library, we're not messing with whatever settings that library provides.