信号事件
当 Node.js 进程收到信号时,则将触发信号事件。
有关标准 POSIX 信号名称(例如 'SIGINT'
、'SIGHUP'
等)的列表,请参阅 signal(7)
。
信号在 Worker
线程上不可用。
信号句柄将接收信号的名称('SIGINT'
、'SIGTERM'
等)作为第一个参数。
每个事件的名称将是信号的大写通用名称(例如 'SIGINT'
表示 SIGINT
信号)。
// 从标准输入开始读取,因此进程不会退出。
process.stdin.resume();
process.on('SIGINT', () => {
console.log('Received SIGINT. Press Control-D to exit.');
});
// 使用单个函数处理多个信号
function handle(signal) {
console.log(`Received ${signal}`);
}
process.on('SIGINT', handle);
process.on('SIGTERM', handle);
-
'SIGUSR1'
由 Node.js 预留以启动调试器。 可以安装监听器,但这样做可能会干扰调试器。 -
'SIGTERM'
和'SIGINT'
在非 Windows 平台上具有默认的句柄,其在使用代码128 + signal number
退出之前重置终端模式。 如果这些信号之一安装了监听器,则其默认行为将被删除(Node.js 将不再退出)。 -
'SIGPIPE'
默认情况下忽略。 它可以安装监听器。 -
'SIGHUP'
在 Windows 上是在关闭控制台窗口时生成,在其他平台上是在各种类似条件下生成。 参见signal(7)
。 它可以安装监听器,但是 Node.js 将在大约 10 秒后被 Windows 无条件地终止。 在非 Windows 平台上,SIGHUP
的默认行为是终止 Node.js,但一旦安装了监听器,则其默认行为将被删除。 -
'SIGTERM'
Windows 上不支持,可以监听。 -
所有平台都支持来自终端的
'SIGINT'
,通常可以使用 Ctrl+C 生成(但是这是可配置的)。 当启用终端原始模式并使用 Ctrl+C 时不会生成它。 -
'SIGBREAK'
在 Windows 上,当按下 Ctrl+Break 时会发送。 在非 Windows 平台上,它可以被监听,但无法发送或生成它。 -
'SIGWINCH'
当调整控制台大小时会发送。 在 Windows 上,这只会发生在当光标移动时写入控制台,或者当在原始模式下使用可读的终端时。 -
'SIGKILL'
不能安装监听器,它会无条件地终止所有平台上的 Node.js。 -
'SIGSTOP'
不能安装监听器。 -
0
可以发送来测试进程是否存在,如果进程存在则没影响,如果进程不存在则抛出错误。
Windows 不支持信号,因此没有等价的使用信号来终止,但 Node.js 提供了一些对 process.kill()
和 subprocess.kill()
的模拟:
- 发送
SIGINT
、SIGTERM
、和SIGKILL
会导致目标进程无条件的终止,之后子进程会报告进程被信号终止。 - 发送信号
0
可以作为独立于平台的方式来测试进程是否存在。
Signal events will be emitted when the Node.js process receives a signal. Please
refer to signal(7)
for a listing of standard POSIX signal names such as
'SIGINT'
, 'SIGHUP'
, etc.
Signals are not available on Worker
threads.
The signal handler will receive the signal's name ('SIGINT'
,
'SIGTERM'
, etc.) as the first argument.
The name of each event will be the uppercase common name for the signal (e.g.
'SIGINT'
for SIGINT
signals).
// Begin reading from stdin so the process does not exit.
process.stdin.resume();
process.on('SIGINT', () => {
console.log('Received SIGINT. Press Control-D to exit.');
});
// Using a single function to handle multiple signals
function handle(signal) {
console.log(`Received ${signal}`);
}
process.on('SIGINT', handle);
process.on('SIGTERM', handle);
'SIGUSR1'
is reserved by Node.js to start the debugger. It's possible to install a listener but doing so might interfere with the debugger.'SIGTERM'
and'SIGINT'
have default handlers on non-Windows platforms that reset the terminal mode before exiting with code128 + signal number
. If one of these signals has a listener installed, its default behavior will be removed (Node.js will no longer exit).'SIGPIPE'
is ignored by default. It can have a listener installed.'SIGHUP'
is generated on Windows when the console window is closed, and on other platforms under various similar conditions. Seesignal(7)
. It can have a listener installed, however Node.js will be unconditionally terminated by Windows about 10 seconds later. On non-Windows platforms, the default behavior ofSIGHUP
is to terminate Node.js, but once a listener has been installed its default behavior will be removed.'SIGTERM'
is not supported on Windows, it can be listened on.'SIGINT'
from the terminal is supported on all platforms, and can usually be generated with Ctrl+C (though this may be configurable). It is not generated when terminal raw mode is enabled and Ctrl+C is used.'SIGBREAK'
is delivered on Windows when Ctrl+Break is pressed. On non-Windows platforms, it can be listened on, but there is no way to send or generate it.'SIGWINCH'
is delivered when the console has been resized. On Windows, this will only happen on write to the console when the cursor is being moved, or when a readable tty is used in raw mode.'SIGKILL'
cannot have a listener installed, it will unconditionally terminate Node.js on all platforms.'SIGSTOP'
cannot have a listener installed.'SIGBUS'
,'SIGFPE'
,'SIGSEGV'
and'SIGILL'
, when not raised artificially usingkill(2)
, inherently leave the process in a state from which it is not safe to attempt to call JS listeners. Doing so might lead to the process hanging in an endless loop, since listeners attached usingprocess.on()
are called asynchronously and therefore unable to correct the underlying problem.0
can be sent to test for the existence of a process, it has no effect if the process exists, but will throw an error if the process does not exist.
Windows does not support signals so has no equivalent to termination by signal,
but Node.js offers some emulation with process.kill()
, and
subprocess.kill()
:
- Sending
SIGINT
,SIGTERM
, andSIGKILL
will cause the unconditional termination of the target process, and afterwards, subprocess will report that the process was terminated by signal. - Sending signal
0
can be used as a platform independent way to test for the existence of a process.