snapd refresh after 2.49.2 kills snap services
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| snapd |
Fix Released
|
Critical
|
Ian Johnson | ||
Bug Description
After a UC18 or UC20 system is refreshed to snapd 2.49.2, due to this PR: https:/
```
Requires=
After=usr-
```
Which is to fix a race condition on certain devices where the device unexpectedly reboots during a snapd refresh.
This is problematic because when we refresh snapd itself after having written out some systemd units that include the Requires= above (which could happen for app snap refreshes or new installs after snapd 2.49.2 is installed), now we will unmount/stop usr-lib-
Since snapd 2.49.2 has already been deployed, we need a solution to this wherein the new snapd that is refreshed to can figure out how to restart snap services that were killed by the old snapd that stopped the usr-lib-snapd.mount unit before finalizing the refresh to the new snapd.
| Changed in snapd: | |
| assignee: | nobody → Ian Johnson (anonymouse67) |
| importance: | Undecided → Critical |
| status: | New → In Progress |
| Ian Johnson (anonymouse67) wrote | #1 |
| Paweł Stołowski (stolowski) wrote | #2 |
| Changed in snapd: | |
| status: | In Progress → Fix Committed |
| status: | Fix Committed → Fix Released |
| Ian Johnson (anonymouse67) wrote | #3 |
| Changed in snapd: | |
| milestone: | none → 2.51 |
The root cause of why snap services get killed but not restarted here is because the order of operations that snapd does during a snapd snap refresh is as follows:
1) change usr-lib-snapd.mount
2) systemctl daemon-reload
3) systemctl enable usr-lib-snapd.mount
4) systemctl stop usr-lib-snapd.mount (!!!!!!
5) systemctl start usr-lib-snapd.mount
Step 4 is the bit that kills the snap services, and then when we do step 5, the services that we killed in 4 are not restarted. If instead we did the following:
1) change usr-lib-snapd.mount
2) systemctl daemon-reload
3) systemctl enable usr-lib-snapd.mount
4) systemctl restart usr-lib-snapd.mount
then we would not have this situation where snap services get killed when snapd gets refreshed.
We don't necessarily need to change this behavior since snapd in the wild is already doing this, so we can't really stop it from doing it when we refresh to a newer snapd, but this makes it more clear what is going on.