- Previously, the corosync-notifyd daemon, with dbus output enabled, waited 0.5 seconds each time a message was sent through dbus. Consequently, corosync-notifyd was extremely slow in producing output and memory of the Corosync server grew. In addition, when corosync-notifyd was killed, its memory was not freed. With this update, corosync-notifyd no longer slows down its operation with these half-second delays and Corosync now properly frees memory when an IPC client exits.
- The mainconfig module passed an incorrect string pointer to the function that opens the corosync log file. If the path to the file (in cluster.conf) contained a non-existing directory, an incorrect error message was returned stating that there was a configuration file error. The correct error message is now returned informing the user that the log file cannot be created.
- The coroipcc library did not delete temporary buffers used for Inter-Process Communication (IPC) connections that are stored in the /dev/shm shared-memory file system. The /dev/shm memory resources became fully used and caused a Denial of Service event. The library has been modified so that applications delete temporary buffers if the buffers were not deleted by the corosync server. The /dev/shm system is now no longer cluttered with needless data.
- The range condition for the update_aru() function could cause incorrect checking of message IDs. The corosync utility entered the "FAILED TO RECEIVE" state and failed to receive multicast packets. The range value in the update_aru() function is no longer checked and the check is now performed using the fail_to_recv_const constant.
- If the corosync-notifyd daemon was running for a long time, the corosync process consumed an excessive amount of memory. This happened because the corosync-notifyd daemon failed to indicate that the no-longer used corosync objects were removed, resulting in memory leaks. The corosync-notifyd daemon has been fixed and the corosync memory usage no longer increases if corosync-notifyd is running for long periods of time.
- When a large cluster was booted or multiple corosync instances started at the same time, the CPG (Closed Process Group) events were not sent to the user. Therefore, nodes were incorrectly detected as no longer available, or as leaving and re-joining the cluster. The CPG service now checks the exit code in such scenarios properly and the CPG events are sent to users as expected.
- The OpenAIS EVT (Eventing) service sometimes caused deadlocks in corosync between the timer and serialize locks. The order of locking has been modified and the bug has been fixed.
- When corosync became overloaded, IPC messages could be lost without any notification. This happened because some services did not handle the error code returned by the totem_mcast() function. Applications that use IPC now handle the inability to send IPC messages properly and try sending the messages again.
- If both the corosync and cman RPM packages were installed on one system, the RPM verification process failed. This happened because both packages own the same directory but apply different rights to it. Now, the RPM packages have the same rights and the RPM verification no longer fails.
- corosync consumed excessive memory because the getaddrinfo() function leaked memory. The memory is now freed using the freeadrrinfo() function and getaddrinfo() no longer leaks memory.
- It was not possible to activate or deactivate debug logs at runtime due to memory corruption in the objdb structure. The debug logging can now be activated or deactivated on runtime, for example by the "corosync-objctl -w logging.debug=off" command.
- Each IPC connection uses 48 K in the stack. Previously, multi-threading applications with reduced stack size did not work correctly, which resulted in excessive memory usage. Temporary memory resources in a heap are now allocated to the IPC connections so that multi-threading applications no longer need to justify IPC connections' stack size.
- When running applications which used the Corosync IPC library, some messages in the dispatch() function were lost or duplicated. This update properly checks the return values of the dispatch_put() function, returns the correct remaining bytes in the IPC ring buffer, and ensures that the IPC client is correctly informed about the real number of messages in the ring buffer. Now, messages in the dispatch() function are no longer lost or duplicated.