wsld freeses after connecting(?) to wsldhost

[kanayaya]

Steps to reproduce:
have

this version of Windows,
Ubuntu 22.04.1 LTS (GNU/Linux 5.10.102.1-microsoft-standard-WSL2 x86_64)

First i downloaded wsldhost.exe and launched it with "C:\vsock\wsldhost.exe --daemon --display localhost:6000" in powershell
launch vcxsrv with "-port 6000"

then added ".wsld.toml" with x11 option only

then added automatization code to ".profile"

"wsl --shutdown" in ps

when "debugging" echo in while cicle ended ,

call "xset q",
output:

output of standard display is below:

ofcourse wsl apps don't launch
What am i doing wrong?

[nbdd0121]

If xset q returns output, it means that WSLD's X forwarding is working fine. What app are you trying to launch? Does xterm work?

[kanayaya]

it freezes, called from both sides (windows and wsl)


also i tried dolphin and xeyes. same result

ok, wsld side is working, so it means the problem is on windows side, wsldhost.exe?
it doesn't provide display info from vcxsrv to "xset q" command?

I did not build wslhost.exe, just downloaded newest release but built wsld using cargo, can it make errors?

[kanayaya]

maybe i should use -vmid {00000000-0000-0000-0000-000000000000} -vsockport 6000 in vcxsrv launcher?
https://gist.github.com/iamjay/78ab76a0af0173d6047c7800c847f035

[nbdd0121]

No that works with Hyper-V VM but not WSL. Did you launch wsldhost with admin privilege?

[kanayaya]

i think i did. at least i opened PS with admin privilege, so it should run anythingg with it?

[kanayaya]

Could you please build something like "debugging" wsldhost.exe , with prints in right places
Something like "successfuly connected to vcxsrv", "wsld connection established" , and others. Or even with detailed log. It could help with collecting errors and issues on various machines.
Sorry that I don't know neither rust nor your code structure and how it works

[kanayaya]

ah, it also sees screen resolution. it may be that problem is in vcxsrv

[kanayaya]

also it doesn't connect until second terminal is opened. maybe it's some sort of glitch or bug in wsld or automating .profile script

[nbdd0121]

Can you try

[x11]
display = 0
force = true

in your config? WSL doesn't clean /tmp, so sometimes WSLD will have issue creating the socket...

[kanayaya]

I will try. In wsld.toml, right?

[kanayaya]

Aaaaaaand it just works!!!! Thank you so much
What's the issue with cleaning /tmp? Could it be fixed with some bash script?

[nbdd0121]

One approach would be to mount /tmp with tmpfs in your fstab.

[kanayaya]

Will try and write back with all steps. Thank you

[Ruborcalor]

Hello, were you able to make a list of steps? I think I am facing the same problem you did

[isaac84]

@Ruborcalor , I was running into the same issue though I think mine might be related to my corporate env. So, I switched away from WSLD and am now using socat combined with vcxsrv, just got it working

socat 1.7.4.1
VcXsrv 1.20.14.0

1. Removed all the .X* files from /tmp
2. Re-created the /tmp/.X11-unix folder
3. Use socat to redirect the display to VSOCKS run inside WSL socat -b65536 UNIX-LISTEN:/tmp/.X11-unix/X0,fork,mode=777 VSOCK-CONNECT:2:6000
4. export LIBGL_ALWAYS_INDIRECT=1
5. export DISPLAY=:0.0
6. Get VMID 00000000-0000-0000-0000-000000000000 need to run with admin in cmd hcsdiag list note. changes each time WSL restarts
7. Launch VcXsrv with the VSOCK paramaters eg. vcxsrv.exe -vmid {WSL id from step 4 above} -vsockport 6000 -multiwindow -clipboard -wgl -dpi auto
8. Test with xterm or xset q

[nbdd0121]

@isaac84 does the force=true workaround above not work for you?

[Ruborcalor]

Thanks @isaac84 , I ended up finding another solution.

@nbdd0121 , for me the force=true workaround didn't solve the problem on its own. My fix was to use

export DISPLAY="`grep nameserver /etc/resolv.conf | sed 's/nameserver //'`:0"

instead of export DISPLAY=:0

[nbdd0121]

That approach will cause all your X connections to drop when you resume from sleep, or when network status changes (the reason that I created wsld in the first place).

[Ruborcalor]

That approach will cause all your X connections to drop when you resume from sleep, or when network status changes (the reason that I created wsld in the first place).

I see... Then I guess I haven't been able to resolve this issue. force=true does not fix it for me in the way that I tried

[isaac84]

@Ruborcalor No force=true didn't work for me, and as @nbdd0121 said specifying the hostname or IP is no good because that uses TCP.

I could see it was trying to work VcXsrv was saying there was '1 client' when I moused over the Taskbar icon while trying to launch an X app. But the window wouldn't actually render. xterm, xset etc command would just 'hang' in the terminal.

I figured it must be related to my corporate env, firewall, AV or elevated privileges it seemed like something was blocking the traffic. So discovered the other solution above as my workaround to the sleep TCP issue.

[isaac84]

I also don't think I'm on the very latest wsl as wsl --update fails with a Catastrophic Error which I believe it's related to not having a 'local admin' account. I only have the elevated privileges in my corporate env. #cybersecurity ftw 🙄

[nbdd0121]

The privilege in wsl (and thus wsld) is pretty complicated. Vsock connection must be made from the user who starts wsl, and hcsdiag (or the equivalent API used in wsld) must be made with admin privilege. So if the user doesn't have admin privilege, then wsld can't work.