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

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

Closed
mmalecki opened this Issue Dec 14, 2011 · 29 comments

Comments

Projects
None yet
@mmalecki

mmalecki commented Dec 14, 2011

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

This comment has been minimized.

Member

bmeck commented Dec 14, 2011

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

@mmalecki

This comment has been minimized.

mmalecki commented Dec 14, 2011

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

@loqur

This comment has been minimized.

loqur commented Dec 14, 2011

+1

7 similar comments
@thinkroth

This comment has been minimized.

thinkroth commented Dec 14, 2011

+1

@edwardhotchkiss

This comment has been minimized.

edwardhotchkiss commented Dec 14, 2011

+1

@mikosh75

This comment has been minimized.

mikosh75 commented Dec 14, 2011

+1

@alejandro

This comment has been minimized.

alejandro commented Dec 14, 2011

+1

@mlegenhausen

This comment has been minimized.

mlegenhausen commented Dec 14, 2011

+1

@erikhoward

This comment has been minimized.

erikhoward commented Dec 14, 2011

+1

@perezd

This comment has been minimized.

perezd commented Dec 14, 2011

+1

@thejh

This comment has been minimized.

thejh commented Dec 14, 2011

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

@xdenser

This comment has been minimized.

xdenser commented Dec 14, 2011

+1

1 similar comment
@danhak

This comment has been minimized.

danhak commented Dec 14, 2011

+1

@mmalecki

This comment has been minimized.

mmalecki 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

This comment has been minimized.

navanjr commented Dec 14, 2011

+1

@tj

This comment has been minimized.

tj commented Dec 14, 2011

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

@saadiq

This comment has been minimized.

saadiq commented Dec 14, 2011

+1

@ry

This comment has been minimized.

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

@mmalecki

This comment has been minimized.

mmalecki commented 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

This comment has been minimized.

ghost commented Dec 14, 2011

What is the issue with https://github.com/indexzero/daemon.node/blob/master/src/daemon.cc that is causing it to not work on 0.6.x ?

@mmalecki

This comment has been minimized.

mmalecki commented Dec 14, 2011

@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

This comment has been minimized.

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

This comment has been minimized.

ry commented Dec 14, 2011

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

@mmalecki

This comment has been minimized.

mmalecki commented Dec 14, 2011

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

@ry

This comment has been minimized.

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

@mmalecki

This comment has been minimized.

mmalecki commented Dec 14, 2011

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

This comment has been minimized.

tingham commented Dec 15, 2011

+1 (sic. closed issue)

@ekanna

This comment has been minimized.

ekanna commented Dec 15, 2011

+1

@coreyjewett

This comment has been minimized.

coreyjewett 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. :(

+1

@me-andre

This comment has been minimized.

me-andre commented May 2, 2013

+1
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?

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