Call SignalExit() from custom node signal handler

[fabriciomurta]

NodeJS's signalExit() nicely resets terminal on exit, cross platform (POSIX?) friendly. Problem is, if I handle SIGINT or SIGTERM, the default handler would no longer be triggered. Is there a way I can just keep default handler after I do my job?

process.on("SIGINT", function (signalName, signalNumber) {
    console.log("We've received " +signalName + " (" + signalNumber + ")";
    // my call to signalExit() should go here
});

[gireeshpunathil]

f I handle SIGINT or SIGTERM, the default handler would no longer be triggered.

@fabriciomurta - isn't that we want, by design? can you elaborate your use case a little? are you wanting

• signal chaining, wherein every signal is handled by the custom handler followed by all other registered handlers, in an order
• signal chaining, only for SIGINT and SIGTERM
• no signal chaining, but just emulate the behavior of signalExit after custom handling
• emulate the behavior of signalExit after custom handling of SIGINT and SIGTERM
• no re-raising (chaining), but just reset the stdio after each handling
• no reset stdio, but just re-raise (chain) the signal after each handling

[fabriciomurta]

Thanks for the follow-up @gireeshpunathil!

My use case is this:

• start nodeJs
• a third-party spawned tool screws up the terminal however it likes
• if I ctrl+c, NodeJS nicely cleans up and restores the terminal settings (ResetStdio() called from SignalExit()

But then, if I wanted my script to say "Hey, you pressed ctrl+c!", I would lose nice ResetStdio(). So it would be best if I could "chain" the signal like you said, prepending my handler to NodeJS's default one.

I understand that, by default, we "pugging" into the signal handlers should override whatever is default. But in this case, there's a nice portable solution (ResetStdio()) that I'd like to take advantage of. :-) I could send all the reset signs but it wouldn't be as well tested as NodeJS's implementation wired up by default. Chaining will probably (I expect it to) also call something similar to process.exit() which I'd be totally fine with.

So if it is still not clear, this seems what would help me:

• signal chaining, only for SIGINT and SIGTERM

..and actually SIGTERM won't be required, basically SIGINT should help. I have googled thru docs for the new keyword "signal chaining" without much luck.

In the very very very actual use case, I am using NodeJS to wrap a .NET console app. .NET sends lots of "Keypad Mode: Application" and "Cursor keys mode: Application" commands and never resets them. Neither does NodeJS, so I still need to reset them manually when NodeJS regains control. But depending on what the console app does, it also sets TTY [-]echo to off -- and who knows what else. This (and who knows what else in the future) NodeJS handles nicely, so chaining feels like the right thing to do.

[gireeshpunathil]

@fabriciomurta - thanks, this is indeed an interesting case!

the very heart of signal chaining is this:

• cache the original handler for your interested signal
• install a new handler for the signal
• when signal arrives, handle it in your handler
• invoke the cached handler, to give it a chance too
• repeat this recursively, for 3rd, 4th,... handlers

this is largely useful with layered applications running in managed runtimes wherein, a signal with a well defined meaning needs to be over-ridden by the app for what ever reason, without loosing its original meaning in the lower stack components (example: SIGUSR2 in some Java variants means collect heap and text dumps, in Node.js to collect report etc. and the app wants to do some custom action too). The key here is that the person who "pugs" the signal also knows that the other handler also will be (and needs to be) called.

Please note that this is not currently available in Node.js

So if it is still not clear, this seems what would help me:

To make it super simple, will this help your case? resetStdio as a callable JS API? that you can call from wherever you want?

[fabriciomurta]

Hello @gireeshpunathil , and thanks for the dedicated and detailed explanation, it is very enlightening! It's a pity though we can't do it, or something similar in NodeJS.

To make it super simple, will this help your case? resetStdio as a callable JS API? that you can call from wherever you want?

This sure was one of the things I looked as alternatives to me. Tried some process.stdout.reset*(), require('tty').reset*() for no avail.

But I still believe that many more people would benefit of the broader scenario: signal (somehow) the handler that the previously assigned handler (if any) should still take place.

One way that wouldn't break anything would be to pass an options argument to .on(), but this may break design.

Other way that would probably break stuff around is to return false from the handler when we don't want default behavior to take place. I believe this way would be the most intuitive for existing js developers..... although it would break any signal handlers (that already have default handlers). Although it wouldn't be a problem in case the handler calls exit(), in case the signal was transformed in something not to exit, it could be a problem.

Sorry for the long text. I am just thinking on what (I think) would benefit the community overall the most, what would be more worth time developing. Being able to call ResetStdio() will sure have its audience.

Back to my actual use case, what I went with is:

process.on('SIGINT', () => {});'

Yes! It makes sense in my case because the "wrapper" only spawns a child; when it's done, it's done. And as the signal is still passed to the spawned process, it does handle it however it likes (keeping terminal broken, etc), yet the Node JS script will go to its spawnedProcess.on('exit', ...) and do my keypad + cursor cleanup while NodeJS does its own echo/etc cleanups.

So in the end I could benefit of whatever implementation NodeJS has to cleanup after process run, not limiting (a) to know it only calls ResetStdio() then raise the "quits" (b) doing what it does to clean up exit in a portable way no matter how it changes in the future, keeping the solid and well tested "officially suported" behavior. In the least, it is a code reviewed by lots of people.

Let me summarize, thing's too long:

• resetStdio as a callable JS API would sure be welcome, I would totally have used it if it was the solution we had today, instead of what I've done!
• If I were to choose, being able to retain default handler after my custom one (no matter which technique is used) would be the best for the community as a whole. I could find several inquiries about this across google. So that would be for a much greater good and kudos coming from everywhere. :)

[gireeshpunathil]

@fabriciomurta - this is indeed a great discussion!

If I were to choose, being able to retain default handler after my custom one (no matter which technique is used) would be the best for the community as a whole.

makes sense to me! the one caveat though is that it has to be either a separate API, or the existing one with a non-default option; or else the behavioral change will be disruptive - for example a user who over-riden the default SIGINT with a custom handler will now see the custom handling followed by the termination (default OS handler's action)

[fabriciomurta]

Maybe easiest and least disruptive way would be to let call SignalExit()? So the API and nothing would change anything, simply a new native function would be available. And thinking on the long term maybe two:

• process.defaultSigIntHandler()
• process.defaultSigTermHandler()

And (with current implementation) they would just map to the same SignalExit(). Anyone willing to retain default signal behavior (including process actual interruption) just add a call to this from their code (well, and remove their own process.exit() call, perhaps).

I think the only difference between them for now would be one would be exiting with signal 128 + os.constants.signals.SIGINT and then 128 + os.constants.signals.SIGTERM; but this could change in the future at least for a given platform, thus no more required changes in the code.