javascript - 检查应用程序是否在 Electron js 中被强制关闭？

Question

我的问题是如何知道我的应用程序是否已从 Windows 中的任务管理器或 Ubuntu (Linux) 中的系统监视器关闭？

当用户关闭应用程序时，我会从应用程序中注销用户配置文件，但这仅在关闭事件时发生。当我尝试从任务管理器中强制退出应用程序时，注销将不起作用

Answer 1

根据 signal events 上的 nodejs 文档，这是不可能的为 SIGKILL 添加一个监听器，但是您可以为 SIGTERM 添加一个。以下是其他信号事件:

'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 code 128 + 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. See signal(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 of SIGHUP 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 +C (though this may be configurable). It is not generated when terminal raw mode is enabled.

'SIGBREAK' is delivered on Windows when + 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 using kill(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 using process.on() are called asynchronously and therefore unable to correct the underlying problem.