Sign inDemoInstall


Package Overview
File Explorer

Advanced tools

Install Socket

Protect your apps from supply chain attacks



when you want to fire an event no matter how a process exits.


Version published
Weekly downloads
increased by3.37%

Weekly downloads

Package description

What is signal-exit?

The signal-exit package is used to capture and handle events that indicate Node.js process is about to exit. This includes handling of signals like SIGINT and SIGTERM, as well as normal process termination. It allows developers to register callbacks that can perform cleanup or other final actions before the process exits.

What are signal-exit's main functionalities?

Capture exit events

This feature allows you to capture any kind of exit, whether it's due to a signal or a normal exit. The callback function is called with the exit code and the signal that caused the exit, if applicable.

const onExit = require('signal-exit');

const removeExitHandler = onExit(function (code, signal) {
  console.log('Process is exiting with code:', code, 'and signal:', signal);

// Later, if you decide you do not want to handle the exit:

Unregister exit handler

This feature allows you to unregister a previously registered exit handler. This is useful if the exit handling logic is no longer needed, or if you want to replace it with a different handler.

const onExit = require('signal-exit');

const removeExitHandler = onExit(function () {
  // cleanup logic here

// When you no longer need to handle exits:

Other packages similar to signal-exit




When you want to fire an event no matter how a process exits:

  • reaching the end of execution.
  • explicitly having process.exit(code) called.
  • having process.kill(pid, sig) called.
  • receiving a fatal signal from outside the process

Use signal-exit.

// Hybrid module, either works
import { onExit } from 'signal-exit'
// or:
// const { onExit } = require('signal-exit')

onExit((code, signal) => {
  console.log('process exited!', code, signal)


remove = onExit((code, signal) => {}, options)

The return value of the function is a function that will remove the handler.

Note that the function only fires for signals if the signal would cause the process to exit. That is, there are no other listeners, and it is a fatal signal.

If the global process object is not suitable for this purpose (ie, it's unset, or doesn't have an emit method, etc.) then the onExit function is a no-op that returns a no-op remove method.


  • alwaysLast: Run this handler after any other signal or exit handlers. This causes process.emit to be monkeypatched.

Capturing Signal Exits

If the handler returns an exact boolean true, and the exit is a due to signal, then the signal will be considered handled, and will not trigger a synthetic process.kill(, signal) after firing the onExit handlers.

In this case, it your responsibility as the caller to exit with a signal (for example, by calling process.kill()) if you wish to preserve the same exit status that would otherwise have occurred. If you do not, then the process will likely exit gracefully with status 0 at some point, assuming that no other terminating signal or other exit trigger occurs.

Prior to calling handlers, the onExit machinery is unloaded, so any subsequent exits or signals will not be handled, even if the signal is captured and the exit is thus prevented.

Note that numeric code exits may indicate that the process is already committed to exiting, for example due to a fatal exception or unhandled promise rejection, and so there is no way to prevent it safely.

Browser Fallback

The 'signal-exit/browser' module is the same fallback shim that just doesn't do anything, but presents the same function interface.

Patches welcome to add something that hooks onto window.onbeforeunload or similar, but it might just not be a thing that makes sense there.



Last updated on 29 Jul 2023

Did you know?

Socket installs a GitHub app to automatically flag issues on every pull request and report the health of your dependencies. Find out what is inside your node modules and prevent malicious activity before you update the dependencies.


Related posts

SocketSocket SOC 2 Logo


  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap

Stay in touch

Get open source security insights delivered straight into your inbox.

  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc