Verification for resolute (26.04): snapd 2.78+ubuntu26.04 from resolute- proposed
Test host: fresh VM, Ubuntu 26.04.1 LTS, kernel 7.0.0-30-generic, apparmor 5.0.2-0ubuntu1~26.04.1. Snaps installed: lxd 5.21.8 (5.21/stable), hello-world, snapd snap 2.77.1 (rev 28254). Setup notes Every test was run first on 2.77.1+ubuntu26.04.2 from -updates, then on 2.78+ubuntu26.04 from -proposed (only snapd was installed from -proposed: pin priority 100, apt install -t resolute-proposed snapd). The deb was in use in both runs, checked during each test: the snapd daemon ran /usr/lib/snapd/snapd (not the copy in the snapd snap), and snap version reported the deb builds (2.77.1+ubuntu26.04.2, then 2.78+ubuntu26.04). snapd.service ran with SNAPD_DEBUG=1, so every decision snapd makes on a reported mismatch is logged as “reported system key mismatch action: <action>“. Test 1: the defect itself I sent snapd 5 mismatch reports (POST /v2/system-info, action=advise- system-key-mismatch), a few seconds apart. Each report contained the system-key from disk, unchanged except apparmor-parser-features set to null, which is how a client’s report looks (see the client report quoted in the bug description). So the keys really match, and snapd should not regenerate anything. 2.77.1 (-updates): all 5 answered “regenerate-profiles”, 5 “Regenerate security profiles” changes. This is the bug. 2.78 (-proposed): all 5 answered “none”, 0 regenerations. Fixed. Test 2: real mismatches are still handled On 2.78 I sent 1 report where the key really differed (apparmor-parser- mtime changed). snapd answered “regenerate-profiles” and ran 1 regeneration, which is correct: the fix only ignores the parser-features field, not real differences. Test 3: under load 8 parallel “snap run hello-world” loops for 150 s (about 4600 launches). 10 s into the run I changed apparmor-parser-mtime in /var/lib/snapd/system-key once, to cause one real regeneration while launches were happening. 2.78: exactly 1 regeneration (the one caused by the change), no follow-up regenerations. snapd used 132 ms CPU over the 150 s window and 7 ms over a 60 s idle period afterwards, with no regenerations in that minute. 2.77.1 gave the same result (1 regeneration) on this fresh VM, so this test does not tell the versions apart. It only shows that 2.78 behaves normally under load. Test 1 is the one that shows the fix. Sanity on 2.78 An ubuntu:26.04 LXD container launched and ran a command; a snap installed, ran and was removed; snapd and apparmor active; no errors in the snapd journal. Result The fix works on resolute. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2161845 Title: snapd loops forever on "Regenerate security profiles" and writes about 4 TB per day To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/2161845/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
