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

[Otto Kekäläinen]

Filed follow-up
https://bugs.launchpad.net/ubuntu/+source/mariadb/+bug/2038500 to track
when the underlying issue is fixed and the workaround can be removed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  Fix Released
Status in mariadb-10.6 source package in Jammy:
  Fix Released
Status in systemd source package in Jammy:
  Won't Fix

Bug description:
  [Impact]

  Jammy's MariaDB will fail to build, and also fail to start, if the
  underlying kernel is 5.4.x (focal's) and if it's running in an
  unprivileged container (lxd, docker). It will also fail to build in
  launchpad builders.

  Common scenarios where this combination exists is a focal host,
  running an unprivileged jammy container (lxd or docker), or even a
  chroot (the launchpad builders).

  Jammy's MariaDB was built with io_uring support, and it tries to
  enable it at runtime if it deems it's running on a supported kernel.
  There is a range of kernel versions it checks, but of interest for
  this SRU, the Focal (5.4.x) kernel is inside this range and io_uring
  will be enabled. The jammy kernel (5.15) is not, so io_uring will not
  be enabled there, and thus the bug is not manifested in that case.

  If io_uring is enabled, a higher MEMLOCK limit is required than what
  is set by default in focal or jammy (64Mb is what we get, 256Mb or
  more is required).

  The systemd unit file for mariadb tries to raise this limit, but in an
  unprivileged container this won't work.

  MariaDB has checks in place to catch when MEMLOCK is too low, in which
  case it will not use io_uring, but these checks are failing because of
  the LTO build flags that were used in the jammy build of mariadb. It's
  unclear if it's a bug in gcc or something else. There is more
  information in comment #1, comment #5 and later.

  The suggested fix here is to disable LTO for the jammy build. This has
  been done for kinetic already, and is also applied to the debian
  packaging (inside a distro-specific conditional).

  [Test Plan]
  The test plan is to launch mariadb in a jammy lxd container running on a 
focal host.

  lxc launch ubuntu:focal f --vm
  lxc shell f
  lxd init # just hit enter for all questions
  lxc launch ubuntu:jammy j
  lxc shell j
  ulimit -l # confirm it's less than 256
  apt update && apt install mariadb-server -y

  After the installation, mariadb will not be running, and this can be
  checked with:

  systemctl status mariadb.service

  or

  journalctl -u mariadb.server

  You will see something like this:
  Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database 
server...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
/usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be 
created!
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Compressed tables use zlib 1.2.11
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using transactional memory
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Number of pools: 1
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using crc32 + pclmulqdq instructions
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 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)
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld 
got signal 6 ;

  And a crash dump.

  With the fixed version, the service will be running normally after
  installation.

  [Where problems could occur]
  The proposed fix is not a surgical strike. It's unfortunate that we didn't 
get to the bottom of why LTO is causing this behavior. Reverting it is still 
the quickest and less risky change at the moment, though. This gets us on par 
with upstream binary builds, and debian builds, and these also have wide test 
coverage and ample user base.

  The other regression possibility is that this is a rebuild of mariadb
  in the current jammy environment, and the package that is currently in
  jammy was built on March 10th, 2022. Most likely the reverse
  dependencies were updated in jammy since then.

  It's unclear how 10.6.7-2ubuntu1 migrated in jammy. I checked build
  logs and dep8 logs, and can't tell why the tests passed. At least the
  build log in jammy shows the host kernel was 5.4.x, 

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

[Nick Rosbrook]

The commit mentioned in
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1970634/comments/3
has been present in systemd since v251 (which is in Kinetic), so I don't
think there is anything left to do for systemd. Please correct me if I
am wrong.

** Changed in: systemd (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  Fix Released
Status in mariadb-10.6 source package in Jammy:
  Fix Released
Status in systemd source package in Jammy:
  Won't Fix

Bug description:
  [Impact]

  Jammy's MariaDB will fail to build, and also fail to start, if the
  underlying kernel is 5.4.x (focal's) and if it's running in an
  unprivileged container (lxd, docker). It will also fail to build in
  launchpad builders.

  Common scenarios where this combination exists is a focal host,
  running an unprivileged jammy container (lxd or docker), or even a
  chroot (the launchpad builders).

  Jammy's MariaDB was built with io_uring support, and it tries to
  enable it at runtime if it deems it's running on a supported kernel.
  There is a range of kernel versions it checks, but of interest for
  this SRU, the Focal (5.4.x) kernel is inside this range and io_uring
  will be enabled. The jammy kernel (5.15) is not, so io_uring will not
  be enabled there, and thus the bug is not manifested in that case.

  If io_uring is enabled, a higher MEMLOCK limit is required than what
  is set by default in focal or jammy (64Mb is what we get, 256Mb or
  more is required).

  The systemd unit file for mariadb tries to raise this limit, but in an
  unprivileged container this won't work.

  MariaDB has checks in place to catch when MEMLOCK is too low, in which
  case it will not use io_uring, but these checks are failing because of
  the LTO build flags that were used in the jammy build of mariadb. It's
  unclear if it's a bug in gcc or something else. There is more
  information in comment #1, comment #5 and later.

  The suggested fix here is to disable LTO for the jammy build. This has
  been done for kinetic already, and is also applied to the debian
  packaging (inside a distro-specific conditional).

  [Test Plan]
  The test plan is to launch mariadb in a jammy lxd container running on a 
focal host.

  lxc launch ubuntu:focal f --vm
  lxc shell f
  lxd init # just hit enter for all questions
  lxc launch ubuntu:jammy j
  lxc shell j
  ulimit -l # confirm it's less than 256
  apt update && apt install mariadb-server -y

  After the installation, mariadb will not be running, and this can be
  checked with:

  systemctl status mariadb.service

  or

  journalctl -u mariadb.server

  You will see something like this:
  Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database 
server...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
/usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be 
created!
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Compressed tables use zlib 1.2.11
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using transactional memory
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Number of pools: 1
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using crc32 + pclmulqdq instructions
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 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)
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld 
got signal 6 ;

  And a crash dump.

  With the fixed version, the service will be running normally after
  installation.

  [Where problems could occur]
  The proposed fix is not a surgical strike. It's unfortunate that we didn't 
get to the bottom of why LTO is causing this behavior. Reverting it is still 
the quickest and less risky change at the moment, though. This gets us on par 
with upstream binary builds, and debian builds, and these also have wide test 
coverage and ample user base.

  The other regression possibility is that this is a rebuild of mariadb
  in the current jammy environment, and the package that is currently in
  jammy was built on March 10th, 2022. Most likely the reverse
  dependencies were updated in jammy since then.

  It's unclear how 

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

[Andreas Hasenack]

Removing the systemd jammy task, it's unlikely such a change would be
SRUed.

** Changed in: systemd (Ubuntu Jammy)
   Status: Confirmed => Won't Fix

** Tags removed: server-todo

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  Fix Released
Status in systemd source package in Jammy:
  Won't Fix

Bug description:
  [Impact]

  Jammy's MariaDB will fail to build, and also fail to start, if the
  underlying kernel is 5.4.x (focal's) and if it's running in an
  unprivileged container (lxd, docker). It will also fail to build in
  launchpad builders.

  Common scenarios where this combination exists is a focal host,
  running an unprivileged jammy container (lxd or docker), or even a
  chroot (the launchpad builders).

  Jammy's MariaDB was built with io_uring support, and it tries to
  enable it at runtime if it deems it's running on a supported kernel.
  There is a range of kernel versions it checks, but of interest for
  this SRU, the Focal (5.4.x) kernel is inside this range and io_uring
  will be enabled. The jammy kernel (5.15) is not, so io_uring will not
  be enabled there, and thus the bug is not manifested in that case.

  If io_uring is enabled, a higher MEMLOCK limit is required than what
  is set by default in focal or jammy (64Mb is what we get, 256Mb or
  more is required).

  The systemd unit file for mariadb tries to raise this limit, but in an
  unprivileged container this won't work.

  MariaDB has checks in place to catch when MEMLOCK is too low, in which
  case it will not use io_uring, but these checks are failing because of
  the LTO build flags that were used in the jammy build of mariadb. It's
  unclear if it's a bug in gcc or something else. There is more
  information in comment #1, comment #5 and later.

  The suggested fix here is to disable LTO for the jammy build. This has
  been done for kinetic already, and is also applied to the debian
  packaging (inside a distro-specific conditional).

  [Test Plan]
  The test plan is to launch mariadb in a jammy lxd container running on a 
focal host.

  lxc launch ubuntu:focal f --vm
  lxc shell f
  lxd init # just hit enter for all questions
  lxc launch ubuntu:jammy j
  lxc shell j
  ulimit -l # confirm it's less than 256
  apt update && apt install mariadb-server -y

  After the installation, mariadb will not be running, and this can be
  checked with:

  systemctl status mariadb.service

  or

  journalctl -u mariadb.server

  You will see something like this:
  Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database 
server...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
/usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be 
created!
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Compressed tables use zlib 1.2.11
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using transactional memory
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Number of pools: 1
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using crc32 + pclmulqdq instructions
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 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)
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld 
got signal 6 ;

  And a crash dump.

  With the fixed version, the service will be running normally after
  installation.

  [Where problems could occur]
  The proposed fix is not a surgical strike. It's unfortunate that we didn't 
get to the bottom of why LTO is causing this behavior. Reverting it is still 
the quickest and less risky change at the moment, though. This gets us on par 
with upstream binary builds, and debian builds, and these also have wide test 
coverage and ample user base.

  The other regression possibility is that this is a rebuild of mariadb
  in the current jammy environment, and the package that is currently in
  jammy was built on March 10th, 2022. Most likely the reverse
  dependencies were updated in jammy since then.

  It's unclear how 10.6.7-2ubuntu1 migrated in jammy. I checked build
  logs and dep8 logs, and can't tell why the tests passed. At least the
  build log in jammy shows the 

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

[Launchpad Bug Tracker]

This bug was fixed in the package mariadb-10.6 - 1:10.6.7-2ubuntu1.1

---
mariadb-10.6 (1:10.6.7-2ubuntu1.1) jammy; urgency=medium

  * d/rules: disable LTO on Ubuntu so a low MEMLOCK_LIMIT can be
properly caught and dealt with (LP: #1970634)

 -- Andreas Hasenack   Fri, 17 Jun 2022 10:03:50
-0300

** Changed in: mariadb-10.6 (Ubuntu Jammy)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  Fix Released
Status in systemd source package in Jammy:
  Confirmed

Bug description:
  [Impact]

  Jammy's MariaDB will fail to build, and also fail to start, if the
  underlying kernel is 5.4.x (focal's) and if it's running in an
  unprivileged container (lxd, docker). It will also fail to build in
  launchpad builders.

  Common scenarios where this combination exists is a focal host,
  running an unprivileged jammy container (lxd or docker), or even a
  chroot (the launchpad builders).

  Jammy's MariaDB was built with io_uring support, and it tries to
  enable it at runtime if it deems it's running on a supported kernel.
  There is a range of kernel versions it checks, but of interest for
  this SRU, the Focal (5.4.x) kernel is inside this range and io_uring
  will be enabled. The jammy kernel (5.15) is not, so io_uring will not
  be enabled there, and thus the bug is not manifested in that case.

  If io_uring is enabled, a higher MEMLOCK limit is required than what
  is set by default in focal or jammy (64Mb is what we get, 256Mb or
  more is required).

  The systemd unit file for mariadb tries to raise this limit, but in an
  unprivileged container this won't work.

  MariaDB has checks in place to catch when MEMLOCK is too low, in which
  case it will not use io_uring, but these checks are failing because of
  the LTO build flags that were used in the jammy build of mariadb. It's
  unclear if it's a bug in gcc or something else. There is more
  information in comment #1, comment #5 and later.

  The suggested fix here is to disable LTO for the jammy build. This has
  been done for kinetic already, and is also applied to the debian
  packaging (inside a distro-specific conditional).

  [Test Plan]
  The test plan is to launch mariadb in a jammy lxd container running on a 
focal host.

  lxc launch ubuntu:focal f --vm
  lxc shell f
  lxd init # just hit enter for all questions
  lxc launch ubuntu:jammy j
  lxc shell j
  ulimit -l # confirm it's less than 256
  apt update && apt install mariadb-server -y

  After the installation, mariadb will not be running, and this can be
  checked with:

  systemctl status mariadb.service

  or

  journalctl -u mariadb.server

  You will see something like this:
  Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database 
server...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
/usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be 
created!
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Compressed tables use zlib 1.2.11
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using transactional memory
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Number of pools: 1
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using crc32 + pclmulqdq instructions
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 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)
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld 
got signal 6 ;

  And a crash dump.

  With the fixed version, the service will be running normally after
  installation.

  [Where problems could occur]
  The proposed fix is not a surgical strike. It's unfortunate that we didn't 
get to the bottom of why LTO is causing this behavior. Reverting it is still 
the quickest and less risky change at the moment, though. This gets us on par 
with upstream binary builds, and debian builds, and these also have wide test 
coverage and ample user base.

  The other regression possibility is that this is a rebuild of mariadb
  in the current jammy environment, and the package that is currently in
  jammy was built on March 10th, 2022. Most likely the reverse
  

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

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu Jammy)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  Fix Committed
Status in systemd source package in Jammy:
  Confirmed

Bug description:
  [Impact]

  Jammy's MariaDB will fail to build, and also fail to start, if the
  underlying kernel is 5.4.x (focal's) and if it's running in an
  unprivileged container (lxd, docker). It will also fail to build in
  launchpad builders.

  Common scenarios where this combination exists is a focal host,
  running an unprivileged jammy container (lxd or docker), or even a
  chroot (the launchpad builders).

  Jammy's MariaDB was built with io_uring support, and it tries to
  enable it at runtime if it deems it's running on a supported kernel.
  There is a range of kernel versions it checks, but of interest for
  this SRU, the Focal (5.4.x) kernel is inside this range and io_uring
  will be enabled. The jammy kernel (5.15) is not, so io_uring will not
  be enabled there, and thus the bug is not manifested in that case.

  If io_uring is enabled, a higher MEMLOCK limit is required than what
  is set by default in focal or jammy (64Mb is what we get, 256Mb or
  more is required).

  The systemd unit file for mariadb tries to raise this limit, but in an
  unprivileged container this won't work.

  MariaDB has checks in place to catch when MEMLOCK is too low, in which
  case it will not use io_uring, but these checks are failing because of
  the LTO build flags that were used in the jammy build of mariadb. It's
  unclear if it's a bug in gcc or something else. There is more
  information in comment #1, comment #5 and later.

  The suggested fix here is to disable LTO for the jammy build. This has
  been done for kinetic already, and is also applied to the debian
  packaging (inside a distro-specific conditional).

  [Test Plan]
  The test plan is to launch mariadb in a jammy lxd container running on a 
focal host.

  lxc launch ubuntu:focal f --vm
  lxc shell f
  lxd init # just hit enter for all questions
  lxc launch ubuntu:jammy j
  lxc shell j
  ulimit -l # confirm it's less than 256
  apt update && apt install mariadb-server -y

  After the installation, mariadb will not be running, and this can be
  checked with:

  systemctl status mariadb.service

  or

  journalctl -u mariadb.server

  You will see something like this:
  Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database 
server...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
/usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be 
created!
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Compressed tables use zlib 1.2.11
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using transactional memory
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Number of pools: 1
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using crc32 + pclmulqdq instructions
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 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)
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld 
got signal 6 ;

  And a crash dump.

  With the fixed version, the service will be running normally after
  installation.

  [Where problems could occur]
  The proposed fix is not a surgical strike. It's unfortunate that we didn't 
get to the bottom of why LTO is causing this behavior. Reverting it is still 
the quickest and less risky change at the moment, though. This gets us on par 
with upstream binary builds, and debian builds, and these also have wide test 
coverage and ample user base.

  The other regression possibility is that this is a rebuild of mariadb
  in the current jammy environment, and the package that is currently in
  jammy was built on March 10th, 2022. Most likely the reverse
  dependencies were updated in jammy since then.

  It's unclear how 10.6.7-2ubuntu1 migrated in jammy. I checked build
  logs and dep8 logs, and can't tell why the tests passed. At least the
  build log in jammy shows the host kernel was 5.4.x, so it should have
  

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

[Daniel Black]

Will also fix #1979695

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  Fix Committed
Status in systemd source package in Jammy:
  New

Bug description:
  [Impact]

  Jammy's MariaDB will fail to build, and also fail to start, if the
  underlying kernel is 5.4.x (focal's) and if it's running in an
  unprivileged container (lxd, docker). It will also fail to build in
  launchpad builders.

  Common scenarios where this combination exists is a focal host,
  running an unprivileged jammy container (lxd or docker), or even a
  chroot (the launchpad builders).

  Jammy's MariaDB was built with io_uring support, and it tries to
  enable it at runtime if it deems it's running on a supported kernel.
  There is a range of kernel versions it checks, but of interest for
  this SRU, the Focal (5.4.x) kernel is inside this range and io_uring
  will be enabled. The jammy kernel (5.15) is not, so io_uring will not
  be enabled there, and thus the bug is not manifested in that case.

  If io_uring is enabled, a higher MEMLOCK limit is required than what
  is set by default in focal or jammy (64Mb is what we get, 256Mb or
  more is required).

  The systemd unit file for mariadb tries to raise this limit, but in an
  unprivileged container this won't work.

  MariaDB has checks in place to catch when MEMLOCK is too low, in which
  case it will not use io_uring, but these checks are failing because of
  the LTO build flags that were used in the jammy build of mariadb. It's
  unclear if it's a bug in gcc or something else. There is more
  information in comment #1, comment #5 and later.

  The suggested fix here is to disable LTO for the jammy build. This has
  been done for kinetic already, and is also applied to the debian
  packaging (inside a distro-specific conditional).

  [Test Plan]
  The test plan is to launch mariadb in a jammy lxd container running on a 
focal host.

  lxc launch ubuntu:focal f --vm
  lxc shell f
  lxd init # just hit enter for all questions
  lxc launch ubuntu:jammy j
  lxc shell j
  ulimit -l # confirm it's less than 256
  apt update && apt install mariadb-server -y

  After the installation, mariadb will not be running, and this can be
  checked with:

  systemctl status mariadb.service

  or

  journalctl -u mariadb.server

  You will see something like this:
  Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database 
server...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
/usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be 
created!
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Compressed tables use zlib 1.2.11
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using transactional memory
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Number of pools: 1
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using crc32 + pclmulqdq instructions
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 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)
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld 
got signal 6 ;

  And a crash dump.

  With the fixed version, the service will be running normally after
  installation.

  [Where problems could occur]
  The proposed fix is not a surgical strike. It's unfortunate that we didn't 
get to the bottom of why LTO is causing this behavior. Reverting it is still 
the quickest and less risky change at the moment, though. This gets us on par 
with upstream binary builds, and debian builds, and these also have wide test 
coverage and ample user base.

  The other regression possibility is that this is a rebuild of mariadb
  in the current jammy environment, and the package that is currently in
  jammy was built on March 10th, 2022. Most likely the reverse
  dependencies were updated in jammy since then.

  It's unclear how 10.6.7-2ubuntu1 migrated in jammy. I checked build
  logs and dep8 logs, and can't tell why the tests passed. At least the
  build log in jammy shows the host kernel was 5.4.x, so it should have
  been affected. My only explanation is that at that time, the MEMLOCK
  limit was higher in that environment for some 

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

[Andreas Hasenack]

** Changed in: systemd (Ubuntu Jammy)
   Status: In Progress => New

** Changed in: systemd (Ubuntu Jammy)
 Assignee: Andreas Hasenack (ahasenack) => (unassigned)

** Changed in: mariadb-10.6 (Ubuntu Jammy)
   Status: Triaged => In Progress

** Description changed:

  [Impact]
  
  Jammy's MariaDB will fail to build, and also fail to start, if the
  underlying kernel is 5.4.x (focal's) and if it's running in an
  unprivileged container (lxd, docker). It will also fail to build in
  launchpad builders.
  
  Common scenarios where this combination exists is a focal host, running
  an unprivileged jammy container (lxd or docker), or even a chroot (the
  launchpad builders).
  
  Jammy's MariaDB was built with io_uring support, and it tries to enable
  it at runtime if it deems it's running on a supported kernel. There is a
  range of kernel versions it checks, but of interest for this SRU, the
  Focal (5.4.x) kernel is inside this range and io_uring will be enabled.
  The jammy kernel (5.15) is not, so io_uring will not be enabled there,
  and thus the bug is not manifested in that case.
  
  If io_uring is enabled, a higher MEMLOCK limit is required than what is
  set by default in focal or jammy (64Mb is what we get, 256Mb or more is
  required).
  
  The systemd unit file for mariadb tries to raise this limit, but in an
  unprivileged container this won't work.
  
  MariaDB has checks in place to catch when MEMLOCK is too low, in which
  case it will not use io_uring, but these checks are failing because of
  the LTO build flags that were used in the jammy build of mariadb. It's
  unclear if it's a bug in gcc or something else. There is more
  information in comment #1, comment #5 and later.
  
  The suggested fix here is to disable LTO for the jammy build. This has
  been done for kinetic already, and is also applied to the debian
  packaging (inside a distro-specific conditional).
  
  [Test Plan]
  The test plan is to launch mariadb in a jammy lxd container running on a 
focal host.
  
  lxc launch ubuntu:focal f --vm
  lxc shell
  lxd init # just hit enter for all questions
  lxc launch ubuntu:jammy j
  lxc shell j
  ulimit -l # confirm it's less than 256
  apt update && apt install mariadb-server -y
  
  After the installation, mariadb will not be running, and this can be
  checked with:
  
- systemctl status mariadb-server
+ systemctl status mariadb.service
  
  or
  
  journalctl -u mariadb.server
  
  You will see something like this:
  Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database 
server...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
/usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be 
created!
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Compressed tables use zlib 1.2.11
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using transactional memory
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Number of pools: 1
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using crc32 + pclmulqdq instructions
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 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)
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld 
got signal 6 ;
  
  And a crash dump.
  
  With the fixed version, the service will be running normally after
  installation.
  
  [Where problems could occur]
  The proposed fix is not a surgical strike. It's unfortunate that we didn't 
get to the bottom of why LTO is causing this behavior. Reverting it is still 
the quickest and less risky change at the moment, though. This gets us on par 
with upstream binary builds, and debian builds, and these also have wide test 
coverage and ample user base.
  
  The other regression possibility is that this is a rebuild of mariadb in
  the current jammy environment, and the package that is currently in
  jammy was built on March 10th, 2022. Most likely the reverse
  dependencies were updated in jammy since then.
  
  It's unclear how 10.6.7-2ubuntu1 migrated in jammy. I checked build logs
  and dep8 logs, and can't tell why the tests passed. At least the build
  log in jammy shows the host kernel was 5.4.x, so it should have been
  affected. My only explanation is that at that time, the MEMLOCK limit
  was higher in that environment for some reason, and didn't trigger this
  bug. Then at some point later, launchpad builders changed, and MEMLOCK
  was reduced to 64Mb. 

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

[Launchpad Bug Tracker]

** Merge proposal linked:
   
https://code.launchpad.net/~ahasenack/ubuntu/+source/mariadb-10.6/+git/mariadb-10.6/+merge/424986

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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]

  Jammy's MariaDB will fail to build, and also fail to start, if the
  underlying kernel is 5.4.x (focal's) and if it's running in an
  unprivileged container (lxd, docker). It will also fail to build in
  launchpad builders.

  Common scenarios where this combination exists is a focal host,
  running an unprivileged jammy container (lxd or docker), or even a
  chroot (the launchpad builders).

  Jammy's MariaDB was built with io_uring support, and it tries to
  enable it at runtime if it deems it's running on a supported kernel.
  There is a range of kernel versions it checks, but of interest for
  this SRU, the Focal (5.4.x) kernel is inside this range and io_uring
  will be enabled. The jammy kernel (5.15) is not, so io_uring will not
  be enabled there, and thus the bug is not manifested in that case.

  If io_uring is enabled, a higher MEMLOCK limit is required than what
  is set by default in focal or jammy (64Mb is what we get, 256Mb or
  more is required).

  The systemd unit file for mariadb tries to raise this limit, but in an
  unprivileged container this won't work.

  MariaDB has checks in place to catch when MEMLOCK is too low, in which
  case it will not use io_uring, but these checks are failing because of
  the LTO build flags that were used in the jammy build of mariadb. It's
  unclear if it's a bug in gcc or something else. There is more
  information in comment #1, comment #5 and later.

  The suggested fix here is to disable LTO for the jammy build. This has
  been done for kinetic already, and is also applied to the debian
  packaging (inside a distro-specific conditional).

  [Test Plan]
  The test plan is to launch mariadb in a jammy lxd container running on a 
focal host.

  lxc launch ubuntu:focal f --vm
  lxc shell
  lxd init # just hit enter for all questions
  lxc launch ubuntu:jammy j
  lxc shell j
  ulimit -l # confirm it's less than 256
  apt update && apt install mariadb-server -y

  After the installation, mariadb will not be running, and this can be
  checked with:

  systemctl status mariadb-server

  or

  journalctl -u mariadb.server

  You will see something like this:
  Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database 
server...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
/usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be 
created!
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Compressed tables use zlib 1.2.11
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using transactional memory
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Number of pools: 1
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using crc32 + pclmulqdq instructions
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 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)
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld 
got signal 6 ;

  And a crash dump.

  With the fixed version, the service will be running normally after
  installation.

  [Where problems could occur]
  The proposed fix is not a surgical strike. It's unfortunate that we didn't 
get to the bottom of why LTO is causing this behavior. Reverting it is still 
the quickest and less risky change at the moment, though. This gets us on par 
with upstream binary builds, and debian builds, and these also have wide test 
coverage and ample user base.

  The other regression possibility is that this is a rebuild of mariadb
  in the current jammy environment, and the package that is currently in
  jammy was built on March 10th, 2022. Most likely the reverse
  dependencies were updated in jammy since then.

  It's unclear how 10.6.7-2ubuntu1 migrated in jammy. I checked build
  logs and dep8 logs, and can't tell why the tests passed. At least the
  build log in jammy shows the host kernel was 5.4.x, so it should have
  been affected. My 

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

[Andreas Hasenack]

** Description changed:

  [Impact]
  
  Jammy's MariaDB will fail to build, and also fail to start, if the
  underlying kernel is 5.4.x (focal's) and if it's running in an
  unprivileged container (lxd, docker). It will also fail to build in
  launchpad builders.
  
  Common scenarios where this combination exists is a focal host, running
  an unprivileged jammy container (lxd or docker), or even a chroot (the
  launchpad builders).
  
  Jammy's MariaDB was built with io_uring support, and it tries to enable
  it at runtime if it deems it's running on a supported kernel. There is a
  range of kernel versions it checks, but of interest for this SRU, the
  Focal (5.4.x) kernel is inside this range and io_uring will be enabled.
  The jammy kernel (5.15) is not, so io_uring will not be enabled there,
  and thus the bug is not manifested in that case.
  
  If io_uring is enabled, a higher MEMLOCK limit is required than what is
  set by default in focal or jammy (64Mb is what we get, 256Mb or more is
  required).
  
  The systemd unit file for mariadb tries to raise this limit, but in an
  unprivileged container this won't work.
  
  MariaDB has checks in place to catch when MEMLOCK is too low, in which
  case it will not use io_uring, but these checks are failing because of
  the LTO build flags that were used in the jammy build of mariadb. It's
  unclear if it's a bug in gcc or something else. There is more
  information in comment #1, comment #5 and later.
  
  The suggested fix here is to disable LTO for the jammy build. This has
  been done for kinetic already, and is also applied to the debian
  packaging (inside a distro-specific conditional).
  
  [Test Plan]
  The test plan is to launch mariadb in a jammy lxd container running on a 
focal host.
  
  lxc launch ubuntu:focal f --vm
  lxc shell
  lxd init # just hit enter for all questions
  lxc launch ubuntu:jammy j
  lxc shell j
  ulimit -l # confirm it's less than 256
  apt update && apt install mariadb-server -y
  
  After the installation, mariadb will not be running, and this can be
  checked with:
  
  systemctl status mariadb-server
  
  or
  
  journalctl -u mariadb.server
  
  You will see something like this:
  Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database 
server...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
/usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ...
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be 
created!
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Compressed tables use zlib 1.2.11
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using transactional memory
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Number of pools: 1
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] 
InnoDB: Using crc32 + pclmulqdq instructions
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 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)
  Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld 
got signal 6 ;
  
  And a crash dump.
  
  With the fixed version, the service will be running normally after
  installation.
  
  [Where problems could occur]
+ The proposed fix is not a surgical strike. It's unfortunate that we didn't 
get to the bottom of why LTO is causing this behavior. Reverting it is still 
the quickest and less risky change at the moment, though. This gets us on par 
with upstream binary builds, and debian builds, and these also have wide test 
coverage and ample user base.
  
-  * Think about what the upload changes in the software. Imagine the change is
-    wrong or breaks something else: how would this show up?
+ The other regression possibility is that this is a rebuild of mariadb in
+ the current jammy environment, and the package that is currently in
+ jammy was built on March 10th, 2022. Most likely the reverse
+ dependencies were updated in jammy since then.
  
-  * 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.
+ It's unclear how 10.6.7-2ubuntu1 migrated in jammy. I checked build logs
+ and dep8 logs, and can't tell why the tests passed. At least the build
+ log in jammy shows the host kernel was 5.4.x, so it should have been
+ affected. My only explanation is that at that time, the MEMLOCK limit
+ was higher in that environment for some reason, and didn't trigger this
+ bug. Then at some point later, 

[Touch-packages] [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
+ Jammy's MariaDB was built with io_uring support, and it tries to enable
+ it at runtime if it deems it's running on a supported kernel. There is a
+ range of kernel versions it checks, but of interest for this SRU, the
+ Focal (5.4.x) kernel is inside this range and io_uring will be enabled.
+ The jammy kernel (5.15) is not, so io_uring will not be enabled there.
  
-  * justification for backporting the fix to the stable release.
+ Common scenarios where this combination exists is a focal host, running
+ a jammy container (lxd or docker), or even a chroot (the launchpad
+ builders).
  
-  * In addition, it is helpful, but not required, to include an
-explanation of how the upload fixes this bug.
+ If io_uring is enabled, a higher MEMLOCK limit is required than what is
+ set by default in focal or jammy (64Mb is what we get, 256Mb or more is
+ required).
+ 
+ The systemd unit file for mariadb tries to raise this limit, but in an
+ unprivileged container, or a root-less chroot, this won't work.
+ 
+ MariaDB has checks in place to catch when MEMLOCK is too low, in which
+ case it will not use io_uring, but these checks are failing because of
+ the LTO build flags that were used in the jammy build of mariadb. It's
+ unclear if it's a bug in gcc. There is more information in comment #1,
+ comment #5 and later.
+ 
+ The suggested fix here is to disable LTO for the jammy build. This has
+ been done for kinetic already, and is also applied to the debian
+ packaging (inside a distro-specific conditional).
+ 
  
  [Test Plan]
  
-  * detailed instructions how to reproduce the bug
+  * 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.
+  * 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.
+  * 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?
+  * 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.
+  * 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 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.
+  * 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
  
+  * 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]
  
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since 

[Touch-packages] [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]
+ 
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
-  Max locked memory 6553665536  
  bytes 
+  Max locked memory 6553665536  
  bytes
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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 

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

[Andreas Hasenack]

Ok, phew, my test was incorrect, the bug is present in jammy. That makes
this SRU simpler. I'll proceed with it, without a block-proposed tag.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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]

   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Andreas Hasenack]

I got a report on IRC that the existing jammy package of mariadb does
exhibit this problem:

(link will expire soon)
https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_bd5/839585/23/check/kolla-ansible-ubuntu-source/bd5a051/primary/logs/kolla/mariadb/mariadb.txt:

"""
2022-06-15 12:38:03 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)
220615 12:38:03 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

Server version: 10.6.7-MariaDB-2ubuntu1-log
key_buffer_size=67108864
read_buffer_size=131072
max_used_connections=0
max_threads=10002
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 22090304 
K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
(...)
"""

The scenario is very similar to the lxd testing I've been using to
confirm the bug. Above it's a docker container running mariadb from
jammy, on a focal host.

The docker image was built with just pulling in mariadb from jammy,
without rebuilding it, so it's the same binary as published.

I probably made a mistake in my testing with the jammy package just now.
I'll repeat it and inspect it more carefully.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Andreas Hasenack]

Ok, a plain jammy rebuild in a launchpad ppa failed:

2022-06-17 14:18:27 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)

The binary package that is currently in jammy was probably rebuilt
before the lto changes I'm guessing, because it's not affected by this.
So I wonder how current jammy users could be affected by this (besides
the rebuild). Let's see if Michal has something to say about my comment
#15.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Andreas Hasenack]

I can't reproduce this bug anymore with the package currently in jammy
(1:10.6.7-2ubuntu1):

lxc launch ubuntu:focal f --vm
lxc shell f
lxd init # just hit enter for all questions
lxc launch ubuntu:jammy j
lxc shell j
ulimit -l # confirm it's less than 256
apt update && apt install mariadb-server -y

I wonder if it was just an interim issue in jammy's 1:10.6.7-3 package.
I'm doing a test rebuild of 1:10.6.7-2ubuntu1 in jammy.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Andreas Hasenack]

Hi Michal, I'm going over the test procedure for this bug and turns out
the scenario where we encountered it is a bit convoluted, specially for
users: you need to be running a 5.4 kernel on a jammy userspace (jammy
itself has 5.15 kernel).

Could you please elaborate on how this bug affects you? Are you included
in the above scenario, or is it something else?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Andreas Hasenack]

** Changed in: systemd (Ubuntu Jammy)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: systemd (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: systemd (Ubuntu Jammy)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Andreas Hasenack]

** Also affects: systemd (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: mariadb-10.6 (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Changed in: mariadb-10.6 (Ubuntu Jammy)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: mariadb-10.6 (Ubuntu Jammy)
   Status: New => Triaged

** Changed in: mariadb-10.6 (Ubuntu Jammy)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  New

Bug description:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Michal Nasiadka]

Hello, any idea when the fix will land in jammy?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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

Bug description:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Launchpad Bug Tracker]

This bug was fixed in the package mariadb-10.6 - 1:10.6.7-3ubuntu1

---
mariadb-10.6 (1:10.6.7-3ubuntu1) kinetic; urgency=medium

  * d/rules: disable LTO (LP: #1970634)

 -- Andreas Hasenack   Fri, 29 Apr 2022 09:30:44
-0300

** Changed in: mariadb-10.6 (Ubuntu)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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

Bug description:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Launchpad Bug Tracker]

** Merge proposal linked:
   
https://code.launchpad.net/~ahasenack/ubuntu/+source/mariadb-10.6/+git/mariadb-10.6/+merge/420845

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  Confirmed

Bug description:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Andreas Hasenack]

> Could it be -flto/-ffat-lto-objects related (like 
> https://jira.mariadb.org/browse/MDEV-25633)? 
> The top part of the stack trace looks the same.

Nice catch. Indeed, disabling lto fixes the build and startup in low
memlock conditions.

I'm still concerned with lto creeping in via krb5-config[1], but that's
another issue.


1. https://lists.ubuntu.com/archives/ubuntu-devel/2022-April/042013.html

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  Confirmed

Bug description:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  Confirmed

Bug description:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Daniel Black]

Could it be  -flto/-ffat-lto-objects related (like
https://jira.mariadb.org/browse/MDEV-25633)? The top part of the stack
trace looks the same.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Daniel Black]

On the assembly generated by create_linux_aio (in the mariadbd packages
in Ubuntu-22.04, 10.6.7-2:

(gdb) disassemble tpool::create_linux_aio,+200
Dump of assembler code from 0x5640cf2e1fb0 to 0x5640cf2e2078:
   0x5640cf2e1fb0 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+0>:  
endbr64 
   0x5640cf2e1fb4 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+4>:  
push   %rbp
   0x5640cf2e1fb5 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+5>:  
mov%rsp,%rbp
   0x5640cf2e1fb8 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+8>:  
push   %r14
   0x5640cf2e1fba <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+10>: 
mov%esi,%r14d
   0x5640cf2e1fbd <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+13>: 
push   %r13
   0x5640cf2e1fbf <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+15>: 
mov%rdi,%r13
   0x5640cf2e1fc2 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+18>: 
mov$0x158,%edi
   0x5640cf2e1fc7 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+23>: 
push   %r12
   0x5640cf2e1fc9 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+25>: 
sub$0x8,%rsp
   0x5640cf2e1fcd <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+29>: 
call   0x5640ceacb570 <_Znwm@plt>
   0x5640cf2e1fd2 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+34>: 
mov%r14d,%edx
   0x5640cf2e1fd5 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+37>: 
mov%r13,%rsi
   0x5640cf2e1fd8 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+40>: 
mov%rax,%rdi
   0x5640cf2e1fdb <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+43>: 
mov%rax,%r12
   0x5640cf2e1fde <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+46>: 
call   0x5640cf2e1dd0 <(anonymous 
namespace)::aio_uring::aio_uring(tpool::thread_pool*, int)>
   0x5640cf2e1fe3 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+51>: 
add$0x8,%rsp
   0x5640cf2e1fe7 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+55>: 
mov%r12,%rax
   0x5640cf2e1fea <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+58>: 
pop%r12
   0x5640cf2e1fec <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+60>: 
pop%r13
   0x5640cf2e1fee <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+62>: 
pop%r14
   0x5640cf2e1ff0 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+64>: 
pop%rbp
   0x5640cf2e1ff1 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+65>: 
ret
   0x5640cf2e1ff2 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+66>: 
endbr64 
   0x5640cf2e1ff6 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+70>: 
mov%rax,%rdi
   0x5640cf2e1ff9 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+73>: 
mov%rdx,%rax
   0x5640cf2e1ffc <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+76>: 
jmp0x5640ceb23308 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi-8121512>
   0x5640cf2e2001 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+81>: 
endbr64 
   0x5640cf2e2005 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+85>: 
mov%rax,%r13
   0x5640cf2e2008 <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+88>: 
mov%rdx,%r14
   0x5640cf2e200b <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi+91>: 
jmp0x5640ceb232fa <_ZN5tpool16create_linux_aioEPNS_11thread_poolEi.cold>
--Type  for more, q to quit, c to continue without paging--c
   0x5640cf2e2010 <_ZN5tpool19thread_pool_generic17create_native_aioEi+0>:  
endbr64 
   0x5640cf2e2014 <_ZN5tpool19thread_pool_generic17create_native_aioEi+4>:  
push   %rbp
   0x5640cf2e2015 <_ZN5tpool19thread_pool_generic17create_native_aioEi+5>:  
mov%rsp,%rbp
   0x5640cf2e2018 <_ZN5tpool19thread_pool_generic17create_native_aioEi+8>:  
push   %r14
   0x5640cf2e201a <_ZN5tpool19thread_pool_generic17create_native_aioEi+10>: 
mov%esi,%r14d
   0x5640cf2e201d <_ZN5tpool19thread_pool_generic17create_native_aioEi+13>: 
push   %r13
   0x5640cf2e201f <_ZN5tpool19thread_pool_generic17create_native_aioEi+15>: 
mov%rdi,%r13
   0x5640cf2e2022 <_ZN5tpool19thread_pool_generic17create_native_aioEi+18>: 
mov$0x158,%edi
   0x5640cf2e2027 <_ZN5tpool19thread_pool_generic17create_native_aioEi+23>: 
push   %r12
   0x5640cf2e2029 <_ZN5tpool19thread_pool_generic17create_native_aioEi+25>: 
sub$0x8,%rsp
   0x5640cf2e202d <_ZN5tpool19thread_pool_generic17create_native_aioEi+29>: 
call   0x5640ceacb570 <_Znwm@plt>
   0x5640cf2e2032 <_ZN5tpool19thread_pool_generic17create_native_aioEi+34>: 
mov%r14d,%edx
   0x5640cf2e2035 <_ZN5tpool19thread_pool_generic17create_native_aioEi+37>: 
mov%r13,%rsi
   0x5640cf2e2038 <_ZN5tpool19thread_pool_generic17create_native_aioEi+40>: 
mov%rax,%rdi
   0x5640cf2e203b <_ZN5tpool19thread_pool_generic17create_native_aioEi+43>: 
mov%rax,%r12
   0x5640cf2e203e 

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

[Daniel Black]

Note the runtime detection in innodb_use_native_aio_default affects the
default value only. Users can explicity set this and really on distros
to provide patched kernels.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Daniel Black]

Actually create_linux_aio (tpool/aio_liburing.cc:194) should already
catch this exception. So compiler error?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Daniel Black]

Assertion cause:

$  podman run --rm --cap-add=CAP_SYS_PTRACE -e MARIADB_ROOT_PASSWORD=bob -ti 
--user mysql  m106_jammy_debug  bash
mysql@0740c1895ab4:/$ gdb --args  mariadbd --bootstrap
GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from mariadbd...
Reading symbols from 
/usr/lib/debug/.build-id/44/991764aba74dce2376ff38060a66adb6cfe4c0.debug...
(gdb) r
Starting program: /usr/sbin/mariadbd --bootstrap
warning: Error disabling address space randomization: Function not implemented
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
2022-04-28 22:59:13 0 [Note] /usr/sbin/mariadbd (server 
10.6.7-MariaDB-2ubuntu1) starting as process 14 ...
[New Thread 0x7f1b390b2640 (LWP 17)]
[New Thread 0x7f1b245c0640 (LWP 18)]
2022-04-28 22:59:13 0 [Note] InnoDB: The first data file './ibdata1' did not 
exist. A new tablespace will be created!
2022-04-28 22:59:13 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-04-28 22:59:13 0 [Note] InnoDB: Number of pools: 1
2022-04-28 22:59:13 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2022-04-28 22:59:13 0 [Note] mariadbd: O_TMPFILE is not supported on /tmp 
(disabling future attempts)
2022-04-28 22:59:13 0 [Warning] mariadbd: io_uring_queue_init() failed with 
ENOSYS: try uprading the kernel

Thread 1 "mariadbd" received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=139754903728000) at 
./nptl/pthread_kill.c:44
44  ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=139754903728000) 
at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=139754903728000) at 
./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=139754903728000, signo=signo@entry=6) at 
./nptl/pthread_kill.c:89
#3  0x7f1b38a42476 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#4  0x7f1b38a287f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x5640ceb351dc in _Unwind_SetGR.cold ()
#6  0x5640cf4218af in __gcc_personality_v0 ()
#7  0x7f1b39743c64 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#8  0x7f1b39744321 in _Unwind_RaiseException () from 
/lib/x86_64-linux-gnu/libgcc_s.so.1
#9  0x7f1b38eae54b in __cxa_throw () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x5640ceb232ed in (anonymous namespace)::aio_uring::aio_uring 
(this=, tpool=, max_aio=, 
this=, tpool=, 
max_aio=) at ../tpool/./tpool/aio_liburing.cc:63
#11 0x5640cf2e2043 in tpool::create_linux_aio (max_aio=2048, 
pool=0x5640d1625cf0) at ../tpool/./tpool/aio_liburing.cc:194
#12 tpool::thread_pool_generic::create_native_aio (this=0x5640d1625cf0, 
max_io=2048) at ../tpool/./tpool/tpool_generic.cc:285
#13 0x5640ceaea297 in tpool::thread_pool::configure_aio 
(this=0x5640d1625cf0, use_native_aio=, max_io=max_io@entry=2048) 
at ../storage/innobase/./tpool/tpool.h:215
#14 0x5640ceaf07d5 in os_aio_init () at 
../storage/innobase/./storage/innobase/os/os0file.cc:3759
#15 0x5640ceb037f8 in srv_start (create_new_db=) at 
../storage/innobase/./storage/innobase/srv/srv0start.cc:1180
#16 0x5640cf1815b9 in innodb_init (p=) at 
../storage/innobase/./storage/innobase/handler/ha_innodb.cc:4275
#17 0x5640ceef25f2 in ha_initialize_handlerton (plugin=0x5640d14d8b00) at 
./sql/handler.cc:659
#18 0x5640cecb5c7f in plugin_initialize (tmp_root=0x7ffdb8bea250, 
plugin=0x5640d14d8b00, argc=0x5640cfbe92e0 , 
argv=0x5640d14a1860, options_only=)
at ./sql/sql_plugin.cc:1463
#19 0x5640cecb9a84 in plugin_init (argc=, argv=, flags=1) at ./sql/sql_plugin.cc:1756
#20 0x5640ceb8cf5b in init_server_components () at ./sql/mysqld.cc:5046
#21 0x5640ceb921fa in mysqld_main (argc=, argv=) at ./sql/mysqld.cc:5661
#22 0x7f1b38a29d90 in __libc_start_call_main 
(main=main@entry=0x5640ceb35240 , argc=argc@entry=2, 
argv=argv@entry=0x7ffdb8becb68)
at ../sysdeps/nptl/libc_start_call_main.h:58
#23 0x7f1b38a29e40 in __libc_start_main_impl (main=0x5640ceb35240 
, argc=2, argv=0x7ffdb8becb68, init=, 
fini=, 
rtld_fini=, stack_end=0x7ffdb8becb58) at 
../csu/libc-start.c:392
#24 0x5640ceb7cbe5 in _start ()


So it looks like an uncaught exception.

Testing with:

diff --git 

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

[Daniel Black]

>From 5.12 kernel memory locked pages aren't needed -
https://github.com/axboe/liburing/issues/246#issuecomment-816965961.

In #1969160 I tested the upcoming 10.6 release (probably next week
sometime) for crashes in uring initialization failures and it didn't.
Apart from some error log differences from ENOMEM, ENOSYS etc are
handles the same way in the fallback.

I haven't quite concluded how the 10.6.7 release is crashing at the
moment.

With https://bugs.launchpad.net/ubuntu/+source/linux-
hwe-5.13/+bug/195 I assume the jammy kernel 5.15.0 has the right
patches to make 5.15.0 safe despite the MariaDB code not distinguishing
it as so (suggestions of improving kernel version detection welcome).

** Bug watch added: github.com/axboe/liburing/issues #246
   https://github.com/axboe/liburing/issues/246

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Andreas Hasenack]

Since mariadb on the current jammy kernel disables io_uring at startup,
I'm considering disabling io_uring entirely in the jammy mariadb build.
The only scenario where io_uring would be used by the jammy mariadb is
if the user ran a different kernel than the one shipped with jammy.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
   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.
   But then the Launchpad builders got updated to a newer release and 
therefore a newer kernel that supported it.
   AIUI, that's how we ended up with a successful build in the Jammy 
release pocket (of 10.6).
   I think the lp builders are using the focal hwe kernel
   5.4.0-something
   let me check that build log
   But then something changed that caused this current FTBFS, and I 
haven't tracked down what that is.
   hm, both are 10.6.7
   release and proposed
   What puzzles me is that if the root cause is a memlock rlimit issue 
then why did it work before?
   So since there's a contradiction somewhere, maybe one or more of my 
"facts" above is wrong.
   this is the current failure
   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)
   and ulimit -l confirms that the limit is lower
   Max locked memory 6553665536  
  bytes 
   just 64kbytes
   Yeah but then how did the release pocket build work?
   either the limit was different back then
   or ... stuff

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp