Recovering/reconnecting to existing sessions #3088
Comments
|
My .Xauthority looks parseable: but a lot of entries 😕 Does xpra have enough time to try them all out? (ofc I have |
|
Hmmm .... $ ps faux | grep -i xvfb
u 13488 0.0 0.2 1738464 172932 ? Ssl Απρ08 0:00 \_ Xvfb-for-Xpra-:2 +extension GLX +extension Composite -screen 0 8192x4096x24+32 -nolisten tcp -noreset -auth /run/user/1000/gdm/Xauthority -dpi 96 :2
u 15797 0.6 0.3 1787812 222836 ? Sl Απρ08 34:39 \_ Xvfb-for-Xpra-S15793 +extension GLX +extension Composite -screen 0 8192x4096x24+32 -nolisten tcp -noreset -auth /run/user/1000/gdm/Xauthority -dpi 96 -displayfd 6
u 272754 0.7 0.6 2213988 443464 ? Ssl Απρ09 32:57 Xvfb-for-Xpra-:4 +extension GLX +extension Composite -screen 0 8192x4096x24+32 -nolisten tcp -noreset -auth /home/u/.Xauthority -dpi 96 :4
u 2923724 0.0 0.0 11448 668 pts/33 S+ 09:23 0:00 \_ grep --color=auto -i xvfb
u 366252 0.0 0.3 1798980 234328 ? Ssl Απρ09 0:39 Xvfb-for-Xpra-:5 +extension GLX +extension Composite -screen 0 8192x4096x24+32 -nolisten tcp -noreset -auth /home/u/.Xauthority -dpi 96 :5
$ ls -alh /run/user/1000/gdm/Xauthority
-rw------- 1 u u 274 Απρ 8 16:06 /run/user/1000/gdm/Xauthority |
|
This may help:
|
|
Awesome, thank you 😀; however, no screens to try it out right now |
|
|
Also, something decided to kill the |
Do you mean the xpra socket or the X11 socket?
Why did it do that? Was the socket dead? Did you instruct it to do so? (ie:
In the end,
Sorry about that. As per above, |
xpra socket, idk anything about the X11
No, I just did
I have no idea 😕. And, since I was not expecting such a quick response, I just patiently typed
The only data I have is: Logs:
Actions:
|
|
I know it sounds funny, but can I "somehow" attempt to authorise with "all the available X11 credentials and methods" to some leftover display? I don't understand how it is possible that the server can start&connect, but after a few days it cannot re-connect. Can the xpra server dump its credentials somewhere, and me try to manually ping the server with those? |
|
For the shadow server #3077 (comment), the problem is much more obvious. .... ...... ........ The display is not at :0 😱, but DISPLAY is at :1 |
This can happen if the Tested using: xpra start :10 --no-daemon -d server,screen
sleep 10
xpra exit
xauth remove :10
#this will now fail:
DISPLAY=:10 xterm
#but xpra will re-add the xauth entry and succeed:
xpra start :10 --no-daemon -d server,screenThe server will rescue this display despite not being able to access it initially. |
|
|
It seems that It seems that terminal tabs "after some time" (after the first spinner?) degenerate to that state. |
After recovery I get "This server does not provide start menu data" 😒 |
I don't! (what a suprise..) xpra start :10
sleep 5;
xpra exit
xpra displays
xpra recover -d exec
sleep 5;
xpra info :10 | grep commands.start-menu |
|
Fun fun fun fun ... I'll try to fake (?) upgrade the server tomorrow. |
|
Well, I can tell you for a fact that u@h:~$ bat /run/user/1000/xpra/display-\:2-20210507-141812.log
2021-05-07 14:18:12,379 created unix domain socket '/run/user/1000/xpra/u-h-2'
2021-05-07 14:18:12,380 created unix domain socket '/run/xpra/u-h-2'
2021-05-07 14:18:12,380 created unix domain socket '/home/u/.xpra/u-h-2'
2021-05-07 14:18:12,422 pointer device emulation using XTest
2021-05-07 14:18:12,501 serving html content from '/usr/share/xpra/www'
2021-05-07 14:18:12,512 xvfb pid=2980708
2021-05-07 14:18:12,513 Warning: no window manager found
2021-05-07 14:18:12,513 on display :2 using EWMH window 0x2a00005
2021-05-07 14:18:12,513 Error: xpra server not found
u@h:~$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
UNKNOWN session at :2
/run/xpra:
UNKNOWN session at :2
/home/u/.xpra:
UNKNOWN session at :2
Re-probing unknown sessions in: /home/u/.xpra, /run/xpra, /run/user/1000/xpra
^C
caught KeyboardInterrupt(), exiting
u@h:~$ xpra recover
No dead displays found, see 'xpra displays'
u@h:~$ xpra recover :2 |
|
Ah, reproduced. Much fixings needed here. |
|
|
Hopefully everything is fine now 😄 Can't wait for Monday (for a change 😝) |
|
It's even worse now. I don't honestly know why would xpra "decide" it's "okay" to kill the xvfb 😕 |
It's not. And it doesn't for me. |
#3088 (comment) + the log above (after
Well - right now I am just doing it; hopefully, you'll be able to fix it before I actually need it (and it blows up my xvfb out of the blue).
(as above)
Yes (as above). It did detect the |
That's odd because it should now be impossible to have the dead sockets by running |
|
Whenever you are ready, I can |
You can try now.. but maybe not with a critical session just yet? |
|
The sessions seem to be upgradeable now 😕 (and have a Start menu) I don't know how to try recover at this state. |
You can use #3088 (comment) or forcibly kill the xpra server process with a |
|
Also ... I'm not gonna complain again about it; however: Can plain |
|
|
As of 117eb76, it does.
The only way |
Weeeeeeeeeeeeeeeeeell, I kinda disagree - I ran
Awesome - just the way I like it (I imagined it as |
|
Phew .... glad to have put this behind us 😅 |
And proof: u@h:~$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
UNKNOWN session at :2
LIVE session at :9
/run/xpra:
UNKNOWN session at :2
LIVE session at :9
/home/u/.xpra:
UNKNOWN session at :2
LIVE session at :9
Re-probing unknown sessions in: /run/xpra, /home/u/.xpra, /run/user/1000/xpra
^C
caught KeyboardInterrupt(), exiting
u@h:~$ xpra recover
Recovering display ':9' as a seamless server
Entering daemon mode; any further errors will be reported to:
/run/user/1000/xpra/display-:9-20210512-100336.log
u@h:~$ tail -17 /run/user/1000/xpra/display-\:9-20210512-100032.log
2021-05-12 10:00:35,907 xpra X11 seamless version 4.2-r29074 (g5db0de9cc) 64-bit
2021-05-12 10:00:35,908 uid=1000 (u), gid=1000 (u)
2021-05-12 10:00:35,908 running with pid 1021030 on Linux Ubuntu 20.04 focal
2021-05-12 10:00:35,912 connected to X11 display :9 with 24 bit colors
2021-05-12 10:03:37,064 Lost WM selection ManagerSelection(WM_S0), exiting
2021-05-12 10:03:37,064 xpra X11 seamless server is exiting
2021-05-12 10:03:37,064 Disconnecting client /run/xpra/u-h-9:
2021-05-12 10:03:37,064 server upgrade
2021-05-12 10:03:37,066 xpra client 1 disconnected.
2021-05-12 10:03:37,081 stopping pulseaudio with pid 1021145
2021-05-12 10:03:37,185 removing private directory '/run/user/1000/xpra/pulse-9'
2021-05-12 10:03:37,187 upgrading: not cleaning up Xvfb
/usr/lib/python3/dist-packages/gi/overrides/Gtk.py:1632: Warning: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
return _Gtk_main(*args, **kwargs)
2021-05-12 10:03:37,243 started command 'bash -c xpra id "${DISPLAY}" | grep session-type= | cut -d = -f 2 | grep -qP "shadow" || exit 0 ; env DBUS_SESSION_BUS_ADDRESS="$(cut -f 2- -d= "${XDG_RUNTIME_DIR}/dbus-session")" gnome-screensaver-command -l' with pid 1025423
server socket for display :9 is in UNKNOWN state
waiting up to 20 secondsAlso: Can you now recover displays on attach? And since I've remembered: Can you block |
|
Oh ... and yet-another-funny thing: u@h:~$ xpra recover
Recovering display ':9' as a seamless server
Entering daemon mode; any further errors will be reported to:
/run/user/1000/xpra/display-:9-20210512-100336.logNever had it ever recovered the |
Not for me:
It does not try to recover a display that is shown as
I guess we could. Maybe a new subcommand could be added to mean I want to see this display, do whatever is needed to let me see it (ie: start a shadow server if you have to, recover a seamless server if you have to, etc)
As per above, that is already the case. Only
It would if you let |
From #3077 (comment):
The text was updated successfully, but these errors were encountered: