Xpra: Ticket #632: fails to start remote server

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


Sun, 10 Aug 2014 01:43:42 GMT - Antoine Martin: owner changed

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))

Sun, 10 Aug 2014 02:37:52 GMT - onlyjob:

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".


Sun, 10 Aug 2014 15:25:34 GMT - onlyjob:

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.


Sun, 10 Aug 2014 16:22:40 GMT - onlyjob:

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>}

Sun, 10 Aug 2014 16:38:06 GMT - onlyjob:

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...


Sun, 10 Aug 2014 16:38:55 GMT - Antoine Martin:

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.


Sun, 10 Aug 2014 17:08:54 GMT - onlyjob:

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?


Mon, 11 Aug 2014 10:01:43 GMT - Antoine Martin:

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.


Mon, 11 Aug 2014 15:02:35 GMT - Antoine Martin:

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'"

Tue, 12 Aug 2014 03:20:08 GMT - onlyjob:

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...


Tue, 12 Aug 2014 05:30:23 GMT - Antoine Martin:

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?


Tue, 12 Aug 2014 05:52:33 GMT - Antoine Martin:

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):

(and unlike the other subcommands, the regular server start does not remove xeyes from its list of start-child)


Tue, 12 Aug 2014 05:55:37 GMT - Antoine Martin: attachment set

simple patch for seeing which commands are being run on stderr


Tue, 12 Aug 2014 06:38:45 GMT - onlyjob:

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...


Tue, 12 Aug 2014 07:57:58 GMT - Antoine Martin:

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)


Tue, 12 Aug 2014 08:17:06 GMT - onlyjob:

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...


Tue, 12 Aug 2014 08:36:24 GMT - Antoine Martin:

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!?


Tue, 12 Aug 2014 08:43:57 GMT - onlyjob:

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.


Wed, 13 Aug 2014 14:24:11 GMT - onlyjob: attachment set

backported patches for 0.13.8


Wed, 13 Aug 2014 14:31:01 GMT - onlyjob:

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.


Wed, 13 Aug 2014 14:58:45 GMT - Antoine Martin:

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


Thu, 14 Aug 2014 08:44:50 GMT - Antoine Martin: status changed; resolution set

Tested ok and released.


Tue, 19 Aug 2014 01:58:02 GMT - onlyjob:

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"

Tue, 19 Aug 2014 02:24:51 GMT - onlyjob:

This is only happening when server starting over SSH. All children start with xpra start :44 --start-child="xterm" --start-child="xeyes".


Tue, 19 Aug 2014 02:47:29 GMT - Antoine Martin:

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.


Tue, 19 Aug 2014 03:47:30 GMT - onlyjob:

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.


Sat, 23 Aug 2014 03:18:28 GMT - onlyjob:

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.


Fri, 29 Aug 2014 12:49:30 GMT - Antoine Martin:

This was not the end of it... see #666


Sat, 23 Jan 2021 05:01:26 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/632