Question
WebStorm Node.js timeout and Stop button signal delivery limits
Mira Vale
0 reputation · 26 Jun 2023, 12:09 UTC
10.6K views
Loading…
0 reputation · 26 Jun 2023, 12:09 UTC
WebStorm run/debug configurations for Node.js include a per-configuration Timeout field and a Stop button, but the exact forced-termination sequence across platforms is not fully documented. On macOS and Linux, the Stop action sends SIGTERM, while Windows uses CTRL_BREAK_EVENT; whether WebStorm escalates to SIGKILL after a grace period, and whether that sequence is configurable, remains unclear.
There is no separate setting for a graceful shutdown timeout distinct from the process timeout, and npm run configurations appear to inherit the same termination behavior without triggering npm lifecycle scripts such as prestop. When designing local workflows for Node.js services that rely on signal handlers to drain connections or flush logs, these limits affect how reliably cleanup code executes.
Because timeout values are per configuration rather than global, each run configuration must be evaluated individually. Is the termination sequence documented for current WebStorm versions, and does it differ by operating system? Does WebStorm expose a configurable grace period for graceful shutdown before forced termination, or must applications rely solely on their own signal handling? Should npm lifecycle scripts be expected to run when a run configuration is stopped or times out, or does forced termination bypass them entirely?
35775 reputation · 26 Jun 2023, 13:30 UTC
WebStorm's Stop button sends SIGTERM on macOS and Linux, and CTRL_BREAK_EVENT on Windows. The per-configuration Timeout field does not create a separate graceful-shutdown grace period, and WebStorm does not expose a user-configurable interval before forced termination. On Unix-like systems, WebStorm may escalate to SIGKILL if the process does not exit after SIGTERM; on Windows, forced termination uses TerminateProcess, which cannot be intercepted. The exact escalation timing is not documented for current WebStorm versions and may vary by platform and version.
Confirmed: the Stop action uses platform-specific signals; the Timeout field applies per run configuration; npm lifecycle scripts such as prestop are not reliably executed when WebStorm stops or times out a configuration because the IDE terminates the process directly rather than running npm's shutdown sequence.
Likely explanation: WebStorm owns the Node.js process and stops it directly. With an npm wrapper, WebStorm signals or terminates the process tree but does not invoke npm lifecycle hooks. Application code in a process.on('SIGTERM', ...) handler can run only if the process exits before WebStorm escalates to SIGKILL.
nodejs
webstormSIGTERM handler in the Node.js entry point that drains connections, flushes logs, and calls process.exit() within a few seconds.prestop or other npm lifecycle scripts for cleanup in WebStorm workflows; place cleanup inside the application signal handler instead.CTRL_BREAK_EVENT handling, but understand that forced termination bypasses handlers entirely.Run a test script that logs SIGTERM receipt and delays exit, then stop the configuration from WebStorm. If the log appears before the process disappears, graceful handling worked. If the process vanishes without the log, WebStorm escalated before shutdown completed.
Uncertainty: WebStorm does not publish the SIGKILL escalation interval. Treat it as non-configurable and re-verify after WebStorm updates.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.