This repository has been archived by the owner. It is now read-only.

`node` can't `fork(2)` safely #2334

mmalecki opened this Issue Dec 14, 2011 · 29 comments


None yet

Seems like this has something to do with file descriptors getting screwed during forking.

I'll try describing this problem using problems we've had with forever.

When forever forks, it tries to start up a Unix socket server. It worked with node v0.4 but doesn't work with node v0.6. Bad Unix socket persist, causing ECONNREFUSED. Also, unlinking pid file is not possible.

Module we're using for forking is daemon.node.

I think that forever isn't the only usecase for forking processes (right now there's no native way to background a node process without killing it!).

@bnoordhuis told me that node (including libuv) isn't fork-safe and that making it fork-safe isn't even taken into consideration. Can we reconsider it?


bmeck commented Dec 14, 2011

Does anyone know if this affects systems like WebOS that use fork?

@bmeck I think that WebOS still uses node@0.4.12 (where fork(2) kinda worked).

loqur commented Dec 14, 2011





perezd commented Dec 14, 2011


thejh commented Dec 14, 2011

Well, can't you somehow deamonize before loading up node?

xdenser commented Dec 14, 2011


danhak commented Dec 14, 2011


@thejh In this specific situation, there is no workaround. Even if there was one, that's not the point. Ability to fork your process is pretty important.

navanjr commented Dec 14, 2011


tj commented Dec 14, 2011

fork/exec is essentially the same thing, more awkward to work with I suppose

saadiq commented Dec 14, 2011


ry commented Dec 14, 2011

We're not (ever) going to support fork.

  • not portable to windows
  • difficult conceptually for users
  • entire heap will be quickly copied with a compacting VM; no benefits from copy-on-write
  • not necessary
  • difficult for us to do

@ry ry closed this Dec 14, 2011

@visionmedia No, not really. You can't simply push your process to background with child_process.fork. You have to use hack like foreverjs/forever@c18993c but you have to exit from your current process.


ghost commented Dec 14, 2011

What is the issue with that is causing it to not work on 0.6.x ?

@ry Oh! I'm not asking you to add fork(2) to the core! I'm just asking you to reconsider caring about fork-safety.

Marak commented Dec 14, 2011

I must be missing something here.

Surely there is an easy way to fix the issues with forever without requiring a major change to node?

ry commented Dec 14, 2011

@mmalecki no - too hard/distracting - why do you need it?

@ry The usecase was described above. Daemonizing and backgrounding node processes without closing them.

ry commented Dec 14, 2011

you can reparent using child_process.fork and ignoring SIGHUP in the child if that's what you're after

Not really, when I child_process.fork node stays in the foreground and I have to process.exit. That's what I want to avoid.

tingham commented Dec 15, 2011

+1 (sic. closed issue)

ekanna commented Dec 15, 2011


Are we still +1-ing even though ry closed it? When I started using node.js I got the sense that Windows was a second-class citizen, feels like the tables have been turned in 0.6. Guess "forever", wasn't. :(


me-andre commented May 2, 2013

LOL, in ruby/eventmachine I just call fork and everything works as expected. What is "fork-safe" after all? I can admit multithreading is hard to implement in scripting languages, but fork?

@springmeyer springmeyer referenced this issue in tilemill-project/tilemill Jul 16, 2014


synthesis of schemes/node-v6/skipblank #1337

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.