xpra icon
Bug tracker and wiki

Opened 4 weeks ago

Last modified 3 weeks ago

#1880 new defect

Timeout disconnection after tty switch

Reported by: mviereck Owned by: mviereck
Priority: major Milestone: 2.4
Component: server Version: 2.3.x
Keywords: Cc:

Description

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.

Change History (6)

comment:1 Changed 4 weeks ago by Antoine Martin

Milestone: 2.4
Owner: changed from Antoine Martin to mviereck

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

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

comment:3 Changed 4 weeks ago by 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=?

comment:4 Changed 4 weeks ago by 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.

comment:5 Changed 3 weeks ago by 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".

comment:6 Changed 3 weeks ago by 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.

Note: See TracTickets for help on using tickets.