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

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.

/cc @nodejs/platform-windows

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

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.

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

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.

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

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.

@jakelauer

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.

@addaleax

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

Interesting sidenote: I do not experience this in Windows 10

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.

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?

@addaleax

@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

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

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)

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?

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

@bnoordhuis

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

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.)

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; 
        
           }

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?

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.

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

Navigation Menu

Repository navigation

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

13 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	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();
	}

	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;
	}

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

Description

Activity

addaleax commented on Mar 2, 2017

seishun commented on Mar 2, 2017

addaleax commented on Mar 2, 2017

seishun commented on Mar 2, 2017

jakelauer commented on Mar 2, 2017

seishun commented on Mar 2, 2017

jakelauer commented on Mar 2, 2017

addaleax commented on Mar 2, 2017

jakelauer commented on Mar 2, 2017

jakelauer commented on Mar 3, 2017

gireeshpunathil commented on Mar 4, 2017

addaleax commented on Mar 4, 2017

gireeshpunathil commented on Mar 5, 2017

13 remaining items

houd1ni commented on Mar 14, 2018

mindplay-dk commented on Apr 13, 2018

bnoordhuis commented on Apr 13, 2018

houd1ni commented on Apr 13, 2018

bnoordhuis commented on Apr 13, 2018

bnoordhuis commented on Apr 13, 2018

mindplay-dk commented on Apr 18, 2018

bnoordhuis commented on Apr 18, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions