On 0.13.8 I tried the following command from the man page:
xpra start ssh:bigbox:7 --start-child=xterm
but it fails as follows:
Received uninterpretable nonsense: 'xpra main exception: proxy/shadow-start: expected 1 argument but got 2\n' Connection lost
Cannot reproduce. Tried with Fedora 20 and Debian 7.6:
ii xpra 0.13.8-1 amd64 tool to detach/reattach running X programs
Tried both with a brand new user (no existing .xpra
) and with an existing xpra user. Both worked flawlessly.
Trunk has a different error message which may help figure out what is going wrong by also logging the arguments:
assert len(args)==1, "_proxy_start: expected 1 argument but got %s: %s" % (len(args), args)
Otherwise, it might be worth logging the full command that is being run over ssh with:
--- src/xpra/scripts/main.py (revision 7176) +++ src/xpra/scripts/main.py (working copy) @@ -968,7 +968,7 @@ kwargs["stderr"] = PIPE if debug_cb: debug_cb("starting %s tunnel" % str(cmd[0])) - #debug_cb("starting ssh: %s with kwargs=%s" % (str(cmd), kwargs)) + print("starting ssh: %s with kwargs=%s" % (str(cmd), kwargs)) child = Popen(cmd, stdin=PIPE, stdout=PIPE, **kwargs) except OSError, e: raise Exception("Error running ssh program '%s': %s" % (cmd, e))
I applied patch to 0.13.8 but nothing is logged with "starting ssh". Error appears immediately after successful authentication on remote host. I'm on Debian "testing".
Found the problem -- it is start-child
option in xpra.conf
where command is given with arguments...
Apparently it was quite hard to nail because the following sample works just fine:
start-child = zenity --info --text test
with xpra start :333 --start-child=xterm
but not with xpra start ssh:localhost:333 --start-child=xterm
in which case the following error is displayed:
xpra: error: no such option: --info
:333.log
shows
started child 'zenity --info --text test' with pid NNNNN
which do not suggest any problems with syntax however remote server starts only when start-child
is commented in .xpra.conf
.
With the following patch to quote long commands it works almost properly except than it starts 3(!) children (from xpra.conf) instead of 1 over ssh:
--- a/xpra/scripts/main.py +++ b/xpra/scripts/main.py @@ -1040,9 +1040,9 @@ if params["display"] is not None: proxy_args.append(params["display"]) if opts.start_child: for c in opts.start_child: - proxy_args.append("--start-child=%s" % c) + proxy_args.append("--start-child=\"%s\"" % c) #key=value options we forward: for x in ("session-name", "encoding", "socket-dir", "dpi"): v = getattr(opts, x.replace("-", "_")) if v:
Before patch:
starting ssh: ['ssh', '-T', 'localhost', "sh -c 'xpra initenv >> /dev/null 2>&1;~/.xpra/run-xpra _proxy_start :333 --start-child=zenity --info --text test --start-child=xterm --encoding=rgb --dpi=96 --no-pulseaudio'"] with kwargs={'stderr': <open file '<stderr>', mode 'w' at 0x7f6e5530b1e0>}
After patch:
starting ssh: ['ssh', '-T', 'localhost', 'sh -c \'xpra initenv >> /dev/null 2>&1;~/.xpra/run-xpra _proxy_start :333 --start-child="zenity --info --text test" --start-child="xterm" --encoding=rgb --dpi=96 --no-pulseaudio\''] with kwargs={'stderr': <open file '<stderr>', mode 'w' at 0x7ff7c19711e0>}
I think first start-child process starts upon server initialisation when it parses its config file. Second is passed by the client when it parses config file and then push corresponding --start-child over SSH. Those two are correct and they will be the same with xpra start ssh:localhost:333
.
But I don't understand why/where third start-child process is started (proxy?)... Not sure how to de-duplicate...
Thanks. That's the problem! (I got sidetracked during testing on Jessie because the amd opencl sdk was installed and playing havoc with signals before I disabled it..)
It may be better to do it this way (untested):
proxy_args.append("--start-child") proxy_args.append(str(c))
So that we can have quotes within the child string.
As for the extra child being started, I will test tomorrow.
Replying to totaam:
It may be better to do it this way (untested):
proxy_args.append("--start-child") proxy_args.append(str(c))So that we can have quotes within the child string.
I tried that but probably I did something wrong because it did not handle quotes at all..
As for the extra child being started, I will test tomorrow.
Thanks. From the quick look it appears that run_proxy start extra process...
From implementation prospective I think Xpra should not push start-child from its config file to remote side when server is starting over SSH because
To me the most intuitive behaviour is when only explicitly given in command line --start-child arguments are pushed to the remote side when new server is starting over SSH. Of course remote side is expected to start children as per its own config file. Thoughts?
I tried that but probably I did something wrong because it did not handle quotes at all..
I think that r7246 fixes quotes within start-child commands.
But only as long as we get rid of this monster (which you have seen before..):
cmd += ["sh -c 'xpra initenv >> /dev/null 2>&1 || echo \"Warning: xpra server does not support initenv\" 1>&2;"+(" ".join(proxy_cmd))+"'"]
r7245 replaces the shell with simple arguments to ssh instead. It is quite a big change... so makes me nervous about backporting to v0.13.x as this could break something somewhere. Does that work for you at least?
As for deciding where to honour start-child, you are right. The problem is that the code doesn't know or care where start-child was set... that's done somewhere else. But I'll see what I can do.
r7254 fixes the multiple start-child issue... but I've just spotted that shell escaping is now broken! (not sure when - could be r7253, will investigate). Tested with:
xpra start ssh:test@localhost:10 --start-child "xterm -T 'hello world'"
Replying to totaam:
Tested with:
xpra start ssh:test@localhost:10 --start-child "xterm -T 'hello world'"
For the record --start-child
argument with long quoted command wasn't broken; only long start-child
config options...
Works fine with r7262 on top: we don't need so much escaping. Only when calling ssh which calls the remote shell.
Will backport unless you can break it?
You need r7263 to remove the extra child from the _proxy_start
command.
It goes like this (I added start-child = xeyes -distance
to the global /etc/xpra/xpra.conf
for testing):
xpra start ssh:xpra@localhost:10 --start-child "xterm -T 'hello world'"
['ssh', '-l', 'xpra', '-T', 'localhost', 'xpra', 'initenv', '>>', '/dev/null', '2>&1', \ '||', 'echo', '"Warning: xpra server does not support initenv"', '1>&2', ';', \ '~/.xpra/run-xpra', '_proxy_start', ':10', "'--start-child=xterm -T '\\''hello world'\\'''", '--dpi=96'], ..)
['/bin/xpra', '_proxy_start', ':10', "--start-child=xterm -T 'hello world'", '--dpi=96']
/bin/xpra', 'start', ':10', "--start-child=xterm -T 'hello world'
(and unlike the other subcommands, the regular server start does not remove xeyes from its list of start-child)
simple patch for seeing which commands are being run on stderr
All good in regards to start-child but I think r7245 broke subshell so the following no longer works:
xpra attach --ssh="ssh -A -t gateway ssh -A" ssh:host:333
Perhaps that's why shell was needed...
Works fine here, are you sure you've got all the patches applied?
xpra --ssh="ssh -A -t localhost ssh -A" start ssh:xpra@localhost:10 --start-child=xterm Popen(['ssh', '-A', '-t', 'localhost', 'ssh', '-A', '-l', 'xpra', '-T', 'localhost', \ 'xpra', 'initenv', '>>', '/dev/null', '2>&1', '||', \ 'echo', '"Warning: xpra server does not support initenv"', '1>&2', ';', \ '~/.xpra/run-xpra', '_proxy_start', ':10', "'--start-child=xterm'", '--dpi=96'], ..)
How does it break it and what is the error? (the patch above may help figure things out too)
I think I got them all: r7245, r7246, r7253, r7254, r7260, r7262, r7263 applied to 0.13.8. The following command:
xpra attach --ssh="ssh -A -t localhost ssh -A" ssh:localhost:333
fails to attach to existing session:
Popen(['ssh', '-A', '-t', 'localhost', 'ssh', '-A', '-T', 'localhost', 'xpra', 'initenv', '>>', '/dev/null', '2>&1', '||', 'echo', '"Warning: xpra server does not support initenv"', '1>&2', ';', '~/.xpra/run-xpra', '_proxy', ':333'], ..) Pseudo-terminal will not be allocated because stdin is not a terminal.
Maybe backport needs some additional changes...
How odd, I get the same error (your should remove -t
btw to avoid the Pseudo-terminal will not be allocated because stdin is not a terminal.), but only when I ssh to the same user account!? If I just add someotherusername@locahost then it works fine!?
Hmm, with -t
or without, with username explicitly given to SSH or without I can't attach through SSH gateway... I can do it only with unpatched 0.13.8. Other than this all start-child issues (including start of server over SSH) are fixed.
backported patches for 0.13.8
I think it will be best to revert r7245 in order to fix attaching through ssh tunnel as in comment:13. With r7246,r7253,r7254,r7260,r7262,r7263 everything seems to work very well on 0.13.8 (r7245 is not needed). I've attached "632_for_0.13.8.zip" with the above patches -- hopefully it will help with backporting to 0.13.8. Thanks.
Thanks, revert for trunk in r7274, patches applied to v0.13.x in r7275.
Will do some more testing tomorrow and release 0.13.9
Tested ok and released.
0.13.9 start only first child (i.e. xterm
) with the following command:
xpra start ssh:localhost:44 --start-child="xterm" --start-child="xeyes"
This is only happening when server starting over SSH. All children start with xpra start :44 --start-child="xterm" --start-child="xeyes"
.
FYI: unless this bug can be reproduced (I cannot) on an actively maintained version (as of today: v0.14.x and trunk / v0.15.x), this bug will not be addressed.
Replying to totaam:
FYI: unless this bug can be reproduced (I cannot) on an actively maintained version (as of today: v0.14.x and trunk / v0.15.x), this bug will not be addressed.
Understood, thanks for explaining that. I'll try 0.14 soon.
Replying to onlyjob:
0.13.9 start only first child (i.e.
xterm
) with the following command:
This problem reported separately as #644 and fixed in 0.14.1.
This was not the end of it... see #666
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/632