xpra icon
Bug tracker and wiki

Opened 8 months ago

Closed 3 weeks ago

#2131 closed defect (fixed)

xpra client not timing out

Reported by: stdedos Owned by: stdedos
Priority: major Milestone: 2.5
Component: client Version: 2.4.x
Keywords: Cc:

Description

2019-02-01 14:04:09,233 Xpra shadow server version 2.5-r21480 64-bit
2019-02-01 14:04:09,234  running on Linux Ubuntu 16.04 xenial

and

2019-02-01 14:03:37,543 Xpra GTK3 client version 2.5-r21454 64-bit
2019-02-01 14:03:37,548  running on Microsoft Windows 10

xpra client is Xpra-Python3-x86_64_Setup_2.5-r21454.exe

The shadow session was (probably?) in some kind of limbo state; however, client didn't try to time it out.

Note: I am not entirely sure if these are the correct server file, since xpra is only archiving at most one backup. However, since it was the bigger file, I thought it might have been useful.

Server uses ethernet, client uses wi-fi, but they are "on the same network". Assume infinite bandwidth.

Attachments (4)

xpra-ticket-#2131.zip (53.9 KB) - added by stdedos 8 months ago.
Xpra_cmd_2019-02-01_15-12-57.png (42.2 KB) - added by stdedos 8 months ago.
xpra-py2
xpra-ticket-#2131-downgrade_pointer-issue.zip (279.5 KB) - added by stdedos 8 months ago.
Xpra_cmd_2019-01-22_13-44-17_pointer-offset.png (25.1 KB) - added by stdedos 8 months ago.

Download all attachments as: .zip

Change History (10)

Changed 8 months ago by stdedos

Attachment: xpra-ticket-#2131.zip added

Changed 8 months ago by stdedos

xpra-py2

comment:1 Changed 8 months ago by stdedos

It seems that xpra is not picking up... screenshot is from Xpra-x86_64_Setup_2.5-r21454 (again, same network).

I'll try to downgrade

Changed 8 months ago by stdedos

comment:2 Changed 8 months ago by stdedos

Even downgrading server to r20740 (xpra --version == v2.5-r21480) and xpra client to 2.5-r20836., still no dice.


Timeouts in older version get a bit "easier to handle" with clipboard=no, but they don't go away.


# * The offset on .0:0 could be explained that the (leftmost) screen is "smaller" than the other ones:

$  xrandr
Screen 0: minimum 8 x 8, current 5520 x 1080, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 connected primary 1680x1050+0+30 (normal left inverted right x axis y axis) 474mm x 296mm
   1680x1050     59.88*+  59.95  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94  
DP-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 connected 1920x1080+3600+0 (normal left inverted right x axis y axis) 527mm x 296mm
   1920x1080     60.00*+  59.94    50.00    60.05    60.00    50.04  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1280x720      60.00    59.94    50.00  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       59.94  
   640x480       75.00    59.94    59.93  
DP-1 connected 1920x1080+1680+0 (normal left inverted right x axis y axis) 527mm x 296mm
   1920x1080     60.00*+
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94 
Last edited 5 months ago by stdedos (previous) (diff)

comment:3 Changed 7 months ago by stdedos

I cannot do anything to kill the server with "normal commands", it gets into some kind of unresponsive state:

$ while ! xpra stop :0 ; do sleep 1 ; done
connection timed out
timeout: server did not disconnect us
connection timed out
timeout: server did not disconnect us
connection timed out
timeout: server did not disconnect us
connection timed out
timeout: server did not disconnect us
xpra initialization error:
cannot find live server for display :0
^C
$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
 DEAD session at :0 (cleaned up)
 LIVE session at :1
/run/xpra:
 DEAD session at :0 (cleaned up)
 LIVE session at :1

and client needs to be killed manually

comment:4 Changed 6 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

The offset thing belongs in a different ticket.

Timeouts in older version get a bit "easier to handle" with clipboard=no, but they don't go away.

This points towards a clipboard problem, this can only be solved properly by #812

Can you get the backtrace from a hung server? (see wiki/Debugging)

Unless I can reproduce this myself, I fear I may have to close this as 'needinfo'.

comment:5 Changed 5 months ago by Antoine Martin

#2247 is similar to this bug.

comment:6 Changed 3 weeks ago by stdedos

Resolution: fixed
Status: newclosed

Whatever it was, it hasn't happened again

Note: See TracTickets for help on using tickets.