Xpra: Ticket #786: remote logging for client

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.



Sun, 11 Jan 2015 09:15:39 GMT - Antoine Martin: attachment set

work in progress patch


Mon, 12 Jan 2015 07:05:03 GMT - Antoine Martin: owner changed

Done in r8436.

To use it:

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?


Sat, 24 Jan 2015 00:57:19 GMT - alas:

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__

Sat, 24 Jan 2015 03:55:14 GMT - Antoine Martin:

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


Sat, 21 Feb 2015 00:47:39 GMT - alas: owner changed

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.


Sat, 21 Feb 2015 01:57:10 GMT - alas:


Sat, 21 Feb 2015 05:44:53 GMT - Antoine Martin: owner changed

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.


Mon, 23 Feb 2015 18:47:40 GMT - alas: status changed; resolution set

Yup, r8689 does indeed fix that annoying little bit of output.

Closing.


Wed, 25 Feb 2015 05:19:55 GMT - Antoine Martin:

Also needed: r8698 to avoid errors when the connection is severed.


Sat, 28 Feb 2015 02:12:55 GMT - Antoine Martin:

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)


Thu, 18 Feb 2016 08:14:33 GMT - Antoine Martin:

Note: as of r11974 + r11977 we now log to "both" the client and server, by default, and on all platforms.


Sat, 23 Jan 2021 05:05:55 GMT - migration script:

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