Expose all "critical" server issues to the client

[stdedos]

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

• When xpra has "finished" whatever it is doing in start / shadow
• Whether xpra thinks it succeeded or failed.
• If it failed, forward the whole message to the client.

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

[Antoine Martin]

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.

[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

[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)