After trying a few things, I've been able to reproduce the crash. Whether the snap refresh occurred through a manual refresh or through subiquity screen does not seem to make a difference.
I believe that you can work around the issue and move forward with your testing by connecting again to the installer through SSH _after_ the refresh is finished (or use the client on /dev/tty1 is that is an option for you).
Please let me know otherwise, I can probably help find another way to do the testing.
Details and investigation:
-------------------------
It seems that after the snap refresh, the clients that were connected through SSH (or maybe other means?) don't reload properly.
In my example:
3447 is the version of the snap after refresh
3314 is the version of the snap before refresh
PID 2205 is the client running on /dev/tty/1
PID 2221 is the server (forked from the client running on /dev/tty/1 - I think)
PID 2242 is a client that has been connected through SSH since _before_ the refresh
PID 2431 is a client that connected through SSH _after_ the refresh
Looking at the environment for each client we have:
Hi Frank,
After trying a few things, I've been able to reproduce the crash. Whether the snap refresh occurred through a manual refresh or through subiquity screen does not seem to make a difference.
I believe that you can work around the issue and move forward with your testing by connecting again to the installer through SSH _after_ the refresh is finished (or use the client on /dev/tty1 is that is an option for you).
Please let me know otherwise, I can probably help find another way to do the testing.
Details and investigation: ------- ------- ----
-------
It seems that after the snap refresh, the clients that were connected through SSH (or maybe other means?) don't reload properly.
In my example:
3447 is the version of the snap after refresh
3314 is the version of the snap before refresh
$ pgrep -a python3 /3447/usr/ bin/python3. 8 /snap/subiquity /3447/usr/ bin/subiquity /3447/usr/ bin/python3. 8 -m subiquity. cmd.server /3447/usr/ bin/python3. 8 -m subiquity /3447/usr/ bin/python3. 8 -m subiquity
2205 /snap/subiquity
2221 /snap/subiquity
2242 /snap/subiquity
2431 /snap/subiquity
PID 2205 is the client running on /dev/tty/1
PID 2221 is the server (forked from the client running on /dev/tty/1 - I think)
PID 2242 is a client that has been connected through SSH since _before_ the refresh
PID 2431 is a client that connected through SSH _after_ the refresh
Looking at the environment for each client we have:
$ strings /proc/2205/environ | grep -e 3447 -e 3314 /snap/subiquity /3447/usr/ bin/python3. 8 DATA=/root/ snap/subiquity/ 3447 ROOT=/snap/ subiquity/ 3447 /var/snap/ subiquity/ 3447 snap/subiquity/ 3447 subiquity/ 3447 /snap/subiquity /3447/lib/ python3. 8/site- packages
PYTHON=
SNAP_USER_
SUBIQUITY_
SNAP_REVISION=3447
SNAP_DATA=
PWD=/var/
SNAP=/snap/
PYTHONPATH=
$ strings /proc/2242/environ | grep -e 3447 -e 3314 /snap/subiquity /3447/usr/ bin/python3. 8 DATA=/root/ snap/subiquity/ 3447 ROOT=/snap/ subiquity/ 3447 subiquity/ 3314/bin: /snap/subiquity /3314/usr/ bin:/usr/ local/sbin: /usr/local/ bin:/usr/ sbin:/usr/ bin:/sbin: /bin:/snap/ bin DATA_DIR= /snap/subiquity /3314/share/ apport /var/snap/ subiquity/ 3447 :/snap/ subiquity/ 3314/lib/ python3. 8/site- packages: /snap/subiquity /3447/lib/ python3. 8/site- packages subiquity/ 3447
PYTHON=
SNAP_USER_
SUBIQUITY_
SNAP_REVISION=3447
PATH=/snap/
APPORT_
SNAP_DATA=
PYTHONPATH=
SNAP=/snap/
$ strings /proc/2431/environ | grep -e 3447 -e 3314 /snap/subiquity /3447/usr/ bin/python3. 8 DATA=/root/ snap/subiquity/ 3447 ROOT=/snap/ subiquity/ 3447 /var/snap/ subiquity/ 3447 subiquity/ 3447 :/snap/ subiquity/ 3447/lib/ python3. 8/site- packages
PYTHON=
SNAP_USER_
SUBIQUITY_
SNAP_REVISION=3447
SNAP_DATA=
SNAP=/snap/
PYTHONPATH=
As shown above, 2242 ends up with a broken environment, making it mix up things from the old and new snap.
Thanks,
Olivier