xpra icon
Bug tracker and wiki

Opened 2 years ago

Closed 2 years ago

Last modified 16 months ago

#786 closed enhancement (fixed)

remote logging for client

Reported by: Antoine Martin Owned by: alas
Priority: major Milestone: 0.15
Component: core Version: trunk
Keywords: Cc:

Description

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.

Attachments (1)

remote-logging.patch (10.6 KB) - added by Antoine Martin 2 years ago.
work in progress patch

Download all attachments as: .zip

Change History (11)

Changed 2 years ago by Antoine Martin

Attachment: remote-logging.patch added

work in progress patch

comment:1 Changed 2 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas

Done in r8436.

To use it:

  • enable remote-logging on the server and client (it is disabled by default on Linux for now)
  • enable -d client on the server so all client logging will be shown
  • enable some logging on the client (to be able to test that it does work)

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?

comment:2 Changed 2 years ago by 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__

comment:3 Changed 2 years ago by 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..)

comment:4 Changed 2 years ago by alas

Owner: changed from alas to Antoine Martin

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.

comment:5 Changed 2 years ago by alas

  • Note - the "unicode" error mentioned above re-appeared when testing for #756 ... see comments there for details.

comment:6 Changed 2 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas

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.

comment:7 Changed 2 years ago by alas

Resolution: fixed
Status: newclosed

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

Closing.

comment:8 Changed 2 years ago by Antoine Martin

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

comment:9 Changed 2 years ago by 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)

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:10 Changed 16 months ago by Antoine Martin

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

Last edited 16 months ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.