Can't do process.on('SIGINT' with 0.5.4 on windows

[Pita]

original issue is here https://github.com/Pita/etherpad-lite/issues/94

We get following error message:

E:\etherpad-lite-win\node>..\bin\node server.js
←[32m[2011-08-18 04:36:32.850] [INFO] console - ←[39mServer is listening at 0.0.
0.0:9001

node.js:205
throw e; // process.nextTick error, or 'error' event on first tick
^
Error: No such module
at EventEmitter. (node.js:318:27)
at E:\etherpad-lite-win\node\server.js:384:13
at E:\etherpad-lite-win\node_modules\async\lib\async.js:484:34
at Array. (E:\etherpad-lite-win\node_modules\async\lib\async.js:4
08:34)
at EventEmitter._tickCallback (node.js:197:26)

E:\etherpad-lite-win\node>

is on SIGINT a unix specific thing? is there something similar for windows? or is this a bug

[Pita]

this happend on windows xp btw

[piscisaureus]

SIGINT is not supported in windows indeed. It is possible to capture ctrl+c / ctrl+break on windows, but there is no support for this yet in node.

Adding event emitters should probably not crash node, but for the time being it might actually be good if it does.
@ry @bnoordhuis what do you guys think?

[bnoordhuis]

Catching Windows events and emitting them as SIGINT / SIGTERM signals through the process object seems like the best option from a backwards compatibility / cross compatibility point of view.

[DrPizza]

I had almost forgotten about it, but this issue is the one that made me start making code contributions to Node.

[wyattanderson]

Seems like a sensible way to accomplish this would be to have a win32-specific SignalWatcher object (since SignalWatcher isn't even included in the win32 build, as far as I can tell) that emulates signals in some appropriate fashion, right?

MSDN lists the "signals" a process can receive from the console, and maybe in combination with what can be received in normal conditions (process shutdown, etc.) emulate the POSIX equivalents.

The problems I see with this are twofold:

1. Coming up with a sensible translation between Windows process events and POSIX signals
2. It's probably more ideal to have some platform-independent abstraction for application/process state, perhaps in combination with what process.on already provides on Linux systems beyond stuff like SIGINT and SIGKILL.

Thoughts? Obviously not a member of the team or anything, but I've been contemplating a patch and wanted feedback.

[piscisaureus]

I agree that we'll need a way for node apps to capture console control signals. A patch should go into libuv - we haven't discussed this yet, but it seems obvious that we'll have to put a somewhat cross-platform equivalent of ev_signal in libuv.

[DrPizza]

Windows has literally no equivalent to UNIX signals. The function you link to is a complete fake: sending a signal to the function directly executes the associated signal handler in the calling thread.

Ctrl-c is trappable and maps relatively well to SIGINT, and I think we should plumb in a handler to allow process.on('SIGINT') to map to ctrl-c. Beyond that, I can't think off-hand of anything else in Windows that's even remotely signal-like.

-----Original Message-----
From: wyattanderson [mailto:reply+i-1431458-
6065c7da3c61c53fc30e308d647ef00abb9439bc@reply.github.com]
Sent: 03 September 2011 23:21
To: DrPizza
Subject: Re: [node] Can't do process.on('SIGINT' with 0.5.4 on windows
(#1553)

Seems like a sensible way to accomplish this would be to have a win32-
specific SignalWatcher object (since SignalWatcher isn't even included in
the win32 build, as far as I can tell) that emulates signals in some
appropriate fashion, right?

[MSDN lists the "signals"](http://msdn.microsoft.com/en-
us/library/ms683242%28v=vs.85%29.aspx) a process can receive from the console,
and maybe in combination with what can be received in normal conditions
(process shutdown, etc.) emulate the POSIX equivalents.

The problems I see with this are twofold:

1. Coming up with a sensible translation between Windows process events and
   POSIX signals 2. It's probably more ideal to have some platform-independent
   abstraction for application/process state, perhaps in combination with what
   process.on already provides on Linux systems beyond stuff like SIGINT and
   SIGKILL.

Thoughts? Obviously not a member of the team or anything, but I've been
contemplating a patch and wanted feedback.

Reply to this email directly or view it on GitHub:
#1553 (comment)

[piscisaureus]

@DrPizza
CTRL_CLOSE_EVENT != SIGTERM ?

[DrPizza]

I'm not sure if they're exactly the same, but probably close enough.

More problematic are things like SIGALRM, SIGUSR, SIGHUP.

-----Original Message-----
From: piscisaureus [mailto:reply+i-1431458-
6065c7da3c61c53fc30e308d647ef00abb9439bc@reply.github.com]
Sent: 03 September 2011 23:37
To: DrPizza
Subject: Re: [node] Can't do process.on('SIGINT' with 0.5.4 on windows
(#1553)

@DrPizza
CTRL_CLOSE_EVENT != SIGTERM ?

Reply to this email directly or view it on GitHub:
#1553 (comment)

[wyattanderson]

Python's signal seems to "do the right thing" for Windows:

On Windows, signal() can only be called with SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, or SIGTERM. A ValueError will be raised in any other case.

Is the functionality in node_signal_handler.cpp being moved to libuv? That's what emits events on process, right?

[piscisaureus]

@wyattanderson
Did you verify it does the right thing? Is there any way you can use it in a meaningful way?

[DrPizza]

SIGSEGV, SIGFPE, SIGILL are all SEH exceptions on Windows. We could feasibly install an SEH handler with e.g. AddVectoredExceptionHandler() that trapped these, but I'm not sure that we should.

SIGSEGV means there's a serious, possibly security-compromising, bug; crashing immediately is the only safe response.
SIGILL means that the compiler or V8 has a serious bug; crashing immediately is the only safe response.
SIGFPE means that V8 has a bug (since V8 should ensure FP is safe and handle any FP issues itself); crashing immediately is the only safe response.

SIGABRT would require abort() to co-operate and emit the signal. MSVC++ abort() doesn't co-operate and doesn't emit the signal; I have no idea what Python is doing to emulate it. I don't believe node gives any direct access to abort() anyway, so the value appears to be negligible to me.

SIGTERM should map to CTRL_CLOSE_EVENT, as @piscisaureus pointed out.

---

I think we can probably do something like this:
CTRL_C_EVENT -> SIGINT
CTRL_BREAK_EVENT -> SIGINT
CTRL_CLOSE_EVENT -> SIGTERM

CTRL_SHUTDOWN_EVENT and CTRL_LOGOFF_EVENT might be useful for services, but have no good signal that I know of. CTRL_SHUTDOWN_EVENT maps tolerably well to SIGTERM I suppose, but I'm not sure what to do with CTRL_LOGOFF_EVENT. Oh, apparently the documentation is wrong; CTRL_LOGOFF_EVENT is sent to any process on logoff. In that case, it too should become SIGTERM.

There might be some value in making CTRL_BREAK_EVENT do SIGHUP or something--that way, applications can use SIGHUP as a signal to reinitialize their configuration etc., which I believe some UNIX programs do.

[wyattanderson]

Sounds good, @DrPizza. I like the idea of mapping CTRL_BREAK_EVENT to SIGHUP, too.

[DrPizza]

As for the implementation... node_signal_watcher.cc currently uses libev directly. My assumption is that libev should be hidden behind libuv, just as libeio is being hidden.

There's the other side to the equation--kill() will have to be implemented to generate events for the ctrl-c handler. At the moment, node.cc calls kill() directly, inside a #ifdef __POSIX__. So I imagine this needs to be moved to libuv too.

[ry]

It seems java used SIGQUIT on unix to print debug information and CTRL_BREAK_EVENT on Windows. http://www.ibm.com/developerworks/java/library/i-signalhandling/

Other signals used by the JVM are for internal control purposes and do not cause it to terminate. The only control signal of interest is SIGQUIT (on Unix type platforms) and SIGBREAK (on Windows), which cause a Java core dump to be generated.