On Tue, Aug 28, 2018 at 8:42 PM Antoine Martin <anto...@nagafix.co.uk> 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 shifter-users@lists.devloop.org.uk http://lists.devloop.org.uk/mailman/listinfo/shifter-users
