Xpra: Ticket #2199: Expose all "critical" server issues to the client

Based on #2198, as a user I'd like to know:

There are multiple times that I am trying to connect, or start an application, and I don't know "the current state of affairs".



Sat, 09 Mar 2019 12:50:42 GMT - Antoine Martin: owner, type, milestone changed

When xpra has "finished" whatever it is doing in start / shadow

by definition, clients are not connected until the server has finished starting up - so how can the server tell the clients anything? FYI: we already have dbus signals for the main server events (ie: startup-complete)

Whether xpra thinks it succeeded or failed.

Do you mean those --start= commands? We don't always know their status. Some commands will exit with an error code, others not. How would you tell the client(s)?

If it failed, forward the whole message to the client.

Generally, the message is printed to stdout. We don't want to capture those.


Sat, 09 Mar 2019 13:32:04 GMT - stdedos:

Replying to Antoine Martin:

Whether xpra thinks it succeeded or failed.

Do you mean those --start= commands? We don't always know their status. Some commands will exit with an error code, others not. How would you tell the client(s)?

In #2198's case it sounds easy: Probably command exited with non-zero status, it had some std(out|err), and the child has died "too fast"

If it failed, forward the whole message to the client.

Generally, the message is printed to stdout. We don't want to capture those.

Since it already comes, isn't it possible to somehow forward it? :/

I was wondering how did the message ended up like that (i.e. no timestamp):

2019-03-08 14:46:04,955 New unix-domain connection received on /run/xpra/user-precision-t3620-50
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.Terminal exited with status 10
2019-03-08 14:46:05,033 New unix-domain connection received on /run/user/1000/xpra/user-precision-t3620-50

Tue, 19 Mar 2019 09:25:51 GMT - stdedos: owner changed


Tue, 19 Mar 2019 09:26:17 GMT - stdedos: owner changed


Wed, 24 Apr 2019 13:16:42 GMT - stdedos:

#2283 is a nice example where I'd prefer "not" to wait for the timeout to find that the session crashed (or how it crashed)


Sat, 23 Jan 2021 05:44:50 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2199