signal-exit

Variables

• signals

Functions

• load()
• onExit()
• unload()

Type Aliases

• Handler

variable signals

const signals: NodeJS.Signals[];

• This is not the set of all possible signals.

  It IS, however, the set of all signals that trigger an exit on either Linux or BSD systems. Linux is a superset of the signal names supported on BSD, and the unknown signals just fail to register, so we can catch that easily enough.

  Windows signals are a different set, since there are signals that terminate Windows processes, but don't terminate (or don't even exist) on Posix systems.

  Don't bother with SIGKILL. It's uncatchable, which means that we can't fire any callbacks anyway.

  If a user does happen to register a handler on a non- fatal signal like SIGWINCH or something, and then exit, it'll end up firing process.emit('exit'), so the handler will be fired anyway.

  SIGBUS, SIGFPE, SIGSEGV and SIGILL, when not raised artificially, inherently leave the process in a state from which it is not safe to try and enter JS listeners.

function load

load: () => void;

function onExit

onExit: (
    cb: Handler,
    opts?: { alwaysLast?: boolean | undefined } | undefined
) => () => void;

function unload

unload: () => void;

type Handler

type Handler = (
    code: number | null | undefined,
    signal: NodeJS.Signals | null
) => true | void;

• A function that takes an exit code and signal as arguments

  In the case of signal exits *only*, a return value of true will indicate that the signal is being handled, and we should not synthetically exit with the signal we received. Regardless of the handler return value, the handler is unloaded when an otherwise fatal signal is received, so you get exactly 1 shot at it, unless you add another onExit handler at that point.

  In the case of numeric code exits, we may already have committed to exiting the process, for example via a fatal exception or unhandled promise rejection, so it is impossible to stop safely.