8.28. cluster

Bug Fixes

BZ#843160

Previously, the fencing time comparison did not work as expected when fence agent completed too fast or the corosync callback was delayed. Consequently, the Distributed Lock Manager (DLM) became unresponsive when waiting for fencing to complete. With this update, different time stamps that are not effected by the sequence of fencing or corosync callbacks are now saved and compared, and DLM no longer hangs in the aforementioned situation.

BZ#1059269

Prior to this update, the "pcs stonith confirm <node>" command failed to acknowledge the STONITH fencing technique. As a consequence, any requests from other nodes in the cluster or from clients in the same node became ignored. A patch has been provided to fix this bug, and "pcs stonith confirm" now works as expected, fencing the specified node successfully.

BZ#1029210

Due to an error in the configuration, the qdisk daemon in some situations used an incorrect "tko" parameter for its wait period when initializing. Consequently, qdisk initialization could be significantly delayed and, under some circumstances, failed entirely. With this update, the cluster configuration file has been fixed, and qdisk initialization now proceeds as expected.

BZ#980575

Previously, the ccs_read_logging() function used the create_daemon_path() function to generate daemon-specific CCS paths for the attributes. As a consequence, attributes on individual logging_daemons were not applied correctly. This bug has been fixed, and attributes on individual logging_daemons are now applied correctly.

BZ#979313

Due to a code error in corosnync, after the corosync utility terminated unexpectedly with a segmentation fault, the qdiskd daemon evicted other cluster nodes. The underlying source code has been patched, and qdiskd no longer evicts the other nodes if corosync crashes.

BZ#1074551

Prior to this update, running the "ccs_tool -verbose" command caused ccs_tool to terminate unexpectedly with a segmentation fault. This bug has been fixed, and ccs_tool now returns an error message providing more information.

BZ#1059853

Due to an overly restrictive umask, running the "gfs2_grow" command changed the /etc/mtab file permissions from default 644 to 600. A patch has been provided to fix this bug, and gfs2_grow no longer resets /etc/mtab permissions.

BZ#1062742

Previously, fsck.gfs2 did not fix corrupt quota_change system files. As a consequence, attempts to mount the file system (FS) resulted in an error, even though fsck.gfs2 reported the FS to be clean. With this patch, if fsck.gfs2 finds a corrupted quota_change file, it can rebuild it. Now, GFS2 mounts successfully as intended.

BZ#1080174

Previous attempts to mount a GFS2 file system that had already been mounted prevented further mount attempts from other nodes from completing. With this update, mount.gfs2 no longer leaves the mount group when the file system is already mounted, and attempts to mount an already mounted GFS2 file system are handled properly.

BZ#1053668

Prior to this update, a GFS2 volume failed to mount after conversion from GFS to GFS2, and the gfs2_convert utility aborted with a segmentation fault. The gfs2-utils code has been patched to fix this bug, and the aforementioned conversions now proceed successfully.

Enhancement

BZ#1081517

To aid debugging and administration, fsck.gfs2 now logs a message to the system log when it starts and ends.