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

jakelauer · 2017-03-02T15:21:48Z

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: angular/angular-cli#4870

They solved it like this:
angular/angular-cli@4af7a42

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.

The text was updated successfully, but these errors were encountered:

addaleax · 2017-03-02T15:23:33Z

/cc @nodejs/platform-windows

seishun · 2017-03-02T15:27:44Z

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

addaleax · 2017-03-02T15:31:02Z

The commit message of angular/angular-cli@4af7a42 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 · 2017-03-02T15:35:14Z

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

jakelauer · 2017-03-02T15:48:52Z

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 · 2017-03-02T15:51:13Z

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

jakelauer · 2017-03-02T15:54:23Z

I originally posted it in the repo of the module that actually threw the error (get-stdin): sindresorhus/get-stdin#20

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

addaleax · 2017-03-02T15:54:49Z

Fwiw, this issue was opened because of sindresorhus/get-stdin#20 (comment) (@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 · 2017-03-02T15:58:05Z

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

jakelauer · 2017-03-03T04:45:07Z

Interesting sidenote: I do not experience this in Windows 10

gireeshpunathil · 2017-03-04T14:39:24Z

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 · 2017-03-04T16:07:55Z

Maybe Node should do something like

node/src/node.cc

Lines 4137 to 4147 in cccc6d8

    
           for (int fd = STDIN_FILENO; fd <= STDERR_FILENO; fd += 1) { 
        
             struct stat ignored; 
        
             if (fstat(fd, &ignored) == 0) 
        
               continue; 
        
             // Anything but EBADF means something is seriously wrong.  We don't 
        
             // have to special-case EINTR, fstat() is not interruptible. 
        
             if (errno != EBADF) 
        
               ABORT(); 
        
             if (fd != open("/dev/null", O_RDWR)) 
        
               ABORT(); 
        
           }

for Windows, too? If that makes sense?

gireeshpunathil · 2017-03-05T02:50:44Z

@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 · 2017-03-05T02:52:07Z

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 · 2017-03-05T05:22:22Z

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 · 2017-03-05T16:41:00Z

@gireeshpunathil Can you provide a full test case?

gireeshpunathil · 2017-03-06T02:47:50Z

@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 · 2017-03-06T08:14:16Z

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 · 2017-03-06T09:10:11Z

ok, sounds good.

dcastro · 2017-03-08T11:27:47Z

+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 · 2017-03-08T11:37:34Z

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

dcastro · 2017-03-08T11:42:05Z

@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 · 2017-03-12T15:12:02Z

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 · 2017-03-13T18:23:36Z

I have the same issue in Bash for Windows 10. There is a code example in this issue:
microsoft/WSL#1774

Check that stdin, stdout and stderr are valid file descriptors on Windows. If not, reopen them with 'nul' file. Refs: nodejs#875 Fixes: nodejs#11656 PR-URL: nodejs#11863 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>

Check that stdin, stdout and stderr are valid file descriptors on Windows. If not, reopen them with 'nul' file. Refs: #875 Fixes: #11656 PR-URL: #11863 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>

Check that stdin, stdout and stderr are valid file descriptors on Windows. If not, reopen them with 'nul' file. Refs: nodejs/node#875 Fixes: nodejs/node#11656 PR-URL: nodejs/node#11863 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>

houd1ni · 2018-03-14T15:54:50Z

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 · 2018-04-13T09:28:10Z

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 · 2018-04-13T09:33:56Z

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

houd1ni · 2018-04-13T17:21:55Z

@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 · 2018-04-13T17:58:00Z

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 · 2018-04-13T18:00:57Z

Wait, I'll link you to it:

node/deps/uv/src/unix/tty.c

Lines 292 to 348 in 039cdeb

    
           uv_handle_type uv_guess_handle(uv_file file) { 
        
             struct sockaddr sa; 
        
             struct stat s; 
        
             socklen_t len; 
        
             int type; 
        
             if (file < 0) 
        
               return UV_UNKNOWN_HANDLE; 
        
             if (isatty(file)) 
        
               return UV_TTY; 
        
             if (fstat(file, &s)) 
        
               return UV_UNKNOWN_HANDLE; 
        
             if (S_ISREG(s.st_mode)) 
        
               return UV_FILE; 
        
             if (S_ISCHR(s.st_mode)) 
        
               return UV_FILE;  /* XXX UV_NAMED_PIPE? */ 
        
             if (S_ISFIFO(s.st_mode)) 
        
               return UV_NAMED_PIPE; 
        
             if (!S_ISSOCK(s.st_mode)) 
        
               return UV_UNKNOWN_HANDLE; 
        
             len = sizeof(type); 
        
             if (getsockopt(file, SOL_SOCKET, SO_TYPE, &type, &len)) 
        
               return UV_UNKNOWN_HANDLE; 
        
             len = sizeof(sa); 
        
             if (getsockname(file, &sa, &len)) 
        
               return UV_UNKNOWN_HANDLE; 
        
             if (type == SOCK_DGRAM) 
        
               if (sa.sa_family == AF_INET || sa.sa_family == AF_INET6) 
        
                 return UV_UDP; 
        
             if (type == SOCK_STREAM) { 
        
           #if defined(_AIX) || defined(__DragonFly__) 
        
               /* on AIX/DragonFly the getsockname call returns an empty sa structure 
        
                * for sockets of type AF_UNIX.  For all other types it will 
        
                * return a properly filled in structure. 
        
                */ 
        
               if (len == 0) 
        
                 return UV_NAMED_PIPE; 
        
           #endif /* defined(_AIX) || defined(__DragonFly__) */ 
        
               if (sa.sa_family == AF_INET || sa.sa_family == AF_INET6) 
        
                 return UV_TCP; 
        
               if (sa.sa_family == AF_UNIX) 
        
                 return UV_NAMED_PIPE; 
        
             } 
        
             return UV_UNKNOWN_HANDLE; 
        
           }

mindplay-dk · 2018-04-18T18:31:49Z

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 · 2018-04-18T19:08:55Z

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.

addaleax added process Issues and PRs related to the process subsystem. windows Issues and PRs related to the Windows platform. labels Mar 2, 2017

soda0289 mentioned this issue Mar 13, 2017

NodeJS cannot spawn a process that reads from STDIN microsoft/WSL#1774

Closed

bzoz mentioned this issue Mar 15, 2017

src: ensure that fd 0-2 are valid on windows #11863

Closed

3 tasks

addaleax closed this as completed in bd496e0 Mar 20, 2017

chrmarti mentioned this issue Jan 31, 2018

--upload-logs not functional on Windows microsoft/vscode#42635

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

jakelauer commented Mar 2, 2017

addaleax commented Mar 2, 2017

seishun commented Mar 2, 2017

addaleax commented Mar 2, 2017

seishun commented Mar 2, 2017

jakelauer commented Mar 2, 2017

seishun commented Mar 2, 2017

jakelauer commented Mar 2, 2017 •

edited

Loading

addaleax commented Mar 2, 2017

jakelauer commented Mar 2, 2017

jakelauer commented Mar 3, 2017

gireeshpunathil commented Mar 4, 2017

addaleax commented Mar 4, 2017

gireeshpunathil commented Mar 5, 2017

scottaddie commented Mar 5, 2017 •

edited

Loading

gireeshpunathil commented Mar 5, 2017 •

edited by gibfahn

Loading

seishun commented Mar 5, 2017

gireeshpunathil commented Mar 6, 2017 •

edited by gibfahn

Loading

seishun commented Mar 6, 2017 •

edited

Loading

gireeshpunathil commented Mar 6, 2017

dcastro commented Mar 8, 2017

seishun commented Mar 8, 2017

dcastro commented Mar 8, 2017 •

edited

Loading

gibfahn commented Mar 12, 2017

soda0289 commented Mar 13, 2017

houd1ni commented Mar 14, 2018 •

edited

Loading

mindplay-dk commented Apr 13, 2018

bnoordhuis commented Apr 13, 2018

houd1ni commented Apr 13, 2018

bnoordhuis commented Apr 13, 2018

bnoordhuis commented Apr 13, 2018

mindplay-dk commented Apr 18, 2018

bnoordhuis commented Apr 18, 2018

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

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

Comments

jakelauer commented Mar 2, 2017

addaleax commented Mar 2, 2017

seishun commented Mar 2, 2017

addaleax commented Mar 2, 2017

seishun commented Mar 2, 2017

jakelauer commented Mar 2, 2017

seishun commented Mar 2, 2017

jakelauer commented Mar 2, 2017 • edited Loading

addaleax commented Mar 2, 2017

jakelauer commented Mar 2, 2017

jakelauer commented Mar 3, 2017

gireeshpunathil commented Mar 4, 2017

addaleax commented Mar 4, 2017

gireeshpunathil commented Mar 5, 2017

scottaddie commented Mar 5, 2017 • edited Loading

gireeshpunathil commented Mar 5, 2017 • edited by gibfahn Loading

seishun commented Mar 5, 2017

gireeshpunathil commented Mar 6, 2017 • edited by gibfahn Loading

seishun commented Mar 6, 2017 • edited Loading

gireeshpunathil commented Mar 6, 2017

dcastro commented Mar 8, 2017

seishun commented Mar 8, 2017

dcastro commented Mar 8, 2017 • edited Loading

gibfahn commented Mar 12, 2017

soda0289 commented Mar 13, 2017

houd1ni commented Mar 14, 2018 • edited Loading

mindplay-dk commented Apr 13, 2018

bnoordhuis commented Apr 13, 2018

houd1ni commented Apr 13, 2018

bnoordhuis commented Apr 13, 2018

bnoordhuis commented Apr 13, 2018

mindplay-dk commented Apr 18, 2018

bnoordhuis commented Apr 18, 2018

jakelauer commented Mar 2, 2017 •

edited

Loading

scottaddie commented Mar 5, 2017 •

edited

Loading

gireeshpunathil commented Mar 5, 2017 •

edited by gibfahn

Loading

gireeshpunathil commented Mar 6, 2017 •

edited by gibfahn

Loading

seishun commented Mar 6, 2017 •

edited

Loading

dcastro commented Mar 8, 2017 •

edited

Loading

houd1ni commented Mar 14, 2018 •

edited

Loading