8.33. corosync

Bug Fixes

BZ#1067043

If the cpg clients on active cluster nodes terminated while corosync on one of the nodes was paused, corosync did not update its internal information about cpg clients on other nodes properly after resuming. Consequently, that node considered the terminated cgp clients to be still up and running. This update modifies the cpg code to ensure that corosync properly updates information about the cpg membership in this situation.

BZ#1011307

Previously, corosync terminated unexpectedly with a segmentation fault when started on a system with the /dev/shm device full. This happened because the corosync logging system, logsys, could not be properly initialized. This update improves handling of the logsys initialization, and corosync now displays an appropriate error message and exits gracefully if logsys cannot be initialized.

BZ#1025321

Due to a list corruption bug in the Corosync Closed Process Group (CPG) API, corosync could terminate unexpectedly with a segmentation fault under some circumstances. To fix this problem, corosync has been modified to handle the CPG init and list removal functions in the same thread.

BZ#1005179

Previously, corosync could abort without logging an error properly if it was unable to store a file to the user's file system. With this update, corosync now properly verifies whether a "blackbox" can be stored on the file system. A failure of a ring ID store operation is no longer handled by assert but corosync now tries to log an error and then exits gracefully.

BZ#1001210

Previously, when using the InfiniBand Architecture (IBA) as a transport protocol for corosync, corosync could not properly handle the restart of the IBA subnet manager (SM). If the IBA SM was restarted, corosync was not able to start or became unresponsive if it was already running. A series of patches addressing this problem has been applied to corosync, and it now works properly as expected in this scenario.