WSLD does not seem to work with Ubuntu 22.04

[PauliusMorku]

Hi! Today I spent the whole day trying to figure out why Ubuntu 22.04 is not working with WSLD, but with no success. It's a fresh installation of Ubuntu, since I wanted to upgrade. Initially, I assumed that something changed within this Ubuntu version and it is not compatible with this method of forwarding GUI (something with wayland support). However, I manage to make it work with x410 and socat via VSOCK, and with conventional forwarding via network using x410, Xming, vcxsrv, MobaXterm. WSLg was disabled and should not have interfered.
When I run any program, I can see no error as if it was successfully running in the background with missing GUI. I have noticed that x410 in floating desktop mode receives black screen as soon as I run something, which means that there is some sort of connection.
I find WSLD the most reliable way of getting GUI in windows and would not want to swap it for anything else, so would be really awesome if this could be somehow fixed.
Best,
Paulius

[nbdd0121]

Does /tmp/.X0-lock or /tmp/.X11-unix/X0 exist?

[PauliusMorku]

Both exist

[nbdd0121]

Can you check if the content of /tmp/.X0-lock matches the PID of WSLD?

[PauliusMorku]

Yes, the PID matches one of the WSLD processes, which is 43.

[nbdd0121]

When I run any program, I can see no error as if it was successfully running in the background with missing GUI. I have noticed that x410 in floating desktop mode receives black screen as soon as I run something, which means that there is some sort of connection.

This makes me wonder if there might be some environment variable interfering. Can you share the your env output?

Also, have you tested some basic x programs, e.g. xeyes?

[PauliusMorku]

Yes, I tried basic apps like xeyes. Here is my env:
pmorku@NA-LT-276:~$ env SHELL=/bin/bash WSL_DISTRO_NAME=Ubuntu22 WT_SESSION=5748cb07-2bec-4209-bc2c-090c9e0418b9 NAME=NA-LT-276 PWD=/home/pmorku LOGNAME=pmorku HOME=/home/pmorku LANG=en_US.UTF-8 WSL_INTEROP=/run/WSL/30_interop LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36: LESSCLOSE=/usr/bin/lesspipe %s %s TERM=xterm-256color LESSOPEN=| /usr/bin/lesspipe %s USER=pmorku DISPLAY=:0 SHLVL=1 WSLENV=WT_SESSION::WT_PROFILE_ID XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Program Files/WindowsApps/Microsoft.WindowsTerminal_1.17.11461.0_x64__8wekyb3d8bbwe:/mnt/c/Program Files/Python311/Scripts/:/mnt/c/Program Files/Python311/:/mnt/c/Python311/Scripts/:/mnt/c/Python311/:/mnt/c/Program Files/Eclipse Adoptium/jre-19.0.1.10-hotspot/bin:/mnt/c/Program Files (x86)/Common Files/Oracle/Java/javapath:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/ProgramData/chocolatey/bin:/mnt/c/Program Files/gs/gs9.56.1/bin:/mnt/c/Program Files/Git/cmd:/mnt/c/Program Files/LLVM/bin:/mnt/c/Program Files/Graphviz/bin:/mnt/c/Program Files (x86)/STMicroelectronics/STM32 ST-LINK Utility/ST-LINK Utility:/mnt/c/Program Files/PuTTY/:/mnt/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/:/mnt/c/Program Files/usbipd-win/:/mnt/c/Users/pauliusm.admin/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/pauliusm.admin/AppData/Local/Programs/Microsoft VS Code/bin:/snap/bin HOSTTYPE=x86_64 WT_PROFILE_ID={02afa160-6310-4a42-a004-56032c7651e7} _=/usr/bin/env

[PauliusMorku]

Additional piece of information: when I kill wsldhost.exe on Windows then opened applications throw:
Gtk-WARNING **: 22:37:48.269: cannot open display: :0
This also indicates that wsldhost.exe is communicating with WSL.
It also seems that apps are reacting to x-server being open on Windows, but it varies from app to app.

[nbdd0121]

I just did a fresh installation of Windows + WSL + Ubuntu 22.04, but cannot reproduce it. The X forwarding works fine for me.

Could you give the exact command lines / configs that you are using for wsldhost and wsld? It'll also be helpful if you can provide the X server that you are using and its version.

[PauliusMorku]

Just did completely fresh install of wsl again just to test it, same behavior. However, I have no possibility for a fresh windows install. For this latest experiment, I did not use any configs except for .wsld.toml (exactly same contents as described in your repo). Running wsld with sudo. From windows side tried to run it with and without admin rights, with and without --daemon. As I mentioned, I tried different x server programs, they all behaved more or less the same. But I mainly use x410.
wsldhost.exe -> version_nightly-2023-03-31

[nbdd0121]

Try launching wsld without any command line and execute xset q in WSL.

[PauliusMorku]

Not entirely sure exactly what did you mean by "launching wsld without any command line" but I tried to execute xset q and it behaved like any other app: kept executing without returning any output or error and initiated black screen in x410 floating window mode.

[PauliusMorku]

I have found something out. So I tried to install WSLD on another instance of Ubuntu 20.04.5, and I realized that it behaves exactly the same way as Ubuntu 22.04. Then I got very curious what's the reason for that. Then I thought maybe it is something to do with WSLD binary on Linux side. I tried to copy the old binary from my old Ubuntu 20 setup which is working fine to the new installations and eureka, this old binary works even on 22.04. Earlier I was probably using the prebuild WSLD binary from releases, and for recent installations I used cargo to get and compile this binary (honestly I forgot that there was a precompiled binary available). I compared the sizes between these binaries, and they are drastically different (the one in home folder is the working one).

[nbdd0121]

Ah! When I tried to reproduce locally I either used the prebuilt binary or did a cargo build --release in the repository. A direct cargo install will ignore the Cargo.lock file and always get latest dependency. So it could be one of a dependency upgrade breaks wsld. Thanks for the pointer and I'll investigate toward that direction.

I think the size difference is due to debugging symbol being stripped on the prebuilt release, so it's probably not really relevant.

[nbdd0121]

I can reproduce the bug locally with tokio >= 1.21. It seems one of their optimisation strategy breaks wsld, although what they're doing is allowed per epoll documentation. Currently looking into this, might be a HyperV driver bug..

[nbdd0121]

I can confirm that this is a Linux kernel bug. hvs_stream_dequeue does not drain the socket (https://elixir.bootlin.com/linux/v6.4.1/source/net/vmw_vsock/hyperv_transport.c#L626) before returning, while epoll documentation says that doing so should drain the socket (https://man7.org/linux/man-pages/man7/epoll.7.html#:~:text=For%20stream%2Doriented%20files).

I guess in the mean time I'll need to pin tokio's version to 1.20 as a workaround.