** Description changed: [impact] as with several other programs, corosync appears to think it's special and needs to have all its memory permanently locked so nothing is ever swapped. Before it does so, it attempts to increase its rlimit to infinity, which is good, as otherwise future memory allocation attempts will fail once the application's memory usage reaches its rlimit. Unfortunately, while it tries to increase its rlimit, it doesn't actually check if the setrlimit() succeeded. This results in the unfortunate situation of locking all future memory *without* an infinite rlimit, which is essentially guaranteed to cause corosync to fail allocating memory at some point in the future. [test case] this causes autopkgtest failures such as bug 1828228 due to crashing (on memory allocation failure). it can be reproduced in an unprivileged container but just starting and using corosync. [regression potential] any regression likely would involve failure to start corosync, or a memory allocation failure during operation. [scope] this is still broken upstream, so it needs to be fixed upstream as well as in all releases. [other info] this "worked" before due to systemd enforcing a very low rlimit. In this case, corosync's call to increase its rlimit still failed, but since the rlimit was so low, it was less than corosync's initial memory size, so the mlockall() call also failed, and corosync ignored that (just logged it) and continued just fine without any of its memory locked. then, systemd's rlimit was bumped by bug 1830746. This allowed corosync (and several other applications that think they are 'special' and should never swap: bug 1890394 and bug 1890394) to continue to fail in increasing its rlimit, but now its mlockall() call succeeds. This results in corosync failing a short time later as its memory usage reaches its rlimit and its memory allocations all fail. As should be entirely clear since corosync hasn't been able to lock its memory at all up until now but yet seemed to work fine, there is virtually no application out there that *actually* should lock all its memory (qemu it a notable exception when sriov is involved, where it *does* need to lock all memory). Upstream corosync should completely remove the call to increase its rlimit and mlockall(). It's not needed and only causes problems. However if upstream corosync insists that corosync is special and needs to lock all memory, it *at least* needs to check setrlimit() and avoid mlockall() if it's unable to increase its rlimit. + + this is also related to bug 1918735 and bug 1828228
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1911904 Title: corosync locks all its current and future memory To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1911904/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
