Communicate failure of GUI connection

[meithecatte]

This is a follow-up to #8060 – when qubes-gui or Xorg fail, the symptoms to the user are "the VM is not responding to my request to start applications". I believe we should pop up a notification in this case, to make diagnosing the issue easier.

As I've mentioned in #8060, I see two general approaches to this problem:

1. Pop up a notification when the user tries to do something that requires a GUI connection, and the connection is broken. I believe all cases go through the qubes.StartApp RPC. We could
   • hardcode a check for this particular RPC, or
   • make it configurable in a manner similar to the RPC policy mechanism, or
   • expose another knob at the RPC call, or
   • there is already a gui flag here, perhaps we could add functionality to that
2. Display a warning icon, with a tooltip explaining the situation, in the domain tray (similar to "has updates available" or "needs to be restarted to apply updates").

[DemiMarie]

1. I believe all cases go through the qubes.StartApp RPC.

This is incorrect: whether or not GUI communication is required is determined by configuration under /etc/qubes/rpc-config/.

[marmarek]

Note that many qrexec services will first wait for X server startup. In most cases it's done via wait-for-session=1 in /etc/qubes/rpc-config/<service-name> (for example qubes.StartApp here). This will wait for qubes-session startup indefinitely, so from dom0 point of view, it isn't really different from "application is still starting". This need fixing in the first place. Only then you can think of how to show this failure to the user.

The waiting is done by calling /etc/qubes-rpc/qubes.WaitForSession (it is called as a separate qrexec service in some cases too). Currently it waits for qrexec-fork-service (which is started from qubes-session when it's done). I guess that needs handling failed qubes-gui-agent service and abort?

[andrewdavidwong]

Note that many qrexec services will first wait for X server startup. In most cases it's done via wait-for-session=1 in /etc/qubes/rpc-config/<service-name> (for example qubes.StartApp here). This will wait for qubes-session startup indefinitely, so from dom0 point of view, it isn't really different from "application is still starting". This need fixing in the first place. Only then you can think of how to show this failure to the user.

Sounds like we need a separate issue for this bug. Does one already exist? (My search didn't turn up anything, but I probably don't understand it well enough to run a really thorough search.)