unattended-upgrade cancellation does not work

[Alexandre Ghiti]

Cancelling the unattended-upgrade at the very end of the installation process does not seem to work as we can see in the logs that the upgrade goes on: this issue is particularly visible on riscv where it takes a very long time.

Attached a targz of /var/log.

[Olivier Gayot (ogayot)]

I made several attempts using focal & jammy as the base iso on amd64 VMs.
I tested with the current version of Subiquity in main (that includes systemd-run), as well as the 22.02.2 version.

The behavior was different but at the end of the day, I wasn't able to cancel unattended-upgrades properly in any scenario.

The worst experience was arguably on 22.02.2 with Jammy. As soon as "cancel updates and reboot" was hit, it seems like the startup sequence started. However, unattended-upgrades was still running and the unattended-upgrade-shutdown --stop-only process still running as well.

The journal started to fill very quickly and soon I ended up with a mix of:

Apr 07 11:29:59 ubuntu-server systemd[1]: This usually indicates unclean termination of a previous run, or servic>
Apr 07 11:29:59 ubuntu-server systemd[1]: systemd-journald.service: Found left-over process 26641 (systemd-journa>
Apr 07 11:29:59 ubuntu-server systemd[1]: This usually indicates unclean termination of a previous run, or servic>
Apr 07 11:29:59 ubuntu-server systemd[1]: systemd-journald.service: Found left-over process 27038 (systemd-journa>
Apr 07 11:29:59 ubuntu-server systemd[1]: This usually indicates unclean termination of a previous run, or servic>
Apr 07 11:30:01 ubuntu-server systemd-journald[58620]: File /var/log/journal/259b437d315445d0806361b688e24137/system.journal corrupted or uncleanly shut down, renaming and replacing.
Apr 07 11:30:00 ubuntu-server systemd-journald[36530]: Failed to write entry (10 items, 319 bytes), ignoring: Inv>
Apr 07 11:30:01 ubuntu-server systemd-journald[16707]: Failed to write entry (25 items, 723 bytes), ignoring: Inv>
Apr 07 11:30:02 ubuntu-server systemd[1]: Unnecessary job was removed for /sys/devices/virtual/block/loop7.

[Michael Hudson-Doyle (mwhudson)]

Oops. This definitely used to work! The cancellation can take a while but rebooting while it's still happening is certainly not intended! The state machine around cancellation is a bit complicated, I guess some refactoring broke it :(