[Bug 1970634] Re: FTBFS: test failure due to low memlock limit

[Andreas Hasenack]

I added a task for systemd to consider raising the default
RLIMIT_MEMLOCK limit.

This upstream commit raises the default limit to 8Mb:

https://github.com/systemd/systemd/commit/852b62507b2

The way things are now, the following scenario does NOT work out of the
box:

- jammy lxd on focal host
- apt install mariadb-server

mariadb will crash and core dump because of the low MEMLOCK limit. Its
systemd service file even has this line to raise the limit:

LimitMEMLOCK=524288

But that does not have any effect from inside the unprivileged lxd
container.

Jammy lxd on jammy host will work just because the jammy kernel (5.15.0)
is deemed unsafe[1] for uring by mariadb, and then uring is disabled
during startup.


1. https://github.com/MariaDB/server/blob/10.6/storage/innobase/handler/ha_innodb.cc#L19480

** Summary changed:

- FTBFS: test failure due to low memlock limit
+ FTBFS: mariadb fails to start due to low MEMLOCK limit

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970634

Title:
  FTBFS: mariadb fails to start due to low MEMLOCK limit

Status in mariadb-10.6 package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  New

Bug description:
  <rbasak> ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime.
  <rbasak> But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it.
  <rbasak> AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6).
  <ahasenack> I think the lp builders are using the focal hwe kernel
  <ahasenack> 5.4.0-something
  <ahasenack> let me check that build log
  <rbasak> But then something changed that caused this current FTBFS, and I haven't tracked down what that is.
  <ahasenack> hm, both are 10.6.7
  <ahasenack> release and proposed
  <rbasak> What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before?
  <rbasak> So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong.
  <ahasenack> this is the current failure
  <ahasenack> 2022-04-14  8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required)
  <ahasenack> and ulimit -l confirms that the limit is lower
  <ahasenack> Max locked memory         65536                65536                bytes     
  <ahasenack> just 64kbytes
  <rbasak> Yeah but then how did the release pocket build work?
  <ahasenack> either the limit was different back then
  <ahasenack> or ... stuff

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+subscriptions