Provide a way to positively detect WSL from an app compiled on Linux.

[dmiller-nmap]

I understand that support is always improving, but it seems unlikely that the specific network functionality (raw sockets, packet sniffing, netlink routes) required by Nmap will ever be supported in WSL/BashOnWindows. We would like to be able to detect WSL and provide users with a helpful message pointing them to our Windows-native build, while allowing our app to continue until the first crash/error.

Is there any stable, predictable method for detecting whether our built-on-Linux program is being run on Windows Subsystem for Linux?

[therealkenc]

Can't speculate on 'stable', but /proc/version has the string 'Microsoft' which seems a pretty safe bet.

[benhillis]

@therealkenc For the time being this is probably the best way to do it. I can't promise that we'll never change the content of these ProcFs files, but I think it's unlikely we'll change it to something that doesn't contain "Microsoft" or "WSL".

/proc/sys/kernel/osrelease
/proc/version

[fpqc]

@benhillis Do you guys over at Microsoft think you might ever support any/most/all of this low-level functionality used by nmap, eventually, in the (distant) future? Are there reasons in principle why you wouldn't want to or couldn't realistically support them?

[benhillis]

@fpqc There's a lot of surface areas and features to cover in limited time. The best way to help us prioritize work is by adding items to our User Voice page.

[fpqc]

@benhillis Yes absolutely you only have a limited time before the Anniversary update for Win10. I was just asking if the team over at Microsoft is planning on eventually seeing the project through to something on which the whole of the Linux userland can run (albeit maybe sometimes requiring tweaks). I mean, of course, Microsoft is a business, not a charity, and ultimately development will continue only if WSL meets business goals, but I was just asking whether the current plan is that development will continue by the WSL team improving compatibility for the foreseeable future.

I think WSL is really Windows 10's new "Killer App" (to use some cliched marketing lingo), and I personally know several people already who have moved (or are prepared to move) back to a Windows ecosystem from Linux because it's such an exciting project.

My biggest worry is that MS is going to take the project to something like 85% completion and then let it stagnate. WSL is something for which I would be willing to pay and for which my company would also be willing to pay, so I hope that development will continue past the anniversary release.

[benhillis]

@fpqc This question is definitely above my pay-grade but I'll try to answer as best I can.

I will say that as a developer on this feature I'm excited about the future of the project don't see it stagnating any time soon. We have some exciting things planned that make me optimistic about the future of our technology.

Thank you for your kind words. I'm sorry if I'm being somewhat vague but I'm trying to err on the side of not putting my foot in my mouth :)

[benhillis]

Closing this out since the discussion has run its course.

[haydentech]

It would be great if someone would update config.guess to detect Ubuntu on Windows. Currently, Ubuntu and Ubuntu-on-Windows return identical results.

[fpqc]

@haydentech For now, it's better not to mainline patches to add WSL support, because it will start fudging tests that the devs would like to solve by improving their driver. The best way to test that is real-world usage, with software hitting all of the syscalls we would expect on a real Linux system. The team is planning to implement unimplemented syscalls and fix buggy ones.

[therealkenc]

It would be great if someone would update config.guess

Unfortunately that doesn't work, because the header files (both kernel and glibc) lie by design. "It's a feature". So, say you push a config.guess patch to savanah to return x86_64-pc-wslwin-gnu, and it gets accepted by the FSF. But, then what.

That won't (for example) make PulseAudio (#486) realize that PTHREAD_PRIO_INHERIT is defined in the pthread.h header, but said feature does not actually work on the platform. You are going to have to push a patch to PA's ax_pthread.m4 too. And if you are going to patch PA to teach it about pc-wslwin-gnu, well... might as well be checking /proc/version. No one pushes a compile-time platform check like that mind you, because Stephen is liable fix the thing without notice.

[haydentech]

@therealkenc I don't expect a config.guess change to magically fix all problems resulting from differences in the 2 platforms. But it would fix my build problem, for one, and be a basis for future enhancements in other products. Right now, there is nothing to build on. Having config.guess return the same result for the two platforms is nonsensical.

[sunilmut]

I echo @fpqc's sentiment above

@fpqc - Regarding your comment, and specifically about raw sockets, the problem is that Windows does not natively support AF_PACKET socket domain. The functionality is exposed through other means on Windows because there are nmap tools on the internet that works on Windows. But, mapping AF_PACKET directly over that functionality is not feasible because of our commitment to compatibility. We are seriously discussing with the core networking team to light up these scenarios, now that it is pretty high on user voice (thanks for the feedback). As @benhillis mentions, some of these will take time given the surface area. Things are not out of reach technically, if there is demand.

[therealkenc]

@therealkenc ... Having config.guess return the same result for the two platforms is nonsensical.

That is one thesis. But it isn't me or Microsoft you have to convince. You need to convince the GNU maintainers to accept your patch that adds the new triplet.

[BeErikk]

uname -r | sed -n 's/.*\( *Microsoft *\).*/\1/p'

will output "Microsoft"
Guess that will be pretty unique for WSL :D

[black7375]

This method does not use external processes.
https://gist.github.com/abl/d004dcad84a16ddd670f5337ba5b896d

if [[ -f "/mnt/c/WINDOWS/system32/wsl.exe" ]]; then
  # We're in WSL, which defaults to umask 0 and causes issues with compaudit
  umask 0022
fi

[therealkenc]

if [[ -f "/mnt/c/WINDOWS/system32/wsl.exe" ]]; then

That method assumes that the 9p automount point hasn't be changed or turned off with wsl.conf. Use the osversion. There is a more recent landing zone at #4555.

[Lazerbeak12345]

What about checking for /etc/wsl.conf as a fallback if the directory /run/WSL doesn't exist? It sounds like you would need at least one of those two filesystem nodes.

Something like this bash code is what I have in mind:

if [[ -f "/run/WSL" ]] || [[ -f "/etc/wsl.conf" ]]; then
    echo "is wsl"
fi

[bluca]

WSL in /proc/sys/kernel/osrelease is supported everywhere and cannot be broken by the distro image, since it's provided by the kernel.

[josesa-xx]

Since the distinction between WSL1 and WSL2 is that the first runs inside a container while the second runs in a virtual machine, we can make use of "systemd-detect-virt --container" to differentiate from both environments.

if [ -n "${WSL_DISTRO_NAME}" ]; then
  # In WSL but which one?
  virt_container="$(systemd-detect-virt --container)"
  case ${virt_container} in
    wsl)
      echo "This is WSL 1"
      ;;
    none)
      echo "This is WSL 2"
      ;;
    *)
      echo "Don't known ${virt_container}"
      ;;
  esac
fi

[mlromramse]

What about systemd-detect-virt?
Responds with wsl

[RokeJulianLockhart]

@mlromramse, and returns none on bare metal. That's not bad.

PS /home/rokejulianlockhart> systemd-detect-virt
none
NativeCommandExitException: Program "systemd-detect-virt" ended with non-zero exit code: 1.
PS /home/rokejulianlockhart>