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