I’m working on a new feature where snapd can detect that the root file system of a given snap (as seen from its mount namespace) has become stale and automatically updates it if it is safe to do so.
First of all, the root filesystem is your snap’s designated base snap. For most developers that is the current core snap. Each time the core snap is refreshed it can bring in fixed libraries, programs and new features but because up until now this change was not reflected in even new processes if any process belonging to the same snap ran before. In practical terms you’d have to reboot to see the changes.
This is certianly suboptimal so after completing the live changes to mount namespaces in response to interface (content interface) connection changes I jumped into the problem of stale rootfs.
Progress look good, I have a working prototype. As I just stepped off the plane I won’t link to a branch but expect a New RFC pull request tomorrow.
One thing that I want to highlight is that my solution explicitly only updates the mount namespace if there are no processes using that namespace anymore. This includes services, apps and hooks alike. The guiding principle was to make sure all processes see the same, consienten, namespace. This means that a long running process can de-facto block important updates for the entire snap until the service is re-started. I think that for IOT applications we need to put a limit and possibly force all the processes to exit. This feels like a topic to discuss this week (at the sprint). I also think this could be done, for snapd that behave nicely, as a hook that asks the snap to become consistent in anticipation of shutting down. Note that this must include all processes, of all kinds. For most software, and perhaps even as a default, in absence of a hook. It could just say “go ahead and restart the snap” but perhaps such view is too naive (uptime at crtiical moments).
Anyway, I just wanted to share this. Stay tuned for more.