xpra icon
Bug tracker and wiki

Opened 3 weeks ago

Closed 3 days ago

Last modified 3 hours ago

#1998 closed defect (needinfo)

xpra stop all does not stop all

Reported by: stdedos Owned by: stdedos
Priority: minor Milestone: 2.5
Component: server Version: 2.4.x
Keywords: Cc:

Description

$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
	LIVE session at :3
	LIVE session at :4
	LIVE session at :5
	LIVE session at :6
$ xpra stop all
Trying to stop 3 displays:
 :4, :5, :6
xpra initialization error:
 failed to connect to '/run/user/1000/xpra/sntentos-precision-t3620-5':
 [Errno 11] Resource temporarily unavailable
xpra initialization error:
 cannot find live server for display :4
$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
	DEAD session at :3 (cleaned up)
	DEAD session at :4 (cleaned up)
	DEAD session at :5 (cleaned up)
	LIVE session at :6
$ connection timed out
timeout: server did not disconnect us
^C
$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
	LIVE session at :6

Attachments (2)

xpra-run.tbz2 (12.5 KB) - added by stdedos 3 weeks ago.
trac_1998_new-instance.zip (63.5 KB) - added by stdedos 18 hours ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 3 weeks ago by stdedos

Then again, sometime later:

$ xpra stop all
No xpra sessions found
$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
	DEAD session at :6 (cleaned up)

Seems to clean them up

comment:2 Changed 3 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

xpra stop all just runs xpra stop NN on each display it finds.

So the only potential bugs that I see here are:

  • after calling stop, the socket is left behind and xpra list cleans it up
  • stopping :6 failed

Both work fine here and I don't see any steps to reproduce.
How do I start those sessions? What state are they in?
Can you call xpra info on the ones that are in the "wrong" state?

comment:3 Changed 3 weeks ago by stdedos

They are sessions from #1997 ticket, so commands were:

$ xpra start ssh://sntentos@localhost --start-child=gnome-terminal --terminate-children=yes --exit-with-children=yes
$ xpra --ssh='ssh -x' start ssh://sntentos@localhost --start-child=gnome-terminal


However, brute-forcing the server with xpra start ... miraculously fixed the issue, and I cannot replicate the state of the sessions. I didn't think of collecting xpra-info preemptively (since I expected xpra stop all to collect them)

If there is anything useful, it's on the attachment. I included everything in there; you might want to check only :3-:6


Maybe this could fail a bit faster? Or assume ':\d+'?

$ xpra info 7
xpra initialization error:
 unknown format for display name: 7

Changed 3 weeks ago by stdedos

Attachment: xpra-run.tbz2 added

comment:4 Changed 3 days ago by Antoine Martin

Resolution: needinfo
Status: newclosed

Maybe this could fail a bit faster? Or assume ':\d+'?

See #2031

Closing, feel free to re-open if you can provide steps to reproduce.

comment:5 Changed 18 hours ago by stdedos

I do not have much more information to add on how to replicate it.
It seems to be related to whatever is causing the "new replication" of #2011

I am attaching (almost) the same diagnostics from #2011, and also the commands ran during this.

Note that clipboard sync was on

Changed 18 hours ago by stdedos

Attachment: trac_1998_new-instance.zip added

comment:6 Changed 17 hours ago by stdedos

More discrepancies (no xpra info, however :/)

$ xpra shadow -d encoding,bandwitdh :0
using systemd-run to wrap 'shadow' server command
'systemd-run' '--description' 'xpra-shadow' '--scope' '--user' '/usr/bin/xpra' 'shadow' '-d' 'encoding,bandwitdh' ':0' '--systemd-run=no'
Running scope as unit run-r3e763248a434434b9b82510637a3cdd1.scope.
Entering daemon mode; any further errors will be reported to:
  /run/user/1000/xpra/:0.log
(killed server from the client)
$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
	DEAD session at :0 (cleaned up)
	LIVE session at :2
/run/xpra:
	LIVE session at :0
	LIVE session at :2
$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
	LIVE session at :2
/run/xpra:
	LIVE session at :0
	LIVE session at :2
$ xpra stop :0
xpra initialization error:
 failed to connect to '/run/xpra/sntentos-precision-t3620-0':
 [Errno 11] Resource temporarily unavailable
$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
	LIVE session at :2
/run/xpra:
	DEAD session at :0 (cleaned up)
	LIVE session at :2

Last edited 17 hours ago by stdedos (previous) (diff)

comment:7 Changed 5 hours ago by Antoine Martin

More discrepancies (no xpra info, however :/)

No server log?

comment:8 in reply to:  7 Changed 3 hours ago by stdedos

Replying to Antoine Martin:

More discrepancies (no xpra info, however :/)

No server log?

No :/ I started killing it before of thinking to collect xpra info.

I assumed it would give the same as trac_1998_new-instance.zip/xpra-info-1.log:

$ xpra info :1
xpra initialization error:
 failed to connect to '/run/xpra/sntentos-precision-t3620-1':
 [Errno 11] Resource temporarily unavailable

$ xpra stop :1
xpra initialization error:
 cannot find live server for display :1

$ xpra info :1
xpra initialization error:
 cannot find live server for display :1

after having it killed from the client; hence I didn't try collecting.


You can see that the problem in:

$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
	DEAD session at :0 (cleaned up)
	LIVE session at :2
/run/xpra:
	LIVE session at :0
	LIVE session at :2

is not in the:

Found the following xpra sessions:
/run/user/1000/xpra:
	DEAD session at :0 (cleaned up)
	LIVE session at :2

but in the:

/run/xpra:
	LIVE session at :0
	LIVE session at :2
Note: See TracTickets for help on using tickets.