remote logging for client

[totaam]

Issue migrated from trac ticket # 786

component: core | priority: major | resolution: fixed

2015-01-11 09:00:18: totaam created the issue

---

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.

[totaam]

2015-01-11 09:15:39: antoine uploaded file remote-logging.patch (10.6 KiB)

work in progress patch

[totaam]

2015-01-12 07:05:03: totaam changed owner from antoine to afarr

[totaam]

2015-01-12 07:05:03: totaam commented

---

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?

[totaam]

2015-01-24 00:57:19: afarr commented

---

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__

[totaam]

2015-01-24 03:55:14: totaam commented

---

I am noticing a regular bit of odd output server-side upon connection: unexpected data type in logging packet: <type 'unicode'>
[[BR]]
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)

[[BR]]
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..)

[totaam]

2015-02-21 00:47:40: afarr changed owner from afarr to totaam

[totaam]

2015-02-21 00:47:40: afarr commented

---

Re-tested (at last) with 0.15.0 8647 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.

[totaam]

2015-02-21 01:57:11: afarr commented

---

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

[totaam]

2015-02-21 05:44:53: antoine changed owner from totaam to afarr

[totaam]

2015-02-21 05:44:53: antoine commented

---

About the only way I can think of to improve it would be to enable server-side client debugging/logging output on the fly
[[BR]]
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.
[[BR]]
Yes, this belongs in this ticket.
I believe r8689 fixes this, if it does please close this ticket.

[totaam]

2015-02-23 18:47:41: afarr changed status from new to closed

[totaam]

2015-02-23 18:47:41: afarr set resolution to fixed

[totaam]

2015-02-23 18:47:41: afarr commented

---

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

Closing.

[totaam]

2015-02-25 05:19:56: antoine commented

---

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

[totaam]

2015-02-28 02:12:55: antoine commented

---

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)

[totaam]

2016-02-18 08:14:33: antoine commented

---

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