-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] npm not handling process signals #6684
Comments
@ryanrasti I'm getting this same behavior in npm v9.6.7. Can you verify what npm version was working? In my case There is a possibly identical issue that was opened at #6547, but no triage occurred in the month since it was opened. This may be caused by a change made in npm/run-script#142. There were no tests associated with the changed behavior. Maybe an issue needs opened in that repository? cc: @nlf, @wraithgar |
How does this issue still have zero response? Very disappointing. @nlf @wraithgar For those looking for a workaround on Linux, you can kill the entire process tree like this:
As a bonus, you can inspect the process tree with either the root process ID or the process group ID like this:
|
Any news about this? |
## Description This PR reverts the changes made in commit `545f3be94d412941537ad0011717933d48cb58cf`, which inadvertently broke signal forwarding to child processes (PR #142 ). Contrary to the assumptions by @nlf , `SIGTERM` and similar signals are not being correctly propagated to child processes. Instead, they are only received by npm, resulting in incomplete signal handling. The removal of signal forwarding in #142 means that child processes do not receive necessary signals for appropriate cleanup and termination. This issue is evident in workflows involving `npm start` used as a Docker command for local execution. For instance, using CTRL + C does not properly terminate the application and results in a forced kill after a 10-second delay. This behavior could lead to more significant problems in production environments, (if `npm` is used to start the app) such as data loss due to improper database connection closures. ## Minimal Reproduction Steps Create a package.json with the following content: ```json { "name": "npm", "scripts": { "start": "node ./main-test.js" } } ``` Create a main-test.js file: ```typescript const interval = setInterval(() => console.log('alive!'), 3000); async function onSignal(signal) { console.log(`${signal} received, cleaning up...`); clearInterval(interval); console.log('Cleaning up done'); } process.on('SIGINT', onSignal); process.on('SIGTERM', onSignal); ``` Execute `npm start`. The script should output `alive!` every 3 seconds. Attempt to terminate it using `kill -SIGTERM [PID]`. It should log `Cleaning up done` and shut down gracefully, which it does in older versions of `npm` (e.g., `v8.19.4`) but fails in newer versions (e.g., `v9.6.7`). ## Impact Reverting this change will restore the expected behavior for signal handling in `npm` # References - npm/cli#6547 - npm/cli#6684 - #142
This PR reverts the changes made in commit `545f3be94d412941537ad0011717933d48cb58cf`, which inadvertently broke signal forwarding to child processes (PR #142 ). Contrary to the assumptions by @nlf , `SIGTERM` and similar signals are not being correctly propagated to child processes. Instead, they are only received by npm, resulting in incomplete signal handling. The removal of signal forwarding in #142 means that child processes do not receive necessary signals for appropriate cleanup and termination. This issue is evident in workflows involving `npm start` used as a Docker command for local execution. For instance, using CTRL + C does not properly terminate the application and results in a forced kill after a 10-second delay. This behavior could lead to more significant problems in production environments, (if `npm` is used to start the app) such as data loss due to improper database connection closures. Create a package.json with the following content: ```json { "name": "npm", "scripts": { "start": "node ./main-test.js" } } ``` Create a main-test.js file: ```typescript const interval = setInterval(() => console.log('alive!'), 3000); async function onSignal(signal) { console.log(`${signal} received, cleaning up...`); clearInterval(interval); console.log('Cleaning up done'); } process.on('SIGINT', onSignal); process.on('SIGTERM', onSignal); ``` Execute `npm start`. The script should output `alive!` every 3 seconds. Attempt to terminate it using `kill -SIGTERM [PID]`. It should log `Cleaning up done` and shut down gracefully, which it does in older versions of `npm` (e.g., `v8.19.4`) but fails in newer versions (e.g., `v9.6.7`). Reverting this change will restore the expected behavior for signal handling in `npm` - npm/cli#6547 - npm/cli#6684 - #142
Since [email protected] which depends of @npm/[email protected] (in which the regression was fixed), everything works fine for me :). |
I've faced the same issue... |
I can confirm that npm version 10.3.0 does forward the signals as expected. |
I think this is still happening on Ubuntu 20.04.6 LTS with node 18.20.0 and npm 10.5.0 |
We have tested 10.3.0 and 10.5.0 on Node 21.7.3 & MacOS Sonoma and unfortunately the problem is still there. |
I am able to reproduce on npm 10.3.0 and node v21.6.2, on macos 13.4 |
Here a small repository with another example that reproduces the problem: https://github.com/skyrpex/npm-scripts-sigint-problem. The issue happens with npm |
I have created a demo repo to showcase the bug. The repo verifies that this only happens in versions of NPM |
Any news? |
Is there an existing issue for this?
NOTE: I originally posted this issue on nodejs/node but was redirected here.
This issue exists in the latest npm version
Current Behavior
npm doesn't handle SIGTERM like it used to. I noticed this issue specifically when updating node from v20.2.0 to v20.3.0 (npm 9.6.7 to 9.8.1).
Expected Behavior
Expected that the below program exits with code 0 (i.e., npm is aborted by the signal and the script handles the signal as well)
Steps To Reproduce
The below script sends a SIGTERM to the npm process that spawned it. Run
npm run test
with:In package.json
In
test.js
Environment
The text was updated successfully, but these errors were encountered: