On Tue, Sep 8, 2020 at 1:48 PM Colin Watson <cjwat...@canonical.com> wrote: > 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. >
Thanks Colin, it is a good idea! Although, I've seen uploads from my teammates take like 2-3 months to get merged/released on systemd package, due to security fixes on such package. It might take a while to get the fix organically if we follow such approach... > 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 think the cloud image folks can chime in with good ideas, but I'd consider cloud-init - likely it's possible to configure it in a way to apply this change on boot time. Another idea: would it be possible to change launchpad-buildd to accomplish the ulimit change ? Cheers, Guilherme _______________________________________________ Mailing list: https://launchpad.net/~launchpad-users Post to : launchpad-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-users More help : https://help.launchpad.net/ListHelp
