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.
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=...
?
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))
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>}
That ssh does look malformed.
Can please you post what the command should look like, by applying the print patch to an older version?
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>}
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)
I believe r6746 fixes this.
Please confirm so I can backport.
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>}
"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
?
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.
By the way redirection of error is not optional.
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.
Shell and redirection seems to be a minimal fix that takes care of warnings too. Shell without redirection produces connection error...
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.
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:
--- xpra/scripts/main.py (revision 6750) +++ xpra/scripts/main.py (working copy) @@ -643,7 +643,7 @@ elif mode in ("_proxy", "_proxy_start", "_shadow_start") and (supports_server or supports_shadow): nox() return run_proxy(parser, options, script_file, args, mode) - elif mode == "initenv": + elif mode == "initenv-disabled!": from xpra.scripts.server import xpra_runner_shell_script, write_runner_shell_script script = xpra_runner_shell_script(script_file, os.getcwd(), options.socket_dir) dotxpra = DotXpra(options.socket_dir)
xpra start :10
xpra attach --ssh="ssh -A -t localhost ssh -A" ssh:localhost:10
Awesome, thank you. :)
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.
(editing bug title to make it easier to find what this is about)
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.
I've added more info:
Replying to totaam:
I've added more info:
- to the wiki page: wiki/Xdummy
- to the xorg.conf: r6794
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.
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
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
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?
Not heard back from onlyjob, nomnomnom?
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.
Backported in r6886. Closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/597