-
-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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,screen The 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 seconds Also: 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.log Never 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: