vscode-remote-x11 icon indicating copy to clipboard operation
vscode-remote-x11 copied to clipboard

Published 20 hours ago • verified publisher icon joelspadin

Cant set up display

Open leojrfs opened this issue 4 years ago • 14 comments

First of all, thank you for your work on this extension.

Im running vscode 1.43.2 on macOS 10.15.4 and connecting with a remote session to a Ubuntu 18.04.4 LTS (GNU/Linux 5.3.0-42-generic x86_64) server.

Remote X11:

Setting up display for remote "ssh-remote".
Connecting to SSH leo@host 22

Remote X11 (SSH) (Server IP was modified for the example):

Connecting to [email protected] port 22
Connection ready. Setting up display...
...timed out.

It doesnt start the X11 session:

leo@linux:~> echo $DISPLAY

leojrfs avatar Apr 08 '20 15:04 leojrfs

I have some changes to add more logging that I haven't published yet. I'll try to publish a new version soon and then hopefully it will give more info to go on, since I can't tell what's wrong from what you've written.

joelspadin avatar Apr 14 '20 04:04 joelspadin

I just published version 1.1.0 with improved logging. The Remote X11 (SSH) logs now print the output from the SSH server, which should hopefully tell us why it's timing out.

joelspadin avatar Apr 19 '20 20:04 joelspadin

With the new version launching X apps just hangs, also found out that any interactive program hangs on load (doesn't open and hangs) as well vim, git rebase -i. etc

leo@linux:~/source > git rebase -i origin/master


leo@linux:~/source > vim


leo@linux:~/source > git gui

If I uninstall both vscode-remote-x11 extensions, interactive programs work fine.

leojrfs avatar Apr 24 '20 14:04 leojrfs

Can you provide logs from the Output panel (Ctrl+Shift+U) for "Remote X11" and "Remote X11 (SSH)"? From my experience, GUI programs hanging without displaying anything usually means the application is sending things to the forwarded display, but the X server on the local machine isn't receiving them.

Other things to check:

  1. Does anything display if you use a regular SSH connection without going through my extension? If not, we need to figure that out before my extension will work. You should be able to do something like this outside of vscode:
# Set the location and display number of your X server
export DISPLAY=localhost:0
# SSH with X forwarding
ssh leo@linux -X
# GUI programs should now display locally
xclock
  1. Did DISPLAY get set in the terminal you're running these from?
  2. Does something like "x11 accept: 127.0.0.1" get logged in the "Remote X11 (SSH)" output when you run a GUI program?
  3. Is your X server running?
  4. Does your remoteX11.display setting match the display number on which your X server is listening?

joelspadin avatar Apr 25 '20 02:04 joelspadin

Remote X11:

Setting up display for remote "ssh-remote".
Connecting to SSH leo@linux port 22
DISPLAY = localhost:10.0

Remote X11 (SSH):

Connecting to [email protected] port 22
Connection ready. Setting up display...
Command for host "12.12.12.12" is: bash -c "echo DISPLAY=$DISPLAY"
----- Begin output from host -----

bash -c "echo DISPLAY=$DISPLAY"
]1337;RemoteHost=leo@linux]1337;CurrentDir=/home/leo]1337;ShellIntegrationVersion=14;shell=bash]133;C;]1337;RemoteHost=leo@linux]1337;CurrentDir=/home/leo]133;D;0]133;Aleo@linux:~$ ]133;Bbash -c "echo DISPLAY=$DISPLAY"
]133;C;DISPLAY=localhost:10.0

----- End output from host -----
Display ready: localhost:10.0
Parser disposed.
x11 accept: 127.0.0.1

  1. yes, it works with when not using your extension.

  2. I dont think the DISPLAY variable is an issue, It is set correctly or else X programs would fail with a message like "couldnt connect to display".

  3. yes, every time I try to open a X program it outputs that message:

x11 accept: 127.0.0.1
x11 accept: 127.0.0.1
x11 accept: 127.0.0.1

  1. yes.

  2. yes.

leojrfs avatar Apr 27 '20 16:04 leojrfs

Based on that, it sounds like the traffic is making it through the SSH connection to your local PC, but then either I'm not routing it to the correct place or something like a firewall is blocking it.

I don't have anything that runs macOS, so I can't test how an X server behaves on it. I have a few more ideas though:

  • When not going through my extension, what is DISPLAY set to on the local PC, before you connect with SSH? I assume it's localhost:<display>.<screen>, but if you need to point it at anything other than localhost, I need to add a setting for that.
  • Does your X server use port 6000 + display number? (e.g. display 0 is 6000, display 1 is 6001, etc.) I assume this is the case because all the documentation I've found indicates that this is the correct port to use, but I don't know if it's possible to configure an X server to use different ports.
  • Do you have a firewall that might be blocking vscode from using the port your X server uses? If it's blocking vscode but not a regular ssh process, that could explain this behavior.

joelspadin avatar Apr 28 '20 01:04 joelspadin

@ChaosinaCan I'm having a similar problem on my macbook, and I think it's because we have to route it to somewhere else than localhost. It would be great if you could add the option to change it.

MacOS doesn't come with X server out of the box, we use Xquartz instead. In this case, I have to set DISPLAY=/private/tmp/com.apple.launchd.RnL8eXEjXE/org.macosforge.xquartz:0 on my local machine for it to work.

hyt589 avatar Jun 30 '20 03:06 hyt589

I was thinking I should just replace the display/screen settings with a single one where you write the full DISPLAY variable, and if that's not set it falls back to the one from your environment, and then to localhost:0.0. That would let you change the host, so it should also work for you.

joelspadin avatar Jul 02 '20 03:07 joelspadin

That sounds about right

hyt589 avatar Jul 02 '20 10:07 hyt589

That sounds about right

Have you solved this problem, recently I have this problem too.

olixu avatar Sep 15 '20 11:09 olixu

I just published version 1.5.0, which changes to using a Unix socket to communicate with the X11 server on Linux and macOS. It is now working for me on Linux, but I don't have any way to test on macOS. Could you check if this is fixed now?

joelspadin avatar Jan 31 '21 22:01 joelspadin

I just published version 1.5.0, which changes to using a Unix socket to communicate with the X11 server on Linux and macOS. It is now working for me on Linux, but I don't have any way to test on macOS. Could you check if this is fixed now?

I can confirm that the issue still exists in the latest version.

leojrfs avatar Feb 03 '21 16:02 leojrfs

I came across the related problem, under macOS 10.15.7 + VS code 1.54.3 + Remote X11 1.5.0. Firstly, when I login the remote server through different terminal windows, the DISPLAY variable are set with distinct values, such as localhost:20.0, localhost:18.0, etc. With respect to DISPLAY number, I tried the following: 1 . the local setting is: local_setting 2.1 the remote setting 1 remote_setting or 2.2 the remote setting 2 remote_setting2

Under settings 1+2.1, the xeyes GUI tool hang for a long time and the xquart doesn't show out; under settings 1+2.2, the xquart inited and it worked. The setting 2.1 was set, as I misunderstood the README Also make sure the remoteX11.display setting matches the **display number your X server is set to use**.. The X server is on my own local Mac machine, with display number 0.

The other settings modified: Remote X11.SSH: Xauth Permission Level: trusted in the remote server, which means ssh -Y usename@server. This is also mentioned by @Kernopike. This is solved through a tough trial and error. However, I'm happy finally to make it #36

ddzhang3 avatar Mar 31 '21 08:03 ddzhang3

I came across the related problem, under macOS 10.15.7 + VS code 1.54.3 + Remote X11 1.5.0. Firstly, when I login the remote server through different terminal windows, the DISPLAY variable are set with distinct values, such as localhost:20.0, localhost:18.0, etc. With respect to DISPLAY number, I tried the following: 1 . the local setting is: local_setting 2.1 the remote setting 1 remote_setting or 2.2 the remote setting 2 remote_setting2

Under settings 1+2.1, the xeyes GUI tool hang for a long time and the xquart doesn't show out; under settings 1+2.2, the xquart inited and it worked. The setting 2.1 was set, as I misunderstood the README Also make sure the remoteX11.display setting matches the **display number your X server is set to use**.. The X server is on my own local Mac machine, with display number 0.

The other settings modified: Remote X11.SSH: Xauth Permission Level: trusted in the remote server, which means ssh -Y usename@server. This is also mentioned by @Kernopike. This is solved through a tough trial and error. However, I'm happy finally to make it #36

Hi @ddzhang3

The latest MacOS vs code (Remote - SSH) don’t need this extension anymore.

Check my environment for your reference:

XQuartz: 2.8.0_beta1 (xorg-server 1.19.7) VSCode: 1.55.2 VSCode - Remote-SSH: v0.65.4

Summary of ~/.ssh/config:

ForwardX11 yes
ForwardX11Trusted yes

Kernopike avatar Apr 22 '21 06:04 Kernopike