As reported in https://bugs.launchpad.net/snapd/+bug/1946656,
not-quite idle connections between subiquity and snapd are piling up and
causing issues when trying to restart subiquity. I don't really
understand why, but using a fresh session for each API access makes the
problem go away.
Splitting subiquity into server and client means that in general
old versions of the client can still be running when the server is
updated (the client running on tty1 will be restarted by snapd/systemd
when the snap is updated but clients running via e.g. ssh will not). I
implemented a way for the client to detect this and restart itself: the
server sets a header in all responses that indicates if it has been
updated. So far so good. But the way it knows that it has been updated
is to check the presence of a file that is only created when subiquity
itself triggers the refresh, so it's not there in the case of manual
refresh, and as reported in https://bugs.launchpad.net/bugs/1921820 this
can lead to the client crashing because it cannot parse the new server's
response. This simply changes to creating the marker file in the snap
post-refresh hook, which will be executed for manual snap refreshes as
well.
While I'm at it, remove the rest of the post-install hook that restarted
subiquity clients running on the serial line as the generic machinery
will work for these too.
Michael Hudson-Doyle