-
Notifications
You must be signed in to change notification settings - Fork 822
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide a way to positively detect WSL from an app compiled on Linux. #423
Comments
Can't speculate on 'stable', but /proc/version has the string 'Microsoft' which seems a pretty safe bet. |
@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".
|
@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? |
@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. |
@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. |
@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 :) |
Windows 10 implements Windows Subsystem for Linux (WSL). WSL does not implement support for SIGSEGV handler, which is used inside is_vmware_platform(). As a result, lscpu crashes there. Implement WSL detection, and as a side effect, work around the crash. Note that none of existing virtualization types exactly matches. But the the closest would be "container". References: Provide a way to positively detect WSL from an app compiled on Linux. microsoft/WSL#423 missing support for SIGSEGV handler microsoft/WSL#1637 Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
Closing this out since the discussion has run its course. |
Windows 10 implements Windows Subsystem for Linux (WSL). WSL does not implement support for SIGSEGV handler, which is used inside is_vmware_platform(). As a result, lscpu crashes there. Implement WSL detection, and as a side effect, work around the crash. Note that none of existing virtualization types exactly matches. But the the closest would be "container". References: Provide a way to positively detect WSL from an app compiled on Linux. microsoft/WSL#423 missing support for SIGSEGV handler microsoft/WSL#1637 Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
It would be great if someone would update config.guess to detect Ubuntu on Windows. Currently, Ubuntu and Ubuntu-on-Windows return identical results. |
@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. |
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 That won't (for example) make PulseAudio (#486) realize that |
@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. |
I echo @fpqc's sentiment above @fpqc - Regarding your comment, and specifically about raw sockets, the problem is that Windows does not natively support |
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. |
will output "Microsoft" |
This method does not use external processes. 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 |
That method assumes that the 9p automount point hasn't be changed or turned off with |
What about checking for Something like this bash code is what I have in mind: if [[ -f "/run/WSL" ]] || [[ -f "/etc/wsl.conf" ]]; then
echo "is wsl"
fi |
|
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 |
This comment was marked as resolved.
This comment was marked as resolved.
What about |
@mlromramse, and returns
|
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?
The text was updated successfully, but these errors were encountered: