Hi Christian, Christian Boltz (2021-11-08): > Your patch looks like something that should (also?) be fixed upstream.
My understanding is that the problem here is caused by a Debian patch: https://salsa.debian.org/apparmor-team/apparmor/-/blob/debian/master/debian/patches/debian/Make-the-systemd-unit-a-no-op-in-containers-with-no-inter.patch I could trace the history of that patch back to 2012 (2.7.102-0ubuntu3): * debian/apparmor.init: do nothing in a container. This can be removed once stacked profiles are supported and used by lxc. (LP: #978297) So I believe upstream is not affected, because it'll try to load the AppArmor policy even inside the kind of containers where it will fail (that is, most kinds). I'm going to drop this patch in Debian, which should fix the problem this bug report is about, because: - As we can see here, this patch causes trouble in some environments. - Most container technologies I'm aware of are closer to application containers than system containers, and are not going to start the whole pile of systemd units, so the patch does not matter there. LXC is the only exception I'm aware of. - The fact other distros did not need to apply such a patch suggests it's not necessary for most use cases. - I don't have any time/energy/motivation anymore to maintain or upstream myself patches that were initially created as part of the Ubuntu delta to meet Canonical's strategic goals & deadlines, and never pushed upstream. I'm still immensely grateful by the work done upstream by Canonical employees, though! If removing the patch causes trouble for some sort of LXC containers (there are multiple ways they can or cannot handle AppArmor, depending on versions, system configuration, per-container configuration, I lost track), I'll report this upstream and hopefully a LXC-friendly solution will be implemented there by those of us who particularly care about LXC :) Cheers!
