TTY issue when running Win32 process from WSL

[robwiss]

• Your Windows build number: Microsoft Windows [Version 10.0.15063]

• What you're doing and what's happening:
  from wsl bash:

$ /mnt/c/HashiCorp/Vagrant/bin/vagrant.exe
stdin is not a tty

The version of vagrant installed is 1.9.7. It is the 64-bit Windows one.

• What's wrong / what should be happening instead:
  The help output should print for vagrant.

• Strace of the failing command, if applicable:

execve("/mnt/c/HashiCorp/Vagrant/bin/vagrant.exe", ["/mnt/c/HashiCorp/Vagrant/bin/vag"...], [/* 19 vars */]) = 0
brk(NULL)                               = 0x7fffcb79e000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff108af0000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=38289, ...}) = 0
mmap(NULL, 38289, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff108af2000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...}) = 0
mmap(NULL, 3967392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ff108430000
mprotect(0x7ff1085ef000, 2097152, PROT_NONE) = 0
mmap(0x7ff1087ef000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bf000) = 0x7ff1087ef000
mmap(0x7ff1087f5000, 14752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ff1087f5000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff108ae0000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff108ad0000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff108ac0000
arch_prctl(ARCH_SET_FS, 0x7ff108ad0700) = 0
mprotect(0x7ff1087ef000, 16384, PROT_READ) = 0
mprotect(0x7ff108e09000, 4096, PROT_READ) = 0
mprotect(0x7ff108a25000, 4096, PROT_READ) = 0
munmap(0x7ff108af2000, 38289)           = 0
getpid()                                = 98
brk(NULL)                               = 0x7fffcb79e000
brk(0x7fffcb7bf000)                     = 0x7fffcb7bf000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1668976, ...}) = 0
mmap(NULL, 1668976, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff10888d000
close(3)                                = 0
getcwd("/mnt/c/Users/robwiss", 4096)  = 23
open("/dev/lxssclient", O_RDWR)         = 3
ioctl(3, _IOC(0, 0x00, 0x2f, 0x22), 0x7fffd4004440) = 0
open("/mnt/c/HashiCorp/Vagrant/bin/vagrant.exe", O_RDONLY) = 5
ioctl(3, _IOC(0, 0x00, 0x3f, 0x22), 0x7fffd40042f0) = 0
close(5)                                = 0
open("/mnt/c/Users/robwiss", O_RDONLY) = 5
ioctl(3, _IOC(0, 0x00, 0x3f, 0x22), 0x7fffd40042f0) = 0
close(5)                                = 0
ioctl(4, _IOC(0, 0x00, 0x97, 0x22), 0x7fffd4004398) = 0
ioctl(4, _IOC(0, 0x00, 0xb7, 0x22), 0x7fffd4004390) = 0
ioctl(4, _IOC(0, 0x00, 0xb7, 0x22), 0x7fffd4004390) = 0
ioctl(4, _IOC(0, 0x00, 0xb7, 0x22), 0x7fffd4004390) = 0
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0C\0\0\0\0\0\0\0"..., 177) = 177
read(4, "\0\0\0\0\0\0\0\0009\0\0\0\0\0\0\0", 16) = 16
ioctl(4, _IOC(0, 0x00, 0x9b, 0x22), 0x7fffd4004438) = 0
write(4, "\0\0\0\0\0\0\0\0009\0\0\0\0\0\0\0", 16) = 16
ioctl(5, _IOC(0, 0x00, 0xbf, 0x22), 0x7fffd4004430) = 0
close(3)                                = 0
close(4)                                = 0
close(5)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

lxcore.zip

• Additional info:
  As far as I can tell this error began happening without any apparent cause. I closed a shell, opened a new one, entered a vagrant command, and began receiving this error. Prior to that vagrant was functioning correctly from within the WSL. The error began on August 7th. The command functions correctly on coworker's machines who are running the same version of windows and vagrant as I am. I'm posting it here as I imagine it is related to the way pipes are connected between WSL and Win32 processes.

[benhillis]

When NT processes are launched via interop the stdin, stdout, and stderr handles of the calling process are marshalled over to NT as handles. Handles are created on the NT side to be passed to the CreateProcess API to be used as stdin, stdout, and stderr. These handles are mostly reported as FILE_DEVICE_NAMED_PIPE (including tty as in your example). Vagrant is obviously expecting a stdin that is a FILE_DEVICE_CONSOLE. It's on our backlog to improve support for this scenario. Some related issues: #2370, #1433.

[therealkenc]

For this one it might legitimately be worth talking to the Vagrant people. With enough hand waving one can think of use cases (completely unrelated WSL interop) in Windows where you might want to talk to Vagrant with a Windows named pipe. Which is to say, maybe a WSL work-around here has general applicability. Or, theoretical applicability if not actual applicability. I could be wrong (haven't looked at the code), but it costs nothing to ask.

[robwiss]

@therealkenc perhaps that is what happens when vagrant is launched from python:

Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.check_output('vagrant')
stdout is not a tty
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\subprocess.py", line 219, in check_output
    raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command 'vagrant' returned non-zero exit status 1

an examination of the source for check_output reveals:

    process = Popen(stdout=PIPE, *popenargs, **kwargs)
    output, unused_err = process.communicate()
    retcode = process.poll()

I don't know enough about the cpython implementation on windows to know if that pipe is a named pipe.

[raupie]

Trying to use WSL and Docker for Windows.

docker.exe exec -it ubuntu /bin/bash returns

the input device is not a TTY. If you are using mintty, try prefixing the command with winpty

[aleksijohansson]

+1 for this issue!

[shimizukawa]

+1.
I want to use ssh.exe from wsl world because ssh.exe uses ssh-agent service on the Windows host.

[therealkenc]

Just tried the ssh.exe scenario on skip-ahead Insiders 17627 and the FILE_TYPE_PIPE fail appears to be addressed along with #2370. Be nice if folks can confirm vagrant other scenarios (I don't have vagrant.exe handy), but it is relatively safe to say those will be good too. Note this won't make the Spring Creators Update being released shortly.