Opened 23 months ago
Last modified 21 months ago
#2199 new enhancement
Expose all "critical" server issues to the client
Reported by: | stdedos | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | future |
Component: | android | Version: | 2.4.x |
Keywords: | Cc: |
Description
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".
Change History (5)
comment:1 follow-up: 2 Changed 23 months ago by
Milestone: | 2.5 → future |
---|---|
Owner: | changed from Antoine Martin to stdedos |
Type: | defect → enhancement |
comment:2 Changed 23 months ago by
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
comment:3 Changed 22 months ago by
Owner: | changed from stdedos to Martin |
---|
comment:4 Changed 22 months ago by
Owner: | changed from Martin to Antoine Martin |
---|
comment:5 Changed 21 months ago by
#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)
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
)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)?
Generally, the message is printed to stdout. We don't want to capture those.