@ustcweizhou - very interesting approach to fix this. The type is usually 
"notify". 
There is a drawback that you change implies follow up units might start as soon 
as the daemonizing of libvirt is complete which might be too early. The 
notification would usually signal that it is completely ready and follow on 
units can be started. But lets ignore that for now and consider how it could 
affect the application of the netlink apparmor rule.

Related to comment #10 and comment #11 ff.
If there is an old manual config that will set -d in /etc/default/libvirt-bin 
/etc/default/libvirt-bin then your change of the service file would make it 
match the behavior.
There should be a non-default connection as the service file 
/lib/systemd/system/libvirt-bin.service starts libvirt "directly" and not via 
/etc/default/libvirt-bin - so the -d in that old files (if you are on 
SystemV/Upstart) should not matter.

For all still affected by this could you check:
1. if your libvirt is run with "-d" option (which it should not be anymore)
2. if #1 was yes, then where this config comes from
3. once you debugged #2, decide if you either want to become closer to the 
supported content by changing back OR try a fix like suggested in comment #38 
(which is not generally applicable)

For everyone passing step #2 I'd be interested how in your personal
system setup the "-d" gets applied, as with the systemd setup it should
not be used anymore.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1594902

Title:
  Failed to upgrade to libvirt-bin 1.3.1-1ubuntu10.1 on Ubuntu 16.04
  64-bit

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1594902/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to