bad interaction between snapd and update-notifier when snapd package is being upgraded
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd (Ubuntu) |
Fix Released
|
High
|
Alberto Mardegan | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Impish |
Fix Released
|
High
|
Unassigned | ||
update-notifier (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
[Impact]
On a release upgrade from impish to jammy, dbus postinst hangs for 10 minutes.
[Test Case]
Testing the fix itself:
On a minimal impish system (created with autopkgtest-
$ sudo snap install canonical-livepatch
$ apt list -a snapd
[shows the impish proposed version is used]
$ sudo sed -i 's/impish/jammy/' /etc/apt/
$ sudo apt update
$ apt list -a snapd
[shows the PPA version as the one that will be upgraded to]
$ sudo apt full-upgrade -y
This should pass
Another test would be simply trying an upgrade from impish to jammy as per the original report.
[Regression Potential]
TBD
[Original Description]
On a release upgrade from impish to jammy, I noticed that the dbus postinst hung for 10 minutes. It hung trying to make two calls to canonical-livepatch via /usr/share/
An strace of the second process showed that canonical-livepatch was looping trying to connect to /run/snapd.socket:
[pid 769177] connect(3, {sa_family=AF_UNIX, sun_path=
This was not attached to anything, because the snapd package was among those in the current apt transaction, and was currently not in a configured state:
root 756701 0.0 0.0 24144 12556 pts/20 Ss+ 17:26 0:00 | | \_ /usr/bin/dpkg --force-overwrite --status-fd 57 --no-triggers --configure apparmor:amd64 openssl:amd64 ca-certificates:all libmd0:amd64 libmd0:i386 libbsd0:amd64 libbsd0:i386 libedit2:amd64 libtinfo6:i386 libedit2:i386 libcbor0.8:amd64 libfido2-1:amd64 libkrb5support0
iU snapd 2.55.3+22.04 amd64 Daemon and tooling that enable snap packages
This should probably be fixed by not stopping snapd in the prerm (dh_systemd_start --restart-
Changed in snapd (Ubuntu Impish): | |
importance: | Undecided → High |
Changed in update-notifier (Ubuntu): | |
status: | Confirmed → Invalid |
description: | updated |
Changed in snapd (Ubuntu): | |
status: | Fix Released → Fix Committed |
Hi Steve, thanks for reporting this, and for the hint on how to fix it. We currently have a shell script in our prerm script, which manually stops all our systemd units:
https:/ /github. com/snapcore/ snapd/blob/ master/ packaging/ ubuntu- 16.04/snapd. prerm
Do I correctly understand that your suggestion is not to do that?
I'm actually a bit confused (though this is probably a question for my own team) why we have that prerm script, when we are already using dh_systemd_start in out debian/rules file:
============== dh_systemd_ start: /github. com/systemd/ systemd/ issues/ 8102 snapd/lib/ systemd/ system/ ))
override_
# Due to https:/
# debhelper supporting --remaining like behaviour here would
# have been useful
# (Re-)start socket first
dh_systemd_start snapd.socket
# Then service
dh_systemd_start snapd.service
# Then the rest
dh_systemd_start $(filter-out snapd.socket snapd.service, $(shell ls debian/
==============
wouldn't this rule already cause the units to be stopped at the prerm step (we are using debhelper compatibility level 9)?
Anyway, I'm soon going to propose a PR, so we can discuss over it.