Comment 5 for bug 2028124

Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

Thank you for taking the time to report the bug.

Indeed, I can confirm that qemu-guest-agent.service won't restart after upgrading. For the sake of completeness, here are the steps to verify:

$ lxc launch ubuntu:jammy j --vm -c limits.memory=8GB

Make sure to extend the rootfs size of the VM if needed.

$ lxc shell j
# apt update && apt install -y uvtool uvtool-libvirt
# ...
# su - ubuntu
$ ssh-keygen
$ uvt-simplestreams-libvirt sync release=jammy arch=amd64
$ uvt-kvm create test release=jammy --memory 2024
$ uvt-kvm wait test
$ uvt-kvm ssh test

You can also spawn other releases like Lunar or Mantic. They are all affected by the issue.

Basically, a good way to reproduce the bug is to start the agent, and then simply reinstall the package:

# apt install qemu-guest-agent
# systemctl start qemu-guest-agent
# apt install --reinstall qemu-guest-agent

You will notice that the service doesn't come back up.

Now, the root cause of this problem is the use of "--no-start" in the following d/rules line:

dh_installsystemd -a -pqemu-guest-agent --no-start --no-enable

According to dh_installsystemd:

--no-start
    Do not start the unit file after upgrades and after initial installation (the latter is only relevant for services without a corresponding init script).

Moreover, since qemu is using debhelper-compat 12 or greater, the default option for dh_installsystemd is:

--restart-after-upgrade
    Do not stop the unit file until after the package upgrade has been completed. This is the default behaviour in compat 10.

So, the way I see it, there are two ways to possibly fix this problem:

1) Use --no-restart-after-upgrade, which, contrary to what its name says, will stop the service in the prerm script (which is already being done by default), and start the service again after upgrade.

2) Remove the --no-start option from the d/rules line. I tested it here and it doesn't seem to have any negative side-effects.

I'm still running a few tests and will report back later. This is something that I intend to bring to the Debian qemu maintainer's attention as well.