I investigated the issue and managed to reproduce it once on amd64.

So this isn't strictly specific to riscv but only seems to occur if two
or more Subiquity clients run.

When testing on riscv, I get a subiquity client for serial and another
for the tty.

The --serial option of kvm-test allows having the same in amd64.


Observed behavior
-----------------
* A newly spawned client failed with ServerDisconnectedError right after a 
refresh.


* After refresh, I found 3 different server log files (and only expected two - 
one before refresh, and one after).
  lrwxrwxrwx 1 root root     31 Mar 26 16:53 subiquity-server-debug.log -> 
subiquity-server-debug.log.2342
  -rw------- 1 root root 134897 Mar 26 16:53 subiquity-server-debug.log.1716
  -rw------- 1 root root  26125 Mar 26 16:53 subiquity-server-debug.log.2240
  -rw------- 1 root root  45629 Mar 26 17:13 subiquity-server-debug.log.2342

* The hierarchy of processes also showed some inconsistency. Process
2240 was supposedly a server process (see above) but is now showing as a
shell process (which spawned a server).

   2204 root        20   0  2888  1816  1700 S   0.0  0.0  0:00.05 `- /bin/sh 
/snap/subiquity/7147/usr/bin/subiquity-server
   2240 root        20   0  2888  2036  1924 S   0.0  0.0  0:02.00 |  `- 
/bin/sh /snap/subiquity/7147/usr/bin/subiquity-server
   2342 root        20   0  392M 88488 21476 S   0.0  1.1  0:01.85 |     `- 
/snap/subiquity/7147/usr/bin/python3.12 -m subiquity.cmd.server


Explanation
-----------

* Server process 1716 was the server process before refresh
* Server process 2240 was the new server process after refresh. But it somehow 
was forced to restart and ended up executing os.execvp(["snap", "run", 
"subiquity-server"])
   * as a consequence, it "turned" into the "snap" process, and in turn ended 
up spawning yet another server process (i.e., PID 2342)


Why server 2240  was forced to restart?
---------------------------------------

* it turned out that GET refresh/progress?change_id="x" causes a server
restart if change x is a snap change ID in the "Done" state.

https://github.com/canonical/subiquity/blob/e422d4239fdc2491b3808e63bf77f165276c53a1/subiquity/server/controllers/refresh.py#L225-L242


[...]
2026-03-26 16:53:47,074 DEBUG 
curtin.reporting.start.subiquity/Refresh/progress_GET:45 start: 
subiquity/Refresh/progress_GET: 
2026-03-26 16:53:47,074 DEBUG subiquity.common.api.server:83 /refresh/progress 
waiting on start
[...]
2026-03-26 16:53:47,724 DEBUG subiquity.common.api.server:85 /refresh/progress 
resuming

* One of the clients likely didn't stop immediately upon refresh, and
ended sending a /refresh/progress query to the newly created server
process - triggering a restart.

* In the meantime, a newly created client crashed because the server
decided to restart.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2146422

Title:
  Installer UI crashed with ServerDisconnectedError

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/2146422/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to