Shouldn't the default SIGINT handler trigger process.on('exit')?

[ronkorving]

Maybe it's a bug, maybe it's by design. Documentation doesn't mention anything about whether or not the "exit" event should fire, but it's a bit silly I have to write:

process.on('SIGINT', function () {
 process.exit(somecode); // now the "exit" event will fire
});

Just because the built-in handler won't do it for me. It also means I can no longer depend on the default exit code that Node associates with SIGINT, which apparently is 128 + signal number (according to the docs).

[reqshark]

SIGINT from the terminal is supported on all platforms, and can usually be generated with CTRL+C

the docs describe a few other signals and continue:

Note that Windows does not support sending Signals

however, firing exit events on SIGINT should be an exception.

regardless of exit or uncaughtException listeners set on node processes, ctrl+c on terminal, should result in nothing else but immediate control returned to the terminal.

When node doesn't immediately exit.. I start to think there's either something wrong with my computer, something wrong with node.js being slow, my ssh ClientAliveInterval never got set in ~/.ssh/config so the terminal tab went all zombie and in like 7 or 8 minutes it might say broken pipe .

[Trott]

It seems to me that the fact that the exit event is not guaranteed to actually fire in situations like this should be mentioned in the docs. (Is it there and I'm just overlooking it? If not, I'm happy to put together a minimal PR for it. Probably only needs to be a sentence or two.) It would be great to be able to point to something official like that when people have problems like this.

[reqshark]

@Trott nice PR, I just left you a comment on the diff. If you take a look at the section on Signal Events (which ought to be renamed to "Signal Interrupts" to help delineate the meaning of process events versus kernel/system signals), there's one ambiguity there I'd like to see clarified:

SIGINT from the terminal is supported on all platforms, and can usually be generated with CTRL+C
...
Note that Windows does not support sending Signals

The language here feels contradictory to me and it would be good to clarify that description as well.

[Trott]

Yeah, I'm not sure what that second line you quote is supposed to mean. It seems to be contradicted by https://msdn.microsoft.com/en-us/library/xdkz3x12.aspx.

[reqshark]

well maybe that was written before windows 10 or whichever versions began to support such POSIX

btw, after pointing out how SIGHUP does the same, meaning there's more than three signals bypassing the exit event, i think we should be clear about that and include the rest of the list:

http://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html

[reqshark]

@ronkorving's right.

Maybe it's a bug, maybe it's by design.

The issue he stated here calls for more fix than just the docs. The process module's exit event is borked until it only allows signal bypass from those we know to be intentional user input termination (ctrl+c).

IMO

[reqshark]

the docs provide (and we accept) that:

SIGINT, SIGTERM, and SIGKILL cause the unconditional exit

if the exit event informed which signal is terming the process people wouldn't have to write:

process.on('SIGINT', function () {
 process.exit(somecode); // now the "exit" event will fire
});

One exit handler would be more consistent with the idea of an exit event handler.

the only signal that an exit event should ignore is probably SIGINT or its equivalent on windows. I dont think we should allow the whole other assortment of termination signals, like SIGHUP for instance to bypass the exit event

[sam-github]

SIGINT, SIGTERM, and SIGKILL cause the unconditional exit, those docs are wrong, they should say unconditional termination.

Processes terminate either normally, by exit, or by signal (on unix). The two forms of termination are different, and signal death isn't exit, and doesn't cause exit handlers to trigger. See http://linux.die.net/man/2/waitpid.

This code is correct, other than that it will cause the status to be exited instead of signalled:

process.on('SIGINT', function (){
 process.exit(somecode); // now the "exit" event will fire
});

In particular, note that whether you want to clean up as if its a "normal" exit is a question specific to the application. You should decide what signals you want to trigger your cleanup handlers, and which signals you want to immediately kill the process. When you decide, listen to the ones you want to trap, as you do above.

On Windows, all this is emulated as best it can be, I tried to document the caveats, and what libuv does to try to emulate unix signals for some useful subset of behaviour, but the docs are never perfect.

[sam-github]

>128 Signal Exits - If Node.js receives a fatal signal such as SIGKILL or SIGHUP,
then its exit code will be 128 plus the value of the signal code.

Those docs are wrong, too, for SIGKILL. SIGKILL is not trappable, and termination will be by signal.

That node traps some signals, cleans up the tty state, and then exits rather than re-terminating itself by a signal is a borderline bug that got fixed in 0.12, I thought, but mabye it still exists.

I don't know if I'll have the time to rework those docs in the next days, so if anyone wants to PR some improvements, please do!