Xpra: Ticket #597: "initenv" connection error when using nested ssh - regression in 0.13.4

I connect to my session remotely using the following (sample) command:

xpra attach --ssh="ssh -A -t user@my.gateway.com ssh -A" ssh:localserver:33

Upgrading client from 0.13.3 to 0.13.4 broke this functionality -- now Xpra just prints usage information and the following error

xpra: error: invalid mode 'initenv'

Server is running 0.13.3.



Thu, 12 Jun 2014 07:21:02 GMT - Antoine Martin: owner changed

xpra initenv was added to ensure we can use xpra start ssh:HOST:DISPLAY, it creates the environment if it doesn't exist already.

So, upgrading your server to 0.13.4 should get rid of the warning about "initenv" being missing. It doesn't explain the failure though. Do you only get the failure when using --ssh=...?


Thu, 12 Jun 2014 07:24:12 GMT - Antoine Martin:

Maybe this helps:

Index: xpra/scripts/main.py
===================================================================
--- xpra/scripts/main.py	(revision 6710)
+++ xpra/scripts/main.py	(working copy)
@@ -833,7 +833,7 @@
     if dtype == "ssh":
         cmd = display_desc["full_ssh"]
         proxy_cmd = display_desc["remote_xpra"] + display_desc["proxy_command"] + display_desc["display_as_args"]
-        cmd += ["xpra initenv;"+(" ".join(proxy_cmd))]
+        cmd += ["xpra initenv 2>& /dev/null;"+(" ".join(proxy_cmd))]
         try:
             kwargs = {}
             kwargs["stderr"] = sys.stderr

This will show you what ssh command line ends up being used:

Index: xpra/scripts/main.py
===================================================================
--- xpra/scripts/main.py	(revision 6710)
+++ xpra/scripts/main.py	(working copy)
@@ -849,7 +849,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))

Thu, 12 Jun 2014 07:38:33 GMT - onlyjob:

Thanks for quick response. Yes problem is only with "--ssh" (apparently introduced in r6696). Patch did not fix this problem -- now error is

bash: /dev/null: ambiguous redirect

"starting ssh" printed the following:

starting ssh: ['ssh', '-A', '-t', 'user@my.gateway.com', 'ssh', '-A', '-T', 'localserver', 'xpra initenv 2>& /dev/null;.xpra/run-xpra _proxy :22'] with kwargs={'stderr': <open file '<stderr>', mode 'w' at 0x7f6f871ca1e0>}

Thu, 12 Jun 2014 07:42:45 GMT - Antoine Martin:

That ssh does look malformed.

Can please you post what the command should look like, by applying the print patch to an older version?


Thu, 12 Jun 2014 07:53:28 GMT - onlyjob:

Here you go:

starting ssh: ['ssh', '-A', '-t', 'user@my.gateway.com', 'ssh', '-A', '-T', 'localserver', '.xpra/run-xpra', '_proxy', ':22'] with kwargs={'stderr': <open file '<stderr>', mode 'w' at 0x7f9a6b6541e0>}

Thu, 12 Jun 2014 07:58:26 GMT - Antoine Martin:

Ah, it isn't malformed. I think that what is happening is that the ";" is being caught by the outer ssh and not the inner one. Not sure how to deal with this.. ideas? Maybe adding quotes around would help? As in:

"xpra initenv 2>& /dev/null;.xpra/run-xpra _proxy :22"

(we want this to be executed as a unit)


Thu, 12 Jun 2014 08:36:59 GMT - Antoine Martin:

I believe r6746 fixes this.

Please confirm so I can backport.


Thu, 12 Jun 2014 08:55:04 GMT - onlyjob:

In a way it does fix it but incorrectly:

starting ssh: ['ssh', '-A', '-t', 'user@my.gateway.com', 'ssh', '-A', '-T', 'localserver', "'xpra initenv;.xpra/run-xpra _proxy :22'"] with kwargs={'stderr': <open file '<stderr>', mode 'w' at 0x7f99320ac1e0>}
Pseudo-terminal will not be allocated because stdin is not a terminal.
2014-06-12 18:47:01,446 detected keyboard: rules=evdev, model=pc104, layout=us,ru
2014-06-12 18:47:01,446 desktop size is 3600x1080 with 1 screen(s):
2014-06-12 18:47:01,447   ':0.0' (949x284 mm) workarea: 3600x1038 at 0x42
2014-06-12 18:47:01,447     VGA1 1920x1080 (510x287 mm)
2014-06-12 18:47:01,447     LVDS1 1680x1050 at 1920x0 (331x207 mm)
Usage:
        xpra start DISPLAY
        xpra stop [DISPLAY]
        xpra exit [DISPLAY]
        xpra list
        xpra upgrade DISPLAY
        xpra attach [DISPLAY]
        xpra detach [DISPLAY]
        xpra screenshot filename [DISPLAY]
        xpra info [DISPLAY]
        xpra control DISPLAY command [arg1] [arg2]..
        xpra version [DISPLAY]
        xpra shadow [DISPLAY]
xpra: error: invalid mode 'initenv'
2014-06-12 18:47:02,628 server: Linux debian 7.5 , Xpra version 0.13.3 (r6658)
2014-06-12 18:47:02,630 Attached to ssh:localserver:22 (press Control-C to detach)

Here is a better way:

@@ -826,9 +826,9 @@
     conn = None
     if dtype == "ssh":
         cmd = display_desc["full_ssh"]
         proxy_cmd = display_desc["remote_xpra"] + display_desc["proxy_command"] + display_desc["display_as_args"]
-        cmd += ["xpra initenv;"+(" ".join(proxy_cmd))]
+        cmd += ["sh -c 'xpra initenv 2>&1 >>/dev/null; "+(" ".join(proxy_cmd))+"'"]
         try:
             kwargs = {}
             kwargs["stderr"] = sys.stderr
             if not display_desc.get("exit_ssh", False) and os.name=="posix" and not sys.platform.startswith("darwin"):

which works as follows:

starting ssh: ['ssh', '-A', '-t', 'user@my.gateway.com', 'ssh', '-A', '-T', 'localserver', "sh -c 'xpra initenv 2>&1 >>/dev/null; .xpra/run-xpra _proxy :22'"] with kwargs={'stderr': <open file '<stderr>', mode 'w' at 0x7f278b9a61e0>}

Thu, 12 Jun 2014 09:00:31 GMT - Antoine Martin:

"incorrectly"? How so? The only difference is the redirection of the error (which is optional really).

I don't understand why we would also need the sh -c?


Thu, 12 Jun 2014 09:07:56 GMT - onlyjob:

Please look at the output which still prints xpra: error: invalid mode 'initenv' and shows usage info. How can I possibly demonstrate it any better?

With "sh -c" wrapping everything works smooth. I'm not sure how to explain but that's the way it work when tested.


Thu, 12 Jun 2014 09:08:57 GMT - onlyjob:

By the way redirection of error is not optional.


Thu, 12 Jun 2014 09:11:13 GMT - Antoine Martin:

How can I possibly demonstrate it any better?


We are talking about different things.

The warning message is a different issue from the connection failure.

I am interested in the minimal fix to backport. Adding shell redirection, etc, can wait.


Thu, 12 Jun 2014 09:15:56 GMT - onlyjob:

Shell and redirection seems to be a minimal fix that takes care of warnings too. Shell without redirection produces connection error...


Thu, 12 Jun 2014 09:28:07 GMT - onlyjob:

cmd += ["'xpra initenv 2>&1 >> /dev/null;"+(" ".join(proxy_cmd))+"'"] in r6748 breaks it again:

starting ssh: ['ssh', '-A', '-t', 'user@my.gateway.com', 'ssh', '-A', '-T', 'localserver', "'xpra initenv 2>&1 >> /dev/null;.xpra/run-xpra _proxy :22'"] with kwargs={'stderr': <open file '<stderr>', mode 'w' at 0x7f176d4cf1e0>}
Pseudo-terminal will not be allocated because stdin is not a terminal.
2014-06-12 19:23:13,181 detected keyboard: rules=evdev, model=pc104, layout=us,ru
2014-06-12 19:23:13,181 desktop size is 3600x1080 with 1 screen(s):
2014-06-12 19:23:13,181   ':0.0' (949x284 mm) workarea: 3600x1038 at 0x42
2014-06-12 19:23:13,181     VGA1 1920x1080 (510x287 mm)
2014-06-12 19:23:13,182     LVDS1 1680x1050 at 1920x0 (331x207 mm)
2014-06-12 19:23:14,169 Received uninterpretable nonsense: "Usage: \n\txpra start DISPLAY\n\txpra stop [DISPLAY]\n\txpra exit [DISPLAY]\n\txpra list\n\txpra upgrade DISPLAY\n\txpra attach [DISPLAY]\n\txpra detach [DISPLAY]\n\txpra screenshot filename [DISPLAY]\n\txpra info [DISPLAY]\n\txpra control DISPLAY command [arg1] [arg2]..\n\txpra version [DISPLAY]\n\txpra shadow [DISPLAY]\n\n\nxpra: error: invalid mode 'initenv'\n"
2014-06-12 19:23:14,374 Connection lost

Please believe me, sh -c is required and necessary. Command from my patch works the best, I tested it. Thanks.


Thu, 12 Jun 2014 09:31:31 GMT - Antoine Martin:

Hah, you're right. Applied in r6749 (will backport). Even though the command is run in a shell, the redirection strings are passed to the xpra command instead.

I must have tested it wrong. Bear with me, I'm doing 20 things at a time today.

BTW, for reference, here's the easiest way I found of testing for this bug:


Thu, 12 Jun 2014 09:36:26 GMT - onlyjob:

Awesome, thank you. :)


Thu, 12 Jun 2014 09:46:42 GMT - Antoine Martin: status changed; resolution set

Backport to v0.13.x done in r6751. Closing, thanks!

Note: this code will break if the proxy command specified has single quotes in it. I don't think I want to care about that and write yet more code, this could be endless!

PS: saw that your screen resolution was not in the default xorg.conf we ship, so r6752 added it.


Thu, 12 Jun 2014 09:48:36 GMT - Antoine Martin: summary changed

(editing bug title to make it easier to find what this is about)


Sat, 14 Jun 2014 04:02:39 GMT - onlyjob:

Replying to totaam:

PS: saw that your screen resolution was not in the default xorg.conf we ship, so r6752 added it.

Thank you very much for this. I know that wasn't the first time you've added my new resolution. :) It reminded me about an idea: could you please include commented command that you use to generate new mode lines to "/etc/xpra/xorg.conf"? This way when new modeline is needed it can be easily generated using provided sample command. Thanks.


Sat, 14 Jun 2014 05:27:28 GMT - Antoine Martin:

I've added more info:


Sat, 14 Jun 2014 07:25:36 GMT - onlyjob:

Replying to totaam:

I've added more info:

That's nice, thanks. But I've mentioned sample command because you are using a particular refresh rate to generate your Modelines. Without knowing your preferred refresh rate I can't generate Modelines same as yours.

Besides gtf and cvt commands are provided by package xserver-xorg-core on Debian so they should be already available on most systems.


Sat, 14 Jun 2014 09:26:33 GMT - Antoine Martin:

I don't have a preferred refresh rate, any will do. I don't think it makes any difference whatsoever since it isn't exposed to client applications. I've added yet more information: wiki/Xdummy


Thu, 26 Jun 2014 02:28:42 GMT - nomnomnom:

I just got this issue after upgrading my client on Debian to v0.13.5. It seems that the client is getting the usage message from the server (v0.12.3 in my case) when it doesn't support the initenv subcommand. The current fix (2>&1 >> /dev/null) doesn't seem to fix it. The usage message comes out of stderr and this command redirects stderr to stdout so it still comes back across ssh. It should be "> /dev/null 2>&1". Ie, redirect stderr after redirecting stdout (I assume you want to send both streams to /dev/null). If you redirect to stderr to stdout before redirecting stdout stderr will end up pointing to whatever stdout was pointing to at the time you redirected it, which was the pty.

See here for more on the ordering for redirections: http://wiki.bash-hackers.org/syntax/redirection#multiple_redirections


Thu, 26 Jun 2014 07:32:39 GMT - Antoine Martin: status changed; resolution deleted

Applied in r6864.

Despite the fact that the link is to a bash site, I assume that the fix works equally well for other shells?

Does that work for you? onlyjob?


Wed, 02 Jul 2014 11:57:41 GMT - Antoine Martin: owner, status changed

Not heard back from onlyjob, nomnomnom?


Wed, 02 Jul 2014 17:45:15 GMT - onlyjob:

Thanks, r6864 works as expected. I think it also fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752500

Works for me, should work in other shells too. Thanks.


Thu, 10 Jul 2014 21:17:42 GMT - Antoine Martin: status changed; resolution set

Backported in r6886. Closing.


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

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