Launchpad builder VMs upgraded to bionic

[Dimitri John Ledkov]

Hi,

On Tue, 8 Sep 2020 at 17:49, Colin Watson <cjwatson at 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.