Verification on Questing, Noble and Jammy =========================================
The issue can only be verified on the certification setup using the snapd snap. See: https://bugs.launchpad.net/snapd/+bug/2139300/comments/12 It is therefore not required to test on Questing, Noble and Jammy. ** Description changed: [SRU] 2.74.1: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/2138629 [ Impact ] + + Snapd snap only. Using plz-run to launch a transient systemd unit does not work as expected on some platforms, yielding the error: "cannot set memlock limit to 524288:524288: Operation not permitted" This verification can only be reliable reproduced by running the known problematic certification tests. It is therefore only relevant to the snapd snap, and not required to be verified for snapd deb for all Ubuntu versions. [ Test Plan ] 1. Reproduce with snapd snap < 2.74.1 No need to reproduce, the testing logs have evidence that this happens very reproducible. 2. Prove fixed with snapd snap 2.74.1 Run certification tests and ensure no instance of "cannot set memlock limit to 524288:524288: Operation not permitted". ---original--- Calling a snap from a (devmode) snap (i.e. Checkbox calling bluez.hcitools) now results deterministically in the following error: ``` /system.slice/snap.checkbox-riverside.remote-slave.service is not a snap cgroup for tag snap.bluez.hcitool ``` To work around this issue a new tool was created called `plz-run`, intended to work similarly to `systemd-run` but be compatible with core16+ and use little dbus APIs as possible (to allow us to create a Checkbox-specific interface in snapd that partially already landed, `checkbox-support`). Using this tool we launch the job as a transient systemd unit, therefore outside the sandbox. This should allow us to call other snaps just fine. In recent testing we discovered that this doesn't work on some platforms, yielding the following error: ``` cannot set memlock limit to 524288:524288: Operation not permitted ``` This issue seems to also manifest without Checkbox. This does not happen using `systemd-run`. Reproducer: ``` # on a system with a bluetooth device, this doesn't seem to happen when # image-garden allocate ubuntu-core-22.x86_64 for example $ sudo snap install --edge checkbox22 # this just to pull plz-run, convenient $ sudo snap install bluez $ sudo /snap/checkbox22/2396/bin/plz-run -u ubuntu -g ubuntu -pam system-login snap run bluez.hcitool dev ``` As requested by Zyga, the following may be relevant: ``` static void _sc_cgroup_v2_set_memlock_limit(struct rlimit limit) { /* we may be setting the limit over the current max, which requires root * privileges or CAP_SYS_RESOURCE */ if (setrlimit(RLIMIT_MEMLOCK, &limit) < 0) { die("cannot set memlock limit to %llu:%llu", (long long unsigned int)limit.rlim_cur, (long long unsigned int)limit.rlim_max); } } // _sc_cgroup_v2_adjust_memlock_limit updates the memlock limit which used to be // consulted by pre 5.11 kernels when creating BPF maps or loading BPF programs. // It has been observed that some systems (eg. Debian using 5.10 kernel) have // the default limit set to 64k, which combined with an older way of accounting // of memory use by BPF objects, renders snap-confine unable to create the BPF // map. The situation is made worse by the fact that there is no right value // here, for example older systemd set the limit to 64MB while newer versions // set it even higher). Returns the old limit setting. static struct rlimit _sc_cgroup_v2_adjust_memlock_limit(void) { struct rlimit old_limit = {0}; if (getrlimit(RLIMIT_MEMLOCK, &old_limit) < 0) { die("cannot obtain the current memlock limit"); } /* this should be more than enough for creating the map and loading the * filtering program */ const rlim_t min_memlock_limit = 512 * 1024; if (old_limit.rlim_max >= min_memlock_limit) { return old_limit; } debug("adjusting memlock limit to %llu", (long long unsigned int)min_memlock_limit); struct rlimit limit = { .rlim_cur = min_memlock_limit, .rlim_max = min_memlock_limit, }; _sc_cgroup_v2_set_memlock_limit(limit); return old_limit; } ``` Current system: ``` ubuntu@ubuntu:~$ uname --all Linux ubuntu 5.15.0-1092-intel-iotg #98-Ubuntu SMP Wed Oct 29 12:40:01 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux ubuntu@ubuntu:~$ snap list Name Version Rev Tracking Publisher Notes bare 1.0 5 latest/stable canonical** base bluez 5.48-5 400 latest/stable canonical** - checkbox-iiotg 0.1dev-jammy 78 - ce-certification-qa devmode checkbox22 7.0.0-dev130 x1 latest/edge - devmode,try core 16-2.61.4-20250910 17272 latest/stable canonical** core core22 20260113 2292 latest/stable canonical** base,ignore-validation intel-iotg-kernel 5.15.0-1092.98.1 197 22/stable canonical** kernel pc 22-0.4 194 22/stable canonical** gadget snapd 2.74 26217 latest/beta canonical** snapd strace-static 6.8 114 latest/stable canonical** - ``` ** Tags removed: verification-needed-jammy verification-needed-noble verification-needed-questing ** Tags added: verification-done-jammy verification-done-noble verification-done-questing -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2139300 Title: Snap starting results in cannot set memlock limit to [...] Operation not permitted To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/2139300/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
