xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#632 closed defect (fixed)

fails to start remote server

Reported by: onlyjob Owned by: onlyjob
Priority: major Milestone: 0.14
Component: server Version: trunk
Keywords: Cc:

Description

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

Attachments (2)

see-commands.patch (1.1 KB) - added by Antoine Martin 5 years ago.
simple patch for seeing which commands are being run on stderr
632_for_0.13.8.zip (6.6 KB) - added by onlyjob 5 years ago.
backported patches for 0.13.8

Download all attachments as: .zip

Change History (28)

comment:1 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to onlyjob

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

comment:2 Changed 5 years ago by 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".

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by 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>}
Last edited 5 years ago by onlyjob (previous) (diff)

comment:5 Changed 5 years ago by 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...

Last edited 5 years ago by onlyjob (previous) (diff)

comment:6 Changed 5 years ago by 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.

comment:7 in reply to:  6 Changed 5 years ago by 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

  • local start-child commands from config file may not make any sense on remote side;
  • they might collide with remote commands;
  • it is hard to avoid starting something more than once when start-child are similar in configs on both sides.

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?

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by 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'"

comment:10 in reply to:  9 Changed 5 years ago by 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...

comment:11 Changed 5 years ago by 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?

comment:12 Changed 5 years ago by 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):

  • client:
    xpra start ssh:xpra@localhost:10 --start-child "xterm -T 'hello world'"
    
  • this calls ssh:
    ['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'], ..)
    
  • on the server:
    ['/bin/xpra', '_proxy_start', ':10', "--start-child=xterm -T 'hello world'", '--dpi=96']
    
  • which calls:
    /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)

Changed 5 years ago by Antoine Martin

Attachment: see-commands.patch added

simple patch for seeing which commands are being run on stderr

comment:13 Changed 5 years ago by 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...

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:14 Changed 5 years ago by 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)

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:15 Changed 5 years ago by 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...

Last edited 5 years ago by onlyjob (previous) (diff)

comment:16 Changed 5 years ago by 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!?

comment:17 Changed 5 years ago by 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.

Changed 5 years ago by onlyjob

Attachment: 632_for_0.13.8.zip added

backported patches for 0.13.8

comment:18 Changed 5 years ago by 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.

comment:19 Changed 5 years ago by 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

comment:20 Changed 5 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

Tested ok and released.

comment:21 Changed 5 years ago by 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"
Last edited 5 years ago by onlyjob (previous) (diff)

comment:22 Changed 5 years ago by onlyjob

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

comment:23 Changed 5 years ago by 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.

comment:24 in reply to:  23 Changed 5 years ago by 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.

comment:25 in reply to:  21 Changed 5 years ago by 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.

comment:26 Changed 5 years ago by Antoine Martin

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

Note: See TracTickets for help on using tickets.