[Bug 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit

[Andreas Hasenack]

** Description changed:

+ [Impact]
+ 
+  * An explanation of the effects of the bug on users and
+ 
+  * justification for backporting the fix to the stable release.
+ 
+  * In addition, it is helpful, but not required, to include an
+    explanation of how the upload fixes this bug.
+ 
+ [Test Plan]
+ 
+  * detailed instructions how to reproduce the bug
+ 
+  * these should allow someone who is not familiar with the affected
+    package to reproduce the bug and verify that the updated package fixes
+    the problem.
+ 
+  * if other testing is appropriate to perform before landing this update,
+    this should also be described here.
+ 
+ [Where problems could occur]
+ 
+  * Think about what the upload changes in the software. Imagine the change is
+    wrong or breaks something else: how would this show up?
+ 
+  * It is assumed that any SRU candidate patch is well-tested before
+    upload and has a low overall risk of regression, but it's important
+    to make the effort to think about what ''could'' happen in the
+    event of a regression.
+ 
+  * This must '''never''' be "None" or "Low", or entirely an argument as to why
+    your upload is low risk.
+ 
+  * This both shows the SRU team that the risks have been considered,
+    and provides guidance to testers in regression-testing the SRU.
+ 
+ [Other Info]
+  
+  * Anything else you think is useful to include
+  * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
+  * and address these questions in advance
+ 
+ 
+ [Original 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> 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

-- 
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:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in mariadb-10.6 source package in Jammy:
  Triaged
Status in systemd source package in Jammy:
  In Progress

Bug description:
  [Impact]

   * An explanation of the effects of the bug on users and

   * justification for backporting the fix to the stable release.

   * In addition, it is helpful, but not required, to include an
     explanation of how the upload fixes this bug.

  [Test Plan]

   * detailed instructions how to reproduce the bug

   * these should allow someone who is not familiar with the affected
     package to reproduce the bug and verify that the updated package fixes
     the problem.

   * if other testing is appropriate to perform before landing this update,
     this should also be described here.

  [Where problems could occur]

   * Think about what the upload changes in the software. Imagine the change is
     wrong or breaks something else: how would this show up?

   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.

   * This must '''never''' be "None" or "Low", or entirely an argument as to why
     your upload is low risk.

   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.

  [Other Info]
   
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
   * and address these questions in advance

  
  [Original 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