> 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: <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
