When the core snap is refreshed on a classic system snapd restarts (if re-exec is supported) into the new core snapd. This works fine, however if there is an error during the refresh and snapd reverts to the previous core on revert snapd does not re-exec itself into the old core snap. This leads to hard to read errors later like “cannot find snap-seccomp” on 2.25. We need to ensure that on revert we also restart back into the old snapd.
1 Like
Thanks for reporting and tracking this, Michael.
I’ve hit that exact issue over the weekend. The root cause was lack of space in the filesystem, so the revert was totally fine and desirable. The behavior of the system after that was super confusing, since everything I could observe in the filesystem itself seemed fine, but there was that "ghost’ snapd process running from the core snap that was reverted out.
I looked into this some more and created a reproducer in https://github.com/snapcore/snapd/compare/master...mvo5:core-revert-restarts?expand=1
It turns out we handle the “snap->snap” restart correctly, i.e. if a refresh from a core snap to a new core snap fails for some reason we correctly restart into the old one. However if there is no snap yet and we run from the deb, restart into the core and there is a failure there for some reason, then snapd will not restart itself into the old version.