TO @jamesh CC @jdstrand
I had a look at https://github.com/snapcore/snapd/pull/3963 and discussed this with @niemeyer
There’s an argument that what we did in the paste (delivering persistent mount namespaces before the update tool) was a mistake and we should attempt not to repeat that mistake here. We think there is a way forward that avoids that:
Let’s start by examining the issue in case we start to persist the per-user mount namespace. The only problem is that the FUSE mount uses a userspace daemon and that daemon is killed when the session is ending and when the user is logging out. We can treat this as a specific case of the “mount namespace is stale” problem.
We already have (partial) logic for handling that (we handle the detection, we don’t act on this yet). We can extend that logic to include a condition “there are no processes belonging to the given user that are alive anymore”. The base namespace will be updated when the base snap changes and it is safe to do so (no processes from that snap are alive). The per-user mount namespace is stale when it is no longer inhabited by any processes belonging to that user. We can use the same process enumeration technique we already have for doing that.
This will work but will result in a small inefficiency. In a case where we run a single process application, close it and run it again we will re-construct the per-user namespace even though it was not really necessary. As an optimization we can also store the identifier of the session and keep the using the persisted per-user mount namespace, even if it has no processes anymore, for as long as the session identifier is unchanged.
Let’s do this:
- capture the per-user mount namespace in a new file
/run/snapd/snap.$SNAP_NAME.user.$UID.mnt
, this file will live alongside the older /run/snapd/ns/$SNAP_NAME.mnt
(over time that other will migrate to snap.$SNAP_NAME.system.mnt
)
- before running the update tool consider reusing or discarding the preserved per-user mount namespace. The conditions are described above (no processes belonging to that user and snap are alive anymore).
- run
snap-update-ns
for each user whenever interfaces change requires this (user mount profiles change). We can enumerate the existing per-user mount namespaces by looking at /run/snapd/ns/snap.*.user.*.mnt
and running the tool for each one.
This has the benefit of actually handling updates (we can disconnect and the fuse mount will go away) and opening the path for more general user mounts (we could start using $SNAP_USER_DATA
)
What do you think?