[MDEV-26569] 10.6 mariadbd error: io_uring_queue_init() failed with ENOSYS, and then asserts Created: 2021-09-08 Updated: 2022-10-22 Resolved: 2022-07-29 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.6 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Otto Kekäläinen | Assignee: | Daniel Black |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Description |
|
While preparing 10.6.4 for official Debian upload I noticed that the builds fail when mariadb-test-run tries to start mariadbd on Launchpad with the following error on multiple platforms:
Full log:
The only platform that worked was armhf. |
| Comments |
| Comment by Marko Mäkelä [ 2021-09-08 ] | |||||||
|
I checked one of the linked logs. It starts with the following:
I found a claim that io_uring first appeared in the Linux 5.1 kernel. I would not expect it to be backported to older kernels, such as the 4.15 based kernel here. One of the first mainstream distributions whose kernel supports io_uring (Ubuntu 20.04) is claimed to have shipped with a 5.4 kernel. As far as I understood, it did not include liburing. Here you seem to have a ‘too new’ userspace running on an old kernel. If it is not possible to upgrade the affected systems to a newer kernel, you have two options:
| |||||||
| Comment by Otto Kekäläinen [ 2021-09-08 ] | |||||||
|
Thanks for a quick reply. I guess the Launchpad builders run Ubuntu Bionic and buildd in containers, thus inheriting the kernel 4.15: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=linux-image-generic I asked for access to Ubuntu 20.04 Launchpad build hosts in https://answers.launchpad.net/launchpad/+question/698668 | |||||||
| Comment by Tuukka Pasanen [ 2021-09-12 ] | |||||||
|
This solved or need more work to stop requiring uring? | |||||||
| Comment by Otto Kekäläinen [ 2021-09-12 ] | |||||||
|
There is nothing to be fixed in MariaDB for this – it is correct for MariaDB builds to assume that on new Debian/Ubuntu releases a kernel 5.4+ would be available. Tracking Launchpad.net builder host updates in https://bugs.launchpad.net/launchpad/+bug/1943292 | |||||||
| Comment by Tuukka Pasanen [ 2021-11-04 ] | |||||||
|
I'm closing this as there is nothing to-do | |||||||
| Comment by Daniel Black [ 2022-02-09 ] | |||||||
|
I'm going to open to fix the assertion aspect of this, and perhaps fall back to innodb_use_native_aio=0. I plan on using 22.04 as the basis for 10.8+ container images once Ubuntu-22.04 released. Those are going to operate on older kernels, potentially even ones that don't support io_uring. An assertion looks really sloppy, and we could just fall back to innodb_use_native_aio=0 like we did | |||||||
| Comment by Daniel Black [ 2022-02-10 ] | |||||||
|
MariaDB does appear to be forcing AIO itself off with a simulated ENOSYS.
I don't know how the 2021-12-15 builds are asserting https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.6/+builds?build_text=&build_state=all | |||||||
| Comment by Daniel Black [ 2022-02-15 ] | |||||||
|
Waiting to see if 10.6.7 suffers same problem on https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.6/+builds?build_text=&build_state=all | |||||||
| Comment by Otto Kekäläinen [ 2022-02-17 ] | |||||||
|
I uploaded 10.6.7 to https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.6/+builds?build_text=&build_state=all and unfortunately it still fails to build. However on a closer look the error is related to OpenSSL 3.0 entering repos: This was visible both in latest 10.6.7 and for the 10.6.6 build https://launchpadlibrarian.net/585123790/buildlog_ubuntu-jammy-amd64.mariadb-10.6_1%3A10.6.6-1~ubuntu22.04.1~1644378769.2423f1afc81.debian.latest_BUILDING.txt.gz | |||||||
| Comment by Otto Kekäläinen [ 2022-02-24 ] | |||||||
|
Launchpad builders are now fixed in https://bugs.launchpad.net/launchpad-buildd/+bug/1943292 and builds at https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.6/+builds?build_text=&build_state=all work again |