The generated script, /run/user/$UID/xpra/run-xpra
, incorrectly inserts spaces before the END heredoc marker, causing the remainder of the script to be assigned to the heredoc, resulting a syntax error and a client connection failure.
% tail -17 /run/user/$UID/xpra/run-xpra GDK_BACKEND='x11'; export GDK_BACKEND cd '/usr/lib/python3/dist-packages/xpra' _XPRA_PYTHON='/usr/bin/python3' _XPRA_SCRIPT='/bin/xpra' if which "$_XPRA_PYTHON" > /dev/null && [ -e "$_XPRA_SCRIPT" ]; then # Happypath: exec "$_XPRA_PYTHON" "$_XPRA_SCRIPT" "$@" else cat >&2 <<END Could not find one or both of '$_XPRA_PYTHON' and '$_XPRA_SCRIPT' Perhaps your environment has changed since the xpra server was started? I'll just try executing 'xpra' with current PATH, and hope... END exec xpra "$@" fi % /run/user/$UID/xpra/run-xpra /run/user/20263/xpra/run-xpra: 122: /run/user/20263/xpra/run-xpra: Syntax error: end of file unexpected (expecting "fi")
The culprit is in server/server_util.py
, lines 86-96, where the shell code snippet is not left justified.
By the way, this error is not returned by the Xpra client, regardless of the debug level. The reported error is unhelpful, as it does not include the error message returned by the shell:
2020-03-31 18:04:10,153 Error: failed to receive anything, not an xpra server? 2020-03-31 18:04:10,153 could also be the wrong protocol, username, password or port 2020-03-31 18:04:10,154 or the session was not found 2020-03-31 18:04:10,154 Connection lost
The only way to debug this was by specifying a -v
option to ssh:
xpra --ssh 'ssh -v' attach ssh://$HOST/99 [...] /run/user/20263/xpra/run-xpra: 122: /run/user/20263/xpra/run-xpra: Syntax error: end of file unexpected (expecting "fi") [...]
It looks like it's correct in trunk, browser/xpra/trunk/src/xpra/server/server_util.py
but not in 3.0.x? browser/xpra/tags/v3.0.x/src/xpra/server/server_util.py
The culprit is in server/server_util.py, lines 86-96, where the shell code snippet is not left justified.
Thanks for the report. That's exactly it. I had tested it with python3, then added the if-else which changed indentation... trunk doesn't need python2 support, so it doesn't have if-else, or the indentation problem.
Lesson of the day: never apply last minute fixes to a stable branch.. r25876 broke this, r25888 fixes it.
Updated builds are on the way..
Hmm, I'm still gettting this error in xpra v3.0.8-r25889.
My commandline is:
xpra start ssh:bunkerhill --start=/opt/calibre/calibre &
Please run your client with -d ssh
and post the output.
And specify your OS at both ends.
Server: Ubuntu 18.04 Client: OsX
xpra start -d ssh ssh:bunkerhill --start=/opt/calibre/calibre 2020-04-01 12:03:29,323 using paramiko 2020-04-01 12:03:29,957 Xpra GTK3 client version 3.0.8-r25796 64-bit 2020-04-01 12:03:29,983 running on Mac OS X 10.15.3 2020-04-01 12:03:31,044 GStreamer version 1.16.2 for Python 3.8.2 64-bit 2020-04-01 12:03:31,318 OpenGL_accelerate module loaded 2020-04-01 12:03:31,347 Using accelerated ArrayDatatype /Applications/Xpra.app/Contents/Resources/lib/python/numpy/ma/core.py:4466: SyntaxWarning: "is" with a literal. Did you mean "=="? if self.shape is (): /Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk3/nativegl_client_window.py:13: Warning: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed return GLContext().check_support(force_enable) #pylint: disable=not-callable /Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk3/nativegl_client_window.py:13: Warning: g_object_set_qdata_full: assertion 'G_IS_OBJECT (object)' failed return GLContext().check_support(force_enable) #pylint: disable=not-callable /Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk3/nativegl_client_window.py:13: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed return GLContext().check_support(force_enable) #pylint: disable=not-callable 2020-04-01 12:03:33,821 OpenGL enabled with AMD Radeon Pro 450 OpenGL Engine 2020-04-01 12:03:38,839 paramiko socket_connect: sockname=('192.168.1.102', 53788), peername=('192.168.1.54', 22) 2020-04-01 12:03:38,851 Connected (version 2.0, client OpenSSH_7.6p1) 2020-04-01 12:03:38,869 do_ssh_paramiko_connect_to(<paramiko.Transport at 0xffb6c10 (cipher aes128-ctr, 128 bits) (connected; awaiting auth)>, '192.168.1.54', 'jeff', None, {'hostname': '192.168.1.54', 'user': 'jeff', 'identityfile': ['/Users/jeff/.ssh/bunkerhill']}, ['/Users/jeff/.ssh/bunkerhill']) 2020-04-01 12:03:38,870 SSH transport <paramiko.Transport at 0xffb6c10 (cipher aes128-ctr, 128 bits) (connected; awaiting auth)> 2020-04-01 12:03:38,871 remote_server_key=MD5:88:0d:3c:9b:2a:ca:e5:b4:05:f9:07:b9:6d:d4:44:36 2020-04-01 12:03:38,889 HostKeys.load(/Users/jeff/.ssh/known_hosts) successful 2020-04-01 12:03:38,889 host keys=<paramiko.hostkeys.HostKeys object at 0x111444a90> 2020-04-01 12:03:38,889 ed25519 host key 'MD5:88:0d:3c:9b:2a:ca:e5:b4:05:f9:07:b9:6d:d4:44:36' OK for host '192.168.1.54' 2020-04-01 12:03:38,890 starting authentication 2020-04-01 12:03:38,890 trying none authentication 2020-04-01 12:03:38,894 auth_none() Traceback (most recent call last): File "/Applications/Xpra.app/Contents/Resources/lib/python/xpra/net/ssh.py", line 583, in auth_none transport.auth_none(username) File "paramiko/transport.pyc", line 1446, in auth_none File "paramiko/auth_handler.pyc", line 250, in wait_for_response paramiko.ssh_exception.BadAuthenticationType: Bad authentication type; allowed types: ['publickey'] 2020-04-01 12:03:38,896 agent keys: () 2020-04-01 12:03:38,897 trying public key authentication using ['/Users/jeff/.ssh/bunkerhill'] 2020-04-01 12:03:38,898 trying '/Users/jeff/.ssh/bunkerhill' 2020-04-01 12:03:38,898 trying to load as RSA 2020-04-01 12:03:38,899 loaded RSA private key from '/Users/jeff/.ssh/bunkerhill' 2020-04-01 12:03:38,899 auth_publickey using /Users/jeff/.ssh/bunkerhill as RSA: MD5:6e:a1:35:e9:12:47:90:62:98:fe:6b:3b:e8:26:92:b3 2020-04-01 12:03:38,917 Authentication (publickey) successful! 2020-04-01 12:03:38,917 will try to run xpra from: ['$XDG_RUNTIME_DIR/xpra/run-xpra', 'xpra', '/usr/local/bin/xpra', '~/.xpra/run-xpra'] 2020-04-01 12:03:39,675 exec_command('which $XDG_RUNTIME_DIR/xpra/run-xpra') 2020-04-01 12:03:39,679 exit status is not ready yet, sleeping 2020-04-01 12:03:39,689 exec_command('which $XDG_RUNTIME_DIR/xpra/run-xpra')=0 2020-04-01 12:03:39,689 cmd(['_proxy_start'], ['--debug=ssh', '--start=/opt/calibre/calibre'])=$XDG_RUNTIME_DIR/xpra/run-xpra "_proxy_start" "--debug=ssh" "--start=/opt/calibre/calibre" 2020-04-01 12:03:39,689 trying to open SSH session, window-size=134217727, timeout=60 2020-04-01 12:03:39,691 channel exec_command($XDG_RUNTIME_DIR/xpra/run-xpra "_proxy_start" "--debug=ssh" "--start=/opt/calibre/calibre") 2020-04-01 12:03:39,757 SSH EOF on stderr of run-xpra 2020-04-01 12:03:39,767 keyboard settings: layout=us 2020-04-01 12:03:39,769 Warning: invalid screen size 8532x9615mm 2020-04-01 12:03:39,769 using 330x206 mm 2020-04-01 12:03:39,774 desktop size is 1680x1050 with 1 screen: 2020-04-01 12:03:39,774 pacific-5.local (330x206 mm - DPI: 129x129) workarea: 1680x947 at 0x23 2020-04-01 12:03:39,774 monitor 2 /Applications/Xpra.app/Contents/Resources/lib/python/xpra/platform/darwin/osx_tray.py:91: Warning: invalid cast from 'GtkMenuBar' to 'GtkWindow' self.macapp.set_menu_bar(self.menu) (Xpra:75148): Gtk-CRITICAL **: 12:03:39.864: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed 2020-04-01 12:03:39,943 Error: failed to receive anything, not an xpra server? 2020-04-01 12:03:39,943 could also be the wrong protocol, username, password or port 2020-04-01 12:03:39,943 or the session was not found 2020-04-01 12:03:39,943 Connection lost
My guess is that since you're doing a remote start, it will use the corrupted run-xpra
script without re-generating it.
Try nuking it, ie:
rm $XDG_RUNTIME_DIR/xpra/run-xpra
or just re-create it by starting the server from an ssh shell:
xpra start --start=app
Bingo!
I executed: rm $XDG_RUNTIME_DIR/xpra/run-xpra
and it works.
Thanks!
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2693