To clarify, the regression appears to be the same problem that the rlimit increase is fixing, but the applications failing now are simply bigger. In general, any application that calls mlockall() with MCL_FUTURE, but doesn't adjust its rlimit (or change its systemd service file to adjust LimitMEMLOCK) is very likely destined to crash later in its life.
I believe the only lp bugs for this regression are bug 1890394 and bug
1902879, which are both fix-committed and verified, so this bug should
be ok to release (again) after those are released. Also I will note both
of those applications (slick-greeter and lightdm-gtk-greeter) were fixed
by commenting out their calls to mlockall.
There is also bug 1902871 and bug 1903199 but I believe those are both
dups of bug 1900394.
Also finally to reflect on cryptsetup's use of mlockall(), since it's
the origin for this bug; cryptsetup is maybe "better" about its use of
mlockall() since it keeps the mlock only for the duration of an
'action':
if (action->required_memlock)
crypt_memory_lock(NULL, 1);
set_int_handler(0);
r = action->handler();
if (action->required_memlock)
crypt_memory_lock(NULL, 0);
however, as this bug shows, that action handler function can still
attempt to allocate enough memory to reach the rlimit and cause
allocation failures. Personally, I think cryptsetup should be fixed
upstream to call setrlimit() to increase its RLIMIT_MEMLOCK to infinity,
at least while the mlock is in effect.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1830746
Title:
memlock setting in systemd (pid 1) too low for containers (bionic)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
