An alternative to #752: in a lot of cases, the end user runs the client and has no idea how to capture logs or even what a log file is...
So add a switch so we can automatically forward the client's log output to the server where it can more easily be collected, together with the server output.
work in progress patch
Done in r8436.
To use it:
remote-logging
on the server and client (it is disabled by default on Linux for now)
-d client
on the server so all client logging will be shown
To make it easier to turn debugging on and off client-side, I have added in r8439 the ability to control client debugging using the xpra control interface, ie:
xpra control :1 client debug enable clipboard
afarr: does that help? how can we make this more useful?
This is spectacular.
With remote-logging=yes -d client
enabled on the server, I am noticing a regular bit of odd output server-side upon connection: unexpected data type in logging packet: <type 'unicode'>
At one point, while passing the session back and forth between an osx to a windows client I also saw a strange bit of output (possibly related to forcing --opengl=on
on the osx client with an intel graphics card to also test the opengl paint boxes?):
2015-01-23 14:14:41,580 do_paint_rgb24 error 2015-01-23 14:14:41,580 File "xpra\client\window_backing_base.pyc", line 271, in do_paint_rgb24 2015-01-23 14:14:41,580 File "xpra\client\gl\gl_window_backing_base.pyc", line 546, in _do_paint_rgb24 2015-01-23 14:14:41,581 File "xpra\client\gl\gl_window_backing_base.pyc", line 580, in _do_paint_rgb 2015-01-23 14:14:41,581 File "xpra\client\gl\gtk_compat.pyc", line 91, in __enter__
I am noticing a regular bit of odd output server-side upon connection:
unexpected data type in logging packet: <type 'unicode'>
Odd, I don't see this here when I connect with any client OS, so I've added more debug for this in r8535 - hopefully we can figure out what it is and get it forwarded properly.
What happens is that we're trying to send a log event to the server, it fails to get encoded, and we send this warning instead... (good thing that I've added a lock to prevent logging errors from endlessly recursing on such errors)
As for the do_paint_rgb24 error
, I think that what may be happening is that we're in the process of painting to a window backing store as the client is cleaning up from another thread (a bit like #582 and #626), and so it fails to setup the paint context. r8536 tries to ignore such cases, but this is a bit of band aid rather than a proper fix.. In any case, I don't think this is critical and it should be quite a rare occurrence.
It may be easier to reproduce with fast updating windows like glxgears, and stealing the session (or control-C it may also be able to trigger it). But probably not worth spending too much time on (very hard to prove that something that is hard to reproduce no longer does..)
Re-tested (at last) with 0.15.0 r8647 windows client against 0.15.0 r8661 fedora 20 server. Looks excellent.
About the only way I can think of to improve it would be to enable server-side client debugging/logging output on the fly... xpra control enable remote-logging
- but that might be asking for crazytalk.
Assuming that's not workable (and that if it were you would have enabled it from the start), I think this ticket is ready for a closing.
About the only way I can think of to improve it would be to enable server-side client debugging/logging output on the fly
That would be doable, the only problem is that the config option is currently a boolean (just on or off), so this would need to be changed to something else.
We can revisit this later if needed.
Note - the "unicode" error mentioned above re-appeared when testing for #756 ... see comments there for details.
Yes, this belongs in this ticket.
I believe r8689 fixes this, if it does please close this ticket.
Yup, r8689 does indeed fix that annoying little bit of output.
Closing.
Also needed: r8698 to avoid errors when the connection is severed.
Reported in #817 TypeError: standard_logging() takes at least 3 arguments (2 given)
, this should be fixed in r8714.
Note: this is a problem in the error handling code for remote logging, so we will still need to deal with the underlying error when we actually see it... (it will show up in the client log as of r8715, together with the exception)
Note: as of r11974 + r11977 we now log to "both" the client and server, by default, and on all platforms.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/786