Xpra: Ticket #1880: Timeout disconnection after tty switch

If I have an xpra client running on X and switch to another tty for more than 60s, and switch back to X, the server complains about a timeout and disconnects:

2018-06-18 23:31:32,958 Disconnecting client Protocol(unix-domain socket:/run/user/1000/xpra/debian9-100):
2018-06-18 23:31:32,959  client ping timeout (waited 60 seconds without a response)
2018-06-18 23:31:32,964 xpra client 1 disconnected.

I can see the client window for a short amount of time before it disappears. I assume the client cannot ping back because X is somehow "frozen" while I am using another tty. It should not be disconnected as it is innocent and I still want to use it.

Is there a way to disable the timeout check at all? I am periodically checking for running server and client myself.



Wed, 20 Jun 2018 05:41:44 GMT - Antoine Martin: owner changed; milestone set

I cannot reproduce, please provide more details as per wiki/ReportingBugs. The ping and echo packets are handled using a non-UI thread, which should not be blocked if the X11 server is somehow "frozen".


Wed, 20 Jun 2018 11:35:36 GMT - mviereck:

Sorry, here some more infos: xpra v2.4-r19642 on debian 9

Steps to reproduce:

Xvfb :50 +extension Composite +extension RANDR +extension RENDER +extension GLX +extension XTEST -screen 0 1920x1080x24 &
xpra start :50 --use-display --start-via-proxy=no --no-daemon &
xpra attach :50 &
DISPLAY=:50 xterm

Switch to another tty:

sleep 60

Switch back to X, get message about disconnection:

2018-06-20 13:20:55,230 Disconnecting client Protocol(unix-domain socket:/run/user/1000/xpra/debian9-50):
2018-06-20 13:20:55,230  client ping timeout (waited 60 seconds without a response)
2018-06-20 13:20:55,249 xpra client 1 disconnected.

xterm still runs on Xvfb / display :50, running xpra attach :50 shows xterm again.


(I just found that I have another issue if I don't use --use-display: After switching back to X, the whole display is black, but the mouse still works and shows changing cursors depending on invisible application in the black background, indicating that display and applications are still active. Display manager is sddm, desktop is xfce).


Wed, 20 Jun 2018 13:03:36 GMT - Antoine Martin:

I still cannot reproduce, I have tried it on Fedora 28 and Debian Stretch in a VM. I've automated the vt-switching with: sudo chvt 4;sleep 65;sudo chvt 2 since it's more difficult to use keyboard shortcuts in a VM.

I just found that I have another issue if I don't use --use-display: After switching back to X, the whole display is black

Please file a separate ticket. I have no idea why use-display would make any difference here: don't we just exec the same command? Have you tried specifying the same xvfb command with --xvfb=?


Wed, 20 Jun 2018 15:03:51 GMT - mviereck:

Have you tried specifying the same xvfb command with --xvfb=?

Same timeout issue with --xvfb instead of --use-display:

xpra start :51 --xvfb "/usr/bin/Xvfb :51 +extension Composite +extension RANDR +extension RENDER +extension GLX +extension XTEST -screen 0 1920x1080x24" --start-via-proxy=no --no-daemon &
xpra attach :51 &
DISPLAY=:51 xterm

Then switching to tty, sleep 60, switching back to X, as described above.

I've automated the vt-switching with: sudo chvt 4;sleep 65;sudo chvt 2 since it's more difficult to use keyboard shortcuts in a VM.

At least in Virtualbox you can switch tty with <CTRL-right><F1..12>. (The default hotkey for some Virtualbox actions is <Ctrl-right>).


For "whole display black" I'll open a separate ticket.


Mon, 25 Jun 2018 08:58:42 GMT - Antoine Martin:

Unless you can give me steps to reproduce this bug in a standard stretch VM, I will have to close this as "needinfo".


Mon, 25 Jun 2018 11:47:46 GMT - mviereck:

I did further tests on debian 9 host and in an ubuntu 18.04 VM.

I found the disconnection does not happen on debian 9 host if I run the client with --opengl=no, but it does with --opengl=yes.

I cannot reproduce it in ubuntu 18.04 VM, neither with --opengl=yes nor with --opengl=no.

It seems the issue needs a real GPU to be reproduced. On tty switch, DRM devices are released by X so they can be used by others. Applications using the GPU are stopped until X gets access to GPU again. This can be seen with glxgears running accelerated on host. Its output stops if switching to another tty and goes on after switching back to X.

I assume xpra client with --opengl=yes is "frozen" as a whole on tty switch, although the ping connection itself does not need the GPU.


Sat, 18 Aug 2018 14:35:36 GMT - Antoine Martin: owner, status changed

It seems the issue needs a real GPU to be reproduced.

Damn. I should be able to simulate this behaviour by forcing the UI thread to sleep for a couple of minutes.

On tty switch, DRM devices are released by X so they can be used by others. Applications using the GPU are stopped until X gets access to GPU again.

We have quite a bit of code for multiple platforms that tries to detect such cases (lock screen, power events, etc). We even have code that detects a stuck UI thread since macos suspends it when you use the global menu. (seemingly a problem with GTK rather than macos itself). This code may help: it can be used to tell the server that there is no point in sending more screen updates until the UI thread is resumed.


Sun, 19 Aug 2018 12:01:06 GMT - Antoine Martin: owner, status changed

We already have code to lockup the UI thread for testing (but you need the fix from r20119 to be able to use it):

XPRA_FAKE_UI_LOCKUPS=120000 xpra attach --no-mmap

This will lockup the UI thread for 2 minutes every 10 seconds. This doesn't cause any problems, so maybe this detection code is enough to fix things for you too?

Try applying r20119 (trivial) and start the client with:

XPRA_UI_THREAD_POLLING=1000 xpra attach

Tue, 21 Aug 2018 03:27:23 GMT - mviereck:

Try applying r20119 (trivial)

I am not sure how to compile xpra. Is there a guidance? Or can I apply the change without compiling?

It seems the issue needs a real GPU to be reproduced.

Damn.

I could reproduce the issue with VirtualBox. It has an option to enable 3D acceleration in guests. 3d acceleration is buggy and unuseable within VM here. But it somehow allows access to real GPU hardware, enough to run a test.

Steps to reproduce:


Tue, 21 Aug 2018 03:41:58 GMT - Antoine Martin:

I am not sure how to compile xpra. Is there a guidance?

wiki/Building

Or can I apply the change without compiling?

You can, it's one line. (just locate gobject_client_base.py)

I could reproduce the issue with VirtualBox?

I'll try if I can find the time.


Tue, 21 Aug 2018 06:53:29 GMT - Antoine Martin:

I could reproduce the issue with VirtualBox?

My Debian Stretch VM already had 3D enabled.


Tue, 25 Sep 2018 05:58:25 GMT - Antoine Martin: status changed; resolution set

Feel free to re-open if you can give me steps to reproduce.


Mon, 12 Nov 2018 13:15:42 GMT - Antoine Martin:

Duplicate here: #2012, but also missing steps to reproduce...


Sat, 23 Jan 2021 05:36:14 GMT - migration script:

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