xpra icon
Bug tracker and wiki

Opened 5 months ago

Closed 2 months ago

Last modified 9 days ago

#1880 closed defect (needinfo)

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 (13)

comment:1 Changed 5 months 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 5 months 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 5 months 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 5 months 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 5 months 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 5 months 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.

comment:7 Changed 3 months ago by Antoine Martin

Owner: changed from mviereck to Antoine Martin
Status: newassigned

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.

comment:8 Changed 3 months ago by Antoine Martin

Owner: changed from Antoine Martin to mviereck
Status: assignednew

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

comment:9 Changed 3 months ago by 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:

  • Within 3d accelerated VM: Run xpra server and client with glxgears. (Terminal output of glxgears should show a framerate matching your monitor if it succeeds to access GPU.)
  • On host: Switch to tty, wait a minute.
  • Switch back to X with VM. xpra server disconnects due to timeout.
Last edited 3 months ago by Antoine Martin (previous) (diff)

comment:10 Changed 3 months ago by 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.

comment:11 Changed 3 months ago by Antoine Martin

I could reproduce the issue with VirtualBox?

My Debian Stretch VM already had 3D enabled.

Last edited 3 months ago by Antoine Martin (previous) (diff)

comment:12 Changed 2 months ago by Antoine Martin

Resolution: needinfo
Status: newclosed

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

comment:13 Changed 9 days ago by Antoine Martin

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

Note: See TracTickets for help on using tickets.