While I was debugging the issue yesterday, I figured I'd update my Xorg X server to the latest version, 1.20.1. This seems to have broken things when loading the Xdummy module, as the ABI versions no longer match.
Is the dummy_drv part of Xpra? Is there a possibility for this to be updated? For now I just rolled back to X server 1.19.6 and everything works. [904276.126] (II) LoadModule: "glx" [904276.130] (II) Loading /home/tools/lib/xorg/modules/extensions/libglx.so [904276.155] (II) Module glx: vendor="X.Org Foundation" [904276.155] compiled for 1.19.6, module version = 1.0.0 [904276.155] ABI class: X.Org Server Extension, version 10.0 [904276.155] (II) LoadModule: "dummy" [904276.162] (II) Loading /home/tools/lib/xorg/modules/drivers/dummy_drv.so [904276.162] (II) Module dummy: vendor="X.Org Foundation" [904276.162] compiled for 1.19.6, module version = 0.3.8 [904276.162] Module class: X.Org Video Driver [904276.162] ABI class: X.Org Video Driver, version 23.0 [904276.162] (WW) dummy: module ABI major version (23) doesn't match the server's version (24) *So, I installed the latest MS Windows beta and explicitly used paramiko as the ssh client. This solved my issue and can now connect to my Xpra server running on Linux*. This was not an issue in Xpra 2.2, so I imagine something in 2.3 changed the way it interfaces with the shell? Thanks, Ben On Wed, Aug 29, 2018 at 10:27 AM Ben Sferrazza <[email protected]> wrote: > > > On Tue, Aug 28, 2018 at 8:42 PM Antoine Martin <[email protected]> > wrote: > >> On 29/08/18 03:23, Ben Sferrazza via shifter-users wrote: >> > Hi. I'm including my previous correspondence below, as it will at least >> > offer some history about my setup and prior issues. >> > >> > I stopped using Xpra a few months ago due to numerous bugs that made it >> > unusable (this is using a Linux server and Windows client). >> > >> > 1. windows get stuck with on-top focus >> Which windows from which applications? >> > 2. disappearing mouse cursor when using X11-only no-toolkit apps that >> use >> > inverted black mouse pointer after clicking on something >> Do you have a specific application we can use to reproduce the problem? >> > 3. some windows don't show window bar until resized (e.g. gvim always >> gets >> > placed in upper-left without window bar) >> Some applications do weird things with their geometry sometimes, gvim is >> one of those. That said, I've just tried it and it worked fine and it >> does seem to request to be placed in the top left corner. >> Please provide more details so we can reproduce the window bar problem. >> (ie: server os and version, gvim version, etc..) >> > 4. dialog box black bars (appears to be trying to add scrollbars?). >> Can you provide example applications we can use to reproduce the problem? >> I've never seen that anywhere except when X11 windows are smaller than >> the minimal window size on mswindows, then we have to pad it with >> something. >> > 5. windows are all blank (white) when returning into work after several >> > hours (requires restarting client) >> That's a known "feature" of some opengl drivers, they clear the video >> memory when the system goes into idle or suspended state. >> We try to detect that (slowing down the refresh rate) and then refresh >> the screen when the session resumes, but that doesn't always fix things. >> You should not need to restart the client: minimizing the windows and >> restoring them should be enough. >> Alternatively, turn off opengl in the client - the client performance >> will be much lower. >> > 6. flickering clipboard icon in systray >> That's a very obvious sign that something is not right and something is >> constantly requesting the clipboard contents. This will cause >> unnecessary traffic and instability. Try to figure out what is causing >> this and stop it. Usually, this is caused by clipboard managers or other >> clipboard synchronization tools (synergy, virtualbox, etc). >> > > I'll certainly provide you with more details once I'm re-connected using > Xpra 2.3.3, and we can hopefully debug the issues I was experiencing. > > >> > I'm inclined to give Xpra another chance, with the newer versions, and >> can >> > hopefully provide actual debugging log information for these bugs to be >> > fixed (if they haven't already). >> Bugs that are reproducible are usually fixed pretty quickly. >> Unfortunately, I have not seen any of the problems you have reported >> above, so the chances that newer versions have already fixed those >> issues are slim. >> For more generic bug reporting and debugging guidelines, see: >> https://xpra.org/trac/wiki/ReportingBugs >> >> > But I'm now not even able to connect to the server from the client using >> > version 2.3.3. It reports Connection Lost immediately. I can ssh into >> the >> > same host without issue. And have made sure that the shell rc file no >> > longer outputs anything, which was the source of my issue a few months >> ago. >> > I have included the relevant sections of the server log and client log >> > below. >> >> > >> > *Server Log:* >> (..) >> > 2018-08-28 18:44:12,059 add_process(<subprocess.Popen object at >> > 0x2b6cf2e9eb10>, xterm, ['xterm'], True, False) pid=17703 >> > 2018-08-28 18:44:12,059 xpra is ready. >> (..) >> > 2018-08-28 18:44:12,067 251.9GB of system memory >> For real? >> > > It's a 48-core server here at work. > > >> (..) >> > 2018-08-28 18:44:12,119 setup() hints={'base-size': (4, 4), >> 'minimum-size': >> > (10, 17), 'gravity': 1, 'increment': (6, 13), 'size': (484, 316)} >> > size=484x316 >> (..) >> > 2018-08-28 18:44:12,308 updateprop(title, ~) previous value=xterm >> Nothing after that which means that the server never received a >> connection from the client. >> >> >> > *Client Log:* >> (..) >> > 2018-08-28 11:37:55,166 poll() procinfo list: [ProcInfo({'returncode': >> > None, 'name': 'ssh', 'process': <subprocess.Popen object at >> > 0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True, >> > 'callback': None, 'command': ['plink', '-ssh', '-agent', '-l', >> > 'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra >> initenv;if >> > [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x >> > $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra >> > _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy >> :100;elif [ >> > -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo >> > "no run-xpra command found"; exit 1; fi'], 'forget': False})] >> > 2018-08-28 11:37:57,167 poll() procinfo list: [ProcInfo({'returncode': >> > None, 'name': 'ssh', 'process': <subprocess.Popen object at >> > 0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True, >> > 'callback': None, 'command': ['plink', '-ssh', '-agent', '-l', >> > 'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra >> initenv;if >> > [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x >> > $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra >> > _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy >> :100;elif [ >> > -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo >> > "no run-xpra command found"; exit 1; fi'], 'forget': False})] >> > 2018-08-28 11:37:58,987 read_parse_thread_loop starting >> > 2018-08-28 11:37:58,987 read thread: eof >> (..) >> > 2018-08-28 11:37:59,006 Error: failed to receive anything, not an xpra >> > server? >> > 2018-08-28 11:37:59,010 could also be the wrong protocol, username, >> > password or port >> > 2018-08-28 11:37:59,010 or the session was not found >> (..) >> The client got an EOF from the ssh command it tried to run. >> (the long and ugly "run-xpra" line above) >> That usually means that the session was not found, or that none of the >> "xpra" or "run-xpra" executable scripts are available and executable. >> >> You can try running it by hand from a putty session. >> I would also try to connect from a *nix client to see if the problem is >> likely to be client side or server side. >> >> This can also be caused by non-bash login shells (ie: csh, tcsh): >> https://xpra.org/trac/ticket/1892 >> The latest 2.4 beta builds include a new ssh backend, which you can >> enable using "--ssh=paramiko" and this will give you more details using >> "--debug=ssh". It should also support all types of login shells, unlike >> putty. More details here: >> https://xpra.org/trac/ticket/1646 > > > OK, we do unfortunately use tcsh here because of some Cadence (EE EDA > software) tools that have a bunch of csh scripts for setting up licenses > and other things. When I struggled with getting Xpra to connect a few > months ago, the culprit was some output to stdout from my .cshrc file. > Though that's been suppressed. I'll give some of the suggestions you > mentioned a try and report back. > > Thanks, > Ben > _______________________________________________ shifter-users mailing list [email protected] http://lists.devloop.org.uk/mailman/listinfo/shifter-users
