leojrfs commented 4 years ago

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 leo@12.12.12.12 port 22
Connection ready. Setting up display...
...timed out.

It doesnt start the X11 session:

leo@linux:~> echo $DISPLAY

joelspadin commented 4 years ago

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 commented 4 years ago

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.

leojrfs commented 4 years ago

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.

joelspadin commented 4 years ago

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:

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
```
Did DISPLAY get set in the terminal you're running these from?
Does something like "x11 accept: 127.0.0.1" get logged in the "Remote X11 (SSH)" output when you run a GUI program?
Is your X server running?
Does your remoteX11.display setting match the display number on which your X server is listening?

leojrfs commented 4 years ago

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 leo@12.12.12.12 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

yes, it works with when not using your extension.
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".
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
```
yes.
yes.

joelspadin commented 4 years ago

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.

hyt589 commented 4 years ago

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

joelspadin commented 4 years ago

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.

hyt589 commented 4 years ago

That sounds about right

olixu commented 4 years ago

That sounds about right

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

joelspadin commented 3 years ago

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?

leojrfs commented 3 years ago

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.

ddzhang3 commented 3 years ago

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 localsetting is:

2.1 the remote setting 1

or 2.2 the remote setting 2

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

Kernopike commented 3 years ago

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 localsetting is:

2.1 the remote setting 1

or 2.2 the remote setting 2

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

joelspadin / vscode-remote-x11

Cant set up display #7

36

36