Control: fixed -1 2.11.1-1 Control: blocked -1 by 879585 Control: severity -1 normal
Hi, (downgrading priority as triggering this bug requires a combination of 2 non-default settings: enabling AppArmor *and* running a kernel from backports) solitone: > When apparmor is enabled, the guest does not shut down correctly, > but remains in the "shutting down" state forever. I believe this is the culprit: > Jan 14 17:42:27 kernel: audit: type=1400 audit(1515948147.468:98): > apparmor="DENIED" > operation="signal" profile="libvirt-86d03398-41ea-4eb6-a6ea-d2a2986a6a56" > pid=768 > comm="libvirtd" requested_mask="receive" denied_mask="receive" signal=term > peer="/usr/sbin/libvirtd" That's explained because you're running Linux 4.14: > Kernel: Linux 4.14.0-0.bpo.2-amd64 (SMP w/4 CPU cores) … that adds new mediation features, such as signal mediation, which are not supported by the AppArmor policy shipped in Stretch, and AppArmor denies any mediated operation that's not explicitly allowed by the policy. This will be fixed in Stretch once we pin the AppArmor feature set to the subset that's correctly supported there, i.e. https://bugs.debian.org/879585 In the meantime, you can either run the kernel from Stretch, or install the libvirt AppArmor policy from current Debian testing/sid, or apply this pinning yourself locally: 1. copy https://salsa.debian.org/apparmor-team/apparmor/blob/debian/stretch/debian/features to /etc/apparmor/features 2. edit /etc/apparmor/parser.conf so it has a line that says: features-file=/etc/apparmor/features 3. reboot … but due to a bug in the Linux 4.14 kernel until 4.14.12 inclusive (https://bugs.debian.org/883703), mount mediation will be broken if you do that. This may or may not break your libvirt use case. But if you run Linux 4.14.13 or newer, the above steps should fix the problem you're experiencing. Cheers, -- intrigeri