Hi, On Tue, 8 Sep 2020 at 17:49, Colin Watson <cjwat...@canonical.com> wrote: > > On Tue, Sep 08, 2020 at 12:57:28PM -0300, Guilherme Piccoli wrote: > > Hi Colin et.al., first of all thanks for the builder update and > > heads-up! We've noticed a failure in building cryptsetup from source, > > reported in LP #1891473 [0]. The reason for such failure is detailed > > in the LP, but a summary is: > > - cryptsetup might make use of mlock() syscall and so, restrict its > > memory usage by the memlock limit (ulimit -l), if it succeeds the > > mlock() call; > > - in Xenial, the memlock limit was extremely low, so mlock() failed > > and the cryptsetup test hereby failing (luks2-metadata validation) > > succeeded, since cryptsetup continues with no locked memory; > > -in Bionic, such limit was bumped to 16M [1], and cryptsetup succeeds > > in the memory locking procedure, but...the limit is low enough in > > order the luks2-metadata-validation-4M exceeds that and fails - worth > > to notice that chroot/containers inherit those limits from host; > > - in Focal such a limit was quite increased (to 64M), so the tests do > > not fail anymore. > > > > In my understanding, we have 2 ways of resolving that: > > > > (a) We could bump the memlock limit in PPA builders to 64M (to match > > real-life cases of Focal, specially useful for Focal packages being > > built); > > The simplest and IMO best way to do this would be to SRU the systemd > change that bumped it to 64M [1] to bionic; we'd then pick that up in > the natural course of events by way of new cloud image builds. Has that > been considered? It feels as though what's happened here is simply that > the Launchpad build farm upgrade has surfaced a bug in bionic, so the > most appropriate thing to do would be to fix it in bionic. >
Upstream it was done as part of larger changes to add BPF functionality. But it is worth-while to pick up just the limit bump there. > Failing that, can somebody advise on whether there's an appropriate way > to configure this in an image without having to maintain a fork of > systemd? The workflow here is that we consume Ubuntu cloud images and > make a few small changes to them, mostly things like installing > launchpad-buildd, before publishing them to Glance for use when starting > new builder VMs. > I have not tried this, but i think one should be able to create a snippet in /etc/security/limits.d/ with like * soft memlock unlimited * hard memlock unlimited Or to the appropriate value of 64*1024 instead of unlimited. > [1] https://github.com/systemd/systemd/commit/91cfdd8d29 > -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel