This one’s for @rustybird most probably. Usiing split-browser qube became my daily driver routine. Thanks a bunch for that! It works great with only 200MB of RAM!
But, from time to time I shut down split-browser qube, or restart it after update. After that if I do ALT+b in a dispVM which was started via split-browser qube prior to its shutdown/restart, it kills dispVM. Huge annoyance, and any help would be highly appreciated.
It’s intentional that Qubes kills a DisposableVM when its opener VM is shut down. What’s changed (in R4.1 I think) is that this doesn’t happen immediately, but only later if the DisposableVM tries to write some data to the opener VM over the original qrexec connection. E.g. when you press Alt-b, the DisposableVM writes a “bookmark this page” an “open the bookmarks list” request, Qubes notices that there’s no connection to write it to anymore, and… poof.
So the delay is a bug. OTOH it’s also an unintentional grace period in case the persistent VM was shut down accidentally. 
Thanks for your explanatory response, @rustybird. I just want to clarify this happens even when opener VM is restarted and up. Of course, because there’s no original qrexec connection anymore I guess. But, who will ever remember if opener VM which is up, was previously restarted or not, right?
While still don’t understand why non-existence of an original qrexec connection should produce dispVM’s killing, is it at least possible on such an event confirming dialog box to be pup-upped with an explanation that original qrexec connection cannot be found and that pressing “OK” will kill dispVM?
Did you mean here “CTRL+d”?
Thank you in advance.
Right, that “grace period” / footgun is not exactly intuitive. The previous R4.0-ish behavior of immediately killing the DisposableVM on opener shutdown was more obvious, so I’ve submitted Opener VM shutdown no longer kills DisposableVM (until it tries to write on the stale qrexec connection) · Issue #7693 · QubesOS/qubes-issues · GitHub
Unfortunately the disposable side doesn’t even know that the persistent side has (or had been) shut down. Only when it finally tries to write to it, that’s when it’s killed by Qubes OS.
Oops yes. Alt-b is the one where the DisposableVM writes an “open the bookmarks list” request.
Thanks rusty. We had similar situation with Qube Manager when trying to run non-existent command via context menu. As I see it now, it is fixed, and we have a dialog box informing us that “Command ‘xxx’ returned non-zero exit status 127” instead of killing Qube Manager.
Hopefully this will be fixed, and I don’t have a Github account for that…
Also, I’m not sure what do you mean with “grace period”. In my case dispVM vanishes immediately after pressing CTRL+d and I’m using fully updated Qubes R4.1.1, xen_version: 4.14.5 Linux 5.18.14-1.fc32.qubes.x86_64, and I’m not aware if it is relevant at all for my goal killing not to happen.
I just meant the time immediately after accidentally shutting down the persistent qube - as long as you then avoid pressing one of the hotkeys, you could theoretically use that time e.g. to finish filling out a form in an important browser tab.
(But as you said, it’s way too easy to lose track of having shut down the persistent qube. And it’s not intuitive that the hotkeys are destructive in this state.)