Node: "Implement me. Unknown stdin file type!" error thrown when running headless process in win32

[jakelauer]

• Version: 6.10.0
• Platform: Windows 7 x86
• Subsystem:

Hi there - I encountered this while attempting to run PostCSS commands via the PostCSS-CLI command line implementation.

Note - I have only encountered this error in Windows 7. Windows 10 seems to work fine.

The exact error is as shown:

internal/process/stdio.js:82

        throw new Error('Implement me. Unknown stdin file type!');
        ^
    Error: Implement me. Unknown stdin file type!
    at process.getStdin [as stdin] (internal/process/stdio.js:82:15)
    at Object.<anonymous> (C:\Users\myusername\AppData\Local\Microsoft\VisualStudio\14.0\Extensions\5xs3acz0.hfk\Resources\nodejs\node_modules\get-stdin\index.js:2:20)

    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)

    at Object.<anonymous> (C:\Users\myusername\AppData\Local\Microsoft\VisualStudio\14.0\Extensions\5xs3acz0.hfk\Resources\nodejs\node_modules\postcss-cli\index.js:6:15)

I found a similar issue in Angular here: https://github.com/angular/angular-cli/issues/4870

They solved it like this:
https://github.com/angular/angular-cli/commit/4af7a429205636e0a7a2fb6675cb4f389f80923d

Let me know if you need more information - I am very new to Node so you might need to simplify any questions you have for me.

[addaleax]

/cc @nodejs/platform-windows

[seishun]

Can you provide a minimal test case that reproduces the issue, preferably without using third-party libraries?

[addaleax]

The commit message of https://github.com/angular/angular-cli/commit/4af7a429205636e0a7a2fb6675cb4f389f80923d sounds like a good clue:

When running in a headless process in win32 the lack of process.stdin throws an error.

I can’t test that myself, though.

[seishun]

That doesn't say much. What does "running in a headless process" mean exactly?

[jakelauer]

I'm sorry for the lack of detail - I'm kind of blind to the details of the issue. I'm extra new to Node, so I can't really give you an example without a third-party plugin. I am reproducing the issue while running PostCSS using their postcss-cli module via the command line in Windows, like this:

"cmd /c cd /d [node directory] postcss [arguments]"

Again, apologies for the briefness! I know this is not a lot to go on. I will provide more details if I can as I try to deal with the issue.

[seishun]

In that case I think it would be more appropriate to post the issue in the PostCSS repo.

[jakelauer]

I originally posted it in the repo of the module that actually threw the error (get-stdin): https://github.com/sindresorhus/get-stdin/issues/20

He directed me to post here as NodeJS did not provide code to handle the situation.

[addaleax]

Fwiw, this issue was opened because of https://github.com/sindresorhus/get-stdin/issues/20#issuecomment-283566914 (@jakelauer: Generally, it helps a lot if you could add cross-links when you open issues on multiple repositories!), and it looks to me like this is something that could/should be fixed in Node core.

[jakelauer]

@addaleax Thanks for the pointers :) I haven't had a lot of experience opening issues on GitHub either!

[jakelauer]

Interesting sidenote: I do not experience this in Windows 10

[gireeshpunathil]

I guess 'headless' here means either a non-console application or a windows service. In either case, node is started from a non-shell parent process with custom (or no) stdin. When node is started normally through shell, the C runtime makes sure that the stdin is created and supplied to the process, this is the responsibility of a parent if node is started through createProcess* calls.

The error message indicates that stdin (the fd 0 which node expects stdin to be at the start-up) is invalid, which leads all the suspecion to its creator process.

[addaleax]

Maybe Node should do something like https://github.com/nodejs/node/blob/cccc6d8545c0ebd83f934b9734f5605aaeb000f2/src/node.cc#L4137-L4147 for Windows, too? If that makes sense?

[gireeshpunathil]

@addaleax - yes, that makes sense to me - though this will not mitigate (I don't think we should mitigate an invalid descriptor scenario if the parent chose to give us a bad one) the issue, this will make sure that we make the right assertion at the right place.

Let me see if I can come up with a test scenario that fails node in the above manner

[scottaddie]

For what it's worth, myself and several others are experiencing the same issue with Yarn only on Windows 7. Windows 10 works fine. Specifically, the issue occurs when Yarn is invoked from Visual Studio 2015 or 2017's NPM Task Runner extension. See the Yarn issue logged here. Sure, I could submit a PR to fix Yarn, but it seems like the source of the problem is Node's handling of process.stdin on Windows 7 in a "headless" scenario.

[gireeshpunathil]

I tested with a parent, and with this sequence:

fclose(stdin);
CreateProcess(NULL, argv[1], NULL,NULL,FALSE,0,NULL,NULL,&si,&pi);

node fails in a similar manner:

D:\gireesh>Win32Project1.exe node.exe
node.js:777
          throw new Error('Implement me. Unknown stdin file type!');
          ^
Error: Implement me. Unknown stdin file type!
    at process.stdin (node.js:777:17)
    at startup (node.js:164:18)
    at node.js:1043:3

[seishun]

@gireeshpunathil Can you provide a full test case?

[gireeshpunathil]

@seishun - here it is:

#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#include <tchar.h>

void _tmain(int argc, TCHAR *argv[])
{
    STARTUPINFO si;
    PROCESS_INFORMATION pi;

    ZeroMemory(&si, sizeof(si));
    si.cb = sizeof(si);
    ZeroMemory(&pi, sizeof(pi));
    fclose(stdin);
    if (!CreateProcess(NULL,   // No module name (use command line)
        argv[1],        // Command line
        NULL,           // Process handle not inheritable
        NULL,           // Thread handle not inheritable
        FALSE,          // Set handle inheritance to FALSE
        0,              // No creation flags
        NULL,           // Use parent's environment block
        NULL,           // Use parent's starting directory 
        &si,            // Pointer to STARTUPINFO structure
        &pi)           // Pointer to PROCESS_INFORMATION structure
        )
    {
        printf("CreateProcess failed (%d).\n", GetLastError());
        return;
    }

    WaitForSingleObject(pi.hProcess, INFINITE);
    CloseHandle(pi.hProcess);
    CloseHandle(pi.hThread);
}

Needless to say, this need to be added in a "win 32 console application" project in Visual Studio, otherwise some of the headers as well as the linkage needs to be adjusted accordingly.

[seishun]

Well, I can reproduce the error with the above code. But I doubt this is what PostCSS does, as their code is 100% JavaScript.

This is the reason why I suggested to post this issue in the PostCSS repo. If the maintainers of PostCSS think this is a bug in Node.js, then they can post an issue here with a proper explanation.

[gireeshpunathil]

ok, sounds good.

[dcastro]

+1, I'm having the exact same issue hosting my node application (which deep down uses process.stdin) in IIS with iisnode (which runs in a headless process).

The problem can be narrowed down to getStdin() @ internal/process/stdio.js and tty_wrap.guessHandleType(0) returning "UNKNOWN" in Windows 7 and Windows Server 2012 RS.

[seishun]

@dcastro If you aren't using any libraries, can you provide steps to reproduce the issue?

[dcastro]

@seishun I'm using iisnode... it's a binary iis module, not a library, but I'm guessing you're looking for a demo with no dependencies whatsoever, right? If so, apologies, I don't have one nor do I know enough about node to come up with one. If a demo with iisnode would do, I'll be happy to provide one.

[gibfahn]

If a demo with iisnode would do, I'll be happy to provide one.

@dcastro A demo with no dependencies is ideal, but steps to reproduce with iisnode is better than nothing, so please do.

[soda0289]

I have the same issue in Bash for Windows 10. There is a code example in this issue:
https://github.com/Microsoft/BashOnWindows/issues/1774

[houd1ni]

Hello! Any progress here?
I've suddenly got this after some times when it worked (running husky):

internal/process/stdio.js:90
        throw new errors.Error('ERR_UNKNOWN_STDIN_TYPE');
        ^

Error [ERR_UNKNOWN_STDIN_TYPE]: Unknown stdin file type
    at process.getStdin [as stdin] (internal/process/stdio.js:90:15)
    at bootstrap (/mnt/c/mylinux/node_modules/npm-run-all/bin/common/bootstrap.js:31:21)
    at Object.<anonymous> (/mnt/c/mylinux/node_modules/npm-run-all/bin/run-s/index.js:13:31)
    at Module._compile (module.js:660:30)
    at Object.Module._extensions..js (module.js:671:10)
    at Module.load (module.js:573:32)
    at tryModuleLoad (module.js:513:12)
    at Function.Module._load (module.js:505:3)
    at Function.Module.runMain (module.js:701:10)
    at startup (bootstrap_node.js:190:16)

[mindplay-dk]

I've got this problem too - see related issue here.

Tracking the issue through issues related to this WSL issue it looks like at least five projects ran into this problem and closed their issues with no resolution.

It would be really great to know if this is a regression, whether it's node or WSL, and so on?

I'd suggest to reopen this issue?

[bnoordhuis]

WSL is essentially a Linux emulator. If it works on Linux but not in WSL, then by definition it's a WSL bug.

[houd1ni]

@bnoordhuis At least, what could cause this bug from the node perspective?
We could fill an issue somewhere to WSL, having some debug information.

[bnoordhuis]

Take a look at uv_guess_handle() in deps/uv/src/unix/tty.c, it tries to detect what kind of object the file descriptor is (tty, socket, pipe, etc.)

[bnoordhuis]

Wait, I'll link you to it:
https://github.com/nodejs/node/blob/039cdebe81e232cae23acdfd8392a8149b718460/deps/uv/src/unix/tty.c#L292-L348

[mindplay-dk]

WSL is essentially a Linux emulator.

It's really not - it's running a real Ubuntu distro + some kernel/driver patches for interop.

If it works on Linux but not in WSL, then by definition it's a WSL bug

Not by definition, no - there are countless Linux distros, and if you look through the related issues, you'll find at least a few people are reporting the same error under other Linux distros. From what I could gather, the issue could not be narrowed down to WSL-only, and the issue was closed on the WSL issue tracker with the conclusion "This is not a bug in Bash on Windows so I will close this issue".

If you think this is incorrect, maybe ask them to reopen the issue?

[bnoordhuis]

It's an emulator in that it emulates the Linux system call interface. If you can reproduce the error with a real Linux kernel, then that's something we can look into to. If it only happens under WSL, it's a WSL bug.