Resolving interop-issue while running wsl-vpnkit as a systemd-service in own wsl-distro about wsl-vpnkit HOT 12 OPEN

I used @dabeck81 script and modified it for the distro setup. I only did the following:

Create the script:

/usr/local/bin/start-vpn-kit.sh

#!/bin/sh

export WSL_INTEROP=
for socket in $(ls /run/WSL|sort -n); do
   if ss -elx | grep "$socket"; then
      export WSL_INTEROP=/run/WSL/$socket
   else
      rm $socket
   fi
done

# also start wsl-vpnkit
/mnt/c/Windows/system32/wsl.exe -d wsl-vpnkit --cd /app wsl-vpnkit

Don't forget to chmod +x

Modify the service to use the script:

/etc/systemd/system/wsl-vpnkit.service

[Unit]
Description=wsl-vpnkit
After=network.target

[Service]
# for wsl-vpnkit setup as a distro
ExecStart=/usr/local/bin/start-vpn-kit.sh

Restart=always
KillMode=mixed

[Install]
WantedBy=multi-user.target

That was already sufficient to get my setup working again.

from wsl-vpnkit.

I have created a pull-request to resolve my issue: #250
This does the necessary to set the WSL_INTEROP value correct inline in the wsl-vpnkit script.
No need anymore for having an extra script running before the service is started.

And most of all, it is self-healing, so if you have more than one bash-terminals running and you would close the process linked to the WSL-INTEROP-socket, that will be detected and will switch over to another running socket

from wsl-vpnkit.

And there it is https://gist.github.com/grepwood/8e42b2bd0e56cd964cbd77b6d182aff0

from wsl-vpnkit.

I've read @OneBlue's post and I have a dastardly idea how to cheese the system for our gain. I'll let you know if it worked.

from wsl-vpnkit.

Hi @dabeck81!

I encountered the same problem with wsl-vpnkit. Thanks to your instructions above I was able to get it running partially, but not as I'd expect. It works as long as I start the systemd service manually with sudo, but not on start-up of my WSL distribution (after I did systemctl enable wsl-vpnkit). Then the "wsl-gvproxy.exe not executable" error shows up again.

I understand you implemented the "standalone script" setup variant mentioned in the top-level README.

What needs to be modified in addition to your fix that wsl-vpnkit doesn't run into the "wsl-gvproxy.exe not executable" issue when using the "distro setup"?

from wsl-vpnkit.

Hi @dabeck81!

I encountered the same problem with wsl-vpnkit. Thanks to your instructions above I was able to get it running partially, but not as I'd expect. It works as long as I start the systemd service manually with sudo, but not on start-up of my WSL distribution (after I did systemctl enable wsl-vpnkit). Then the "wsl-gvproxy.exe not executable" error shows up again.

I understand you implemented the "standalone script" setup variant mentioned in the top-level README.

What needs to be modified in addition to your fix that wsl-vpnkit doesn't run into the "wsl-gvproxy.exe not executable" issue when using the "distro setup"?

I have to correct my above comment, it is my bad.
I did not copy @dabeck81 's wsl-vpnkit.service exactly, for instance, I missed the Type=idle.

Also, my experience might also be impaired by some other issue I encountered with the local proxy px I use in combination - see px 0.8.4: PAC configuration seems to cause unstable behaviour. Maybe there is an interdependency with this.

So, to conclude, it seems like @dabeck81 's solution works, indeed!

However, I'm still interested in the "distro setup".

from wsl-vpnkit.

@dabeck81 your PR assumes that your interop socket will live forever which is just not true. The stability of your solution will literally hang on the skin of your Bash terminal's teeth. If you close all those terminals, you will ensure that wsl-vpnkit will never find a working interop socket until you manually restart the service from a new terminal.

I think a better solution would be to be able to request and free WSL interop sockets much like memory is requested and freed in C. For this purpose, I have created microsoft/WSL#10812 and described my use case and the findings myself and my team made.

Secondly, I don't think WSL_INTEROP="/run/WSL/$(ls /run/WSL | sort -n | tail -n 1)" is going to produce reliable results on faster machines. On my machine, the sockets created by /sbin/init (systemd, PID 1), /init (child of systemd, PID 2) and my terminal (PID whatever), are created within the same second. A more reliable way I think would be to compare the sockets' creation mtime, which is accurate to 10^-10th of a second:

WSL_INTEROP=$(find /run/WSL -type s -printf "%T+ %p\n" | sort -nk1 | tail -n1 | awk '{print $2}')

I'll be honest. I run into this scenario where there is no valid interop socket on a daily basis, because I use qterminal. I don't want to use PowerShell's terminal because it's slow and strange, and cmd.exe is just feature-famished - the choice is obvious for me. I found that Qt apps in WSL2 have a bug where the first time they start in the runtime of a WSL2 instance, the GUI of all Qt apps is not interactive. You need to shut them all down and start one of them again, and then all Qt apps will be interactive until you reboot the WSL2 instance. This is how the cookie crumbles on my end :(

from wsl-vpnkit.

@grepwood ,
I just ran your proposal based upon the mtime of creation of the socket. Your solution is equivalent to mine:

• Yours looks to the creation-time of the socket
• Mine looks for the highest PID. Because the _interop socket holds the PID of the process responsable for creating the socket, you will always have the socket with the highest PID and thus the last created socket. No need to include the creationTime this way

from wsl-vpnkit.

Any word on getting these PRs approved/merged and a new version out?

from wsl-vpnkit.

I've thrown in on microsoft/WSL#10812, providing the logs they requested.

Based on my cursory examination, it looks like @grepwood has it exactly right: the /run/WSL/1_interop socket is magical somehow, and won't allow other processes to open Windows apps. This is why the systemd script is failing, and why the solutions to "borrow" a socket from a terminal work.

from wsl-vpnkit.

Any word on getting these PRs approved/merged and a new version out?

I am affraid only @sakai135 is able to approve and merge the Pull Request, so we will need to wait for that

from wsl-vpnkit.

And there it is https://gist.github.com/grepwood/8e42b2bd0e56cd964cbd77b6d182aff0

"dastardly" was right!

from wsl-vpnkit.