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.
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".
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).
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=
?
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.
Unless you can give me steps to reproduce this bug in a standard stretch VM, I will have to close this as "needinfo".
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.
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.
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
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:
I am not sure how to compile xpra. Is there a guidance?
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.
I could reproduce the issue with VirtualBox?
My Debian Stretch VM already had 3D enabled.
Feel free to re-open if you can give me steps to reproduce.
Duplicate here: #2012, but also missing steps to reproduce...
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1880