Node: Children from child_process.fork printing outside of parent after parent process.exit

[METACEO]

• Version: v6.3.1
• Platform: Linux 3.10.0-327.28.2.el7.x86_64
• Subsystem: child_process

My example demonstrates - what I believe to be - a frustrating extreme to what could be an underlying issue. Copy together the two examples below into the same directory (name the top parent.js and the bottom child.js - for reproducing's sake.) Open two terminals (the first will become difficult to use...) and run node parent.js with the first and wait. While your node application will close, you'll continue to be hit with the console.log from the forked process. This will continue until you kill the child process manually (which, again, can be difficult with the first terminal) so run ps aux | grep "node child.js" with your second terminal, find the forked child's PID and kill it.

The prints will not happen if child.js is forked with a true silent option or if you exit parent.js with Ctrl+C - so I don't know if this is a leak of the child's scope or if this is intentional and by design.

/* parent.js */

// create a child:
require("child_process").fork("child.js")

// exit after a couple of seconds:
setTimeout(process.exit, 2000)

/* child.js */

// call every second:
setInterval(() => console.log(new Date),1000)

[addaleax]

That sounds like the expected behaviour to me, maybe the conversation in https://github.com/nodejs/node/issues/7951#issuecomment-237031167 clarifies things a little, too?

[METACEO]

The behavior that surprises me is that the child's output exists beyond its closed parent - not that the child is continuing to process (just to clarify.) I'm just here expecting my child's output to only appear within my parent's process.

For example, it'd be wild to suddenly get error messages popping up in the terminal and discovering it's all from some old forgotten child process (I mean, it's good to know something's gone wrong - but that will put your general user into a frenzy panic.) We can utilize log files for sure, but to continue dumping things into userland feels pretty wild.

[mscdex]

I also think this is expected since fork() by default will pass the parent's stdin/stdout/stderr file descriptors to the child (when silent is not true). When the parent dies, the child process still has references to those file descriptors, which is why it continues to output to the parent's stdout, etc.

[METACEO]

Yes @mscdex - I'm reading that explicitly now in the docs and it does read as practical. I suppose I just found myself caught off guard with a bizarre scenario.

Consider me taught - thank you both for the quick clarifications.