-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
detached child_process doesn't inherit stdio #3596
Comments
|
@bnoordhuis is this expected behavior? With Node 5 on OS X, and the following code: process.stdout;
require('child_process').spawn('ls', [], {
stdio: 'inherit',
detached: true
}); Nothing is printed. However, if I comment out the |
/cc @indutny - I'm guessing it's related to OS X's broken kqueue support for special files and libuv's workaround. I can reproduce on OS X but it works fine on Linux, FWIW. |
The only explanation that I have is that reopening stdout as |
Gosh, it is twice as odd, considering that piping the output like this: |
And of course it is related to the reopening of |
I think there is some fishy stuff with the current session and the way |
It looks like for a child process
|
@wonnage may I ask you to give a try to this patch? diff --git a/deps/uv/src/unix/process.c b/deps/uv/src/unix/process.c
index 571f8cd..c02c750 100644
--- a/deps/uv/src/unix/process.c
+++ b/deps/uv/src/unix/process.c
@@ -283,8 +283,10 @@ static void uv__process_child_init(const uv_process_options_t* options,
int use_fd;
int fd;
- if (options->flags & UV_PROCESS_DETACHED)
+ if (options->flags & UV_PROCESS_DETACHED) {
+ setpgid(getpid(), getpid());
setsid();
+ }
/* First duplicate low numbered fds, since it's not safe to duplicate them,
* they could get replaced. Example: swapping stdout and stderr; without I suspect that this is an OS X kernel bug and that for some reason |
Gosh, I have figured it out. The actual device behind I'll need some time to think if there is any workaround for this. |
I failed at it miserably :( Submitted Apple bugreport # 23994737 |
Hey! sorry i've been inactive on this thread - switched jobs and no longer working on the code that produced this error in the first place :) |
handwaving through my ignorance of unix internals a bit, but is this a correct summary of the issue: we start with a parent process hooked up to a tty afterwards, piping however, if stdout is a tty ( |
@wonnage I believe piping works because it is not using tty at all, it is using pipes. |
@indutny would you mind sharing the apple bug report on open radar? |
Curious if this is fixed with libuv 1.9.x |
Seeing something very similar with cc/ @chalkers |
The change in e041ac6 to support sending unlocker process output to the main ngcc console output prevents messages require that the main process relinquishes the event-loop to allow the `stdout.on()` handler to run. This results in none of the messages being written when ngcc is run in `--no-async` mode, and some messages failing to be written if the main process is killed (e.g. ctrl-C). It appears that the problem with Windows and detached processes is known - see nodejs/node#3596 (comment). But in the meantime, this commit is a workaround, where non-Windows `inherit` the main process `stdout` while on Windows it reverts to the async handler approach, which is better than nothing.
The change in e041ac6 to support sending unlocker process output to the main ngcc console output prevents messages require that the main process relinquishes the event-loop to allow the `stdout.on()` handler to run. This results in none of the messages being written when ngcc is run in `--no-async` mode, and some messages failing to be written if the main process is killed (e.g. ctrl-C). It appears that the problem with Windows and detached processes is known - see nodejs/node#3596 (comment). But in the meantime, this commit is a workaround, where non-Windows `inherit` the main process `stdout` while on Windows it reverts to the async handler approach, which is better than nothing.
The change in e041ac6 to support sending unlocker process output to the main ngcc console output prevents messages require that the main process relinquishes the event-loop to allow the `stdout.on()` handler to run. This results in none of the messages being written when ngcc is run in `--no-async` mode, and some messages failing to be written if the main process is killed (e.g. ctrl-C). It appears that the problem with Windows and detached processes is known - see nodejs/node#3596 (comment). But in the meantime, this commit is a workaround, where non-Windows `inherit` the main process `stdout` while on Windows it reverts to the async handler approach, which is better than nothing. PR Close #36637
The change in e041ac6 to support sending unlocker process output to the main ngcc console output prevents messages require that the main process relinquishes the event-loop to allow the `stdout.on()` handler to run. This results in none of the messages being written when ngcc is run in `--no-async` mode, and some messages failing to be written if the main process is killed (e.g. ctrl-C). It appears that the problem with Windows and detached processes is known - see nodejs/node#3596 (comment). But in the meantime, this commit is a workaround, where non-Windows `inherit` the main process `stdout` while on Windows it reverts to the async handler approach, which is better than nothing. PR Close #36637
The following snippet of code prints the child process' output if detached is true, and doesn't if it's false:
This part of the docs seems relevant:
Which seems to imply that inheriting these streams is supported. Not sure if this is just me misreading the docs or...
The text was updated successfully, but these errors were encountered: