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).

[pocesar]

In windows 10, I'm having the problem that Ctrl+C sent by terminal is being ignored by NPM and Node itself, and the processes must be forcefully closed through task manager. Even using process.on('SIGINT' is being ignored.

[sam-github]

@pocesar you should file as seperate bug, its unrelated to this. I suggest including your node version, the shell you were using (cmd.exe I hope), and your example program.

[pocesar]

@sam-github alright, sorry for the hijack, you may delete the messages

[Trott]

It seems to me that this can be closed now that the documentation reflects what's going on, but I'm not sure @ronkorving or (especially) @reqshark would agree. Thoughts?

[ronkorving]

You've definitely improved it. I can always open a new (more specific) issue if I hit a wall with this again :) @reqshark, shall we close this?

[Fishrock123]

Fwiw I found the original issue for this that changed it to not call exit, you can see @bnoordhuis's response over there. tl;dr: it's not necessarily safe to do so.

Gona close this one out with that in mind.

[Fishrock123]

Sorry, here is the original issue link: nodejs/node-v0.x-archive#457 (comment)

[addaleax]

@Fishrock123 That issue by @bnoordhuis refers to the C exit function, not Node’s process.exit. Since the JS signal handler is called asynchronously, calling .exit() should be perfectly safe (and left to userland, imho).

[Fishrock123]

Uh, process.exit() still calls exit(). I tracked this down a couple weeks ago, I'm pretty confident that is still the origin of why this works this way.

[addaleax]

Uh, process.exit() still calls exit().

Yes, but… C signal handlers (which @bnoordhuis refers to in that issue) and JS listeners are quite different, and the concept of “unsafe” functions in the POSIX sense just doesn’t apply to JS listeners.

All that Node’s/libuv’s signal handler does is writing down that a signal occurred and notifying the event loop of that, and no JS code is called during the signal handler itself. When the listeners that have been attached using process.on() are called, the process has already resumed normal operation, and calling exit()s of any kind is perfectly fine.

[Fishrock123]

... ok I'll dig though git blame again.

[Fishrock123]

Ok unsure what I dug through and really can't be bothered to dig again, I'll just take your word on it.
¯_(ツ)_/¯

[addaleax]

I’m not particularly sure about the expected behaviour here, but fwiw this kind of question has come up a couple of times on the issue tracker here and people have been quite happy with accepting https://www.npmjs.com/package/signal-exit as a proper solution.

[Fishrock123]

Yeah I had to work around this in dprof and was wondering why it didn't function that way...

[addaleax]

Yeah, I can see why this is a tricky thing and why people would want to have the standard exit handler called…

[bnoordhuis]

What is the consensus here? I see some changes have been made to the documentation. Can this issue be closed?

[sam-github]

@Fishrock123 you re-opened, but its not clear from the conversation why, can it be closed? I think your dprof code link points to the wrong line now, can you update, and press y to convert the link to an absolute one?

[Trott]

This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that.

[Qix-]

@reqshark

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.

Why? Which specification or best practice decrees this? Modern SIGINT is used to interrupt a process in order to gracefully exit it. Long-running processes are a very common use-case for Node.js and thus need a way to gracefully shutdown in a standard way (i.e. both manual and programmatic shutdowns). SIGINT is being used for that pretty much across the board.

14 million downloads of signal-exit seems like an indicator that this confusion isn't localized. Other languages have similar facilities (e.g. Python's atexit) and most all of them respond to SIGINT as a form of graceful exit signal.

I'm actually really surprised this isn't the case for Node.js.

[sam-github]

@qix python does not treat SIGINT as a normal exit:

Note: The functions registered via this module are not called when the program is killed by a signal

https://docs.python.org/2/library/atexit.html

Nor does Ruby, or C/C++, or any other language I've ever worked with. Node.js is doing what everyone else does here.

[Qix-]

@sam-github Python does indeed.

import atexit

@atexit.register
def goodbye():
    print "You are now leaving the Python sector."

import time

time.sleep(100)

C/C++ don't have 'on process exit' handlers. They have signal handlers, which only allow you to catch specific signals. So those languages don't apply here.

Java also runs shutdown hooks upon Ctrl+C:

class Main {
	public static void main(String[] args) throws Throwable {
		System.out.println("Registering...");
		Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
			public void run() {
				System.out.println("Shutdown hook called");
			}
		}));

		Thread.sleep(10000);
	}
}

So no, Node.js is not doing "what everyone else does here". I also think that's a poor metric for what is considered expected or correct.

[sam-github]

Sorry, misread python docs. Interestingly, their atexit has the side effect of changing the return status, so you can't tell from the process status that it would have terminated by signal. Shrug.

C/C++ don't have 'on process exit' handlers.

http://man7.org/linux/man-pages/man3/atexit.3.html

I also think that's a poor metric for what is considered expected or correct.

I agree. It wasn't my argument, I was just contesting that node is unusual in following the lead of C's atexit(), or that if python does it, node should. People are free to use Node APIs to implement the behaviour they want, and are doing so successfully.

[Qix-]

http://man7.org/linux/man-pages/man3/atexit.3.html

TIL, thanks.

I think, at the very least, this should be documented with the exit event.

[sam-github]

The 'exit' event is emitted when the Node.js process is about to exit as a result of either:

The process.exit() method being called explicitly;
The Node.js event loop no longer having any additional work to perform.

^--- seems clear to me, but open an issue proposing the wording you think is missing, or even a PR if you have the inclination.