snap-update-ns should unconditionally rebuild snap mount namespaces if there are certain deleted mounts in them
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| snapd |
New
|
Undecided
|
Unassigned | ||
Bug Description
When you have a snap like the snap-store snap installed and running, it will have a mount namespace reference stored in /run/snapd/ns. It seems when removing the debian package of snapd, this mount namespace reference is not deleted, but since files in that namespace are deleted on the host, such as /usr/lib/snapd, those mounts inside the mount namespace become "//deleted" in /proc/self/
This is problematic because it seems upon reinstalling snapd debian package without rebooting (which would in effect discard the namespace reference), and then reinstalling the same snap such as snap-store, snap-confine/
So:
1) there is a bug in the debian packaging postrm script, etc. We should be getting rid of these namespace references when we uninstall/remove snapd
2) snap-confine/
| Maciej Borzecki (maciek-borzecki) wrote | #1 |
| Sergio Cazzolato (sergio-j-cazzolato) wrote | #2 |
Ad 1. we have a section which unmounts the ns and removes the mnt file: https:/
It's already a bit weird to purge snapd when there are snap applications running, it's not really clear what should happen in such scenario. Killing the applications forcefully may not be the best option though.