Does not shutdown completely when run from the CLI

Question

Does not shutdown completely when run from the CLI

ajotaos opened this issue 4 years ago · 28 comments

After running tsc-watch, on its own, from the CLI and trying to stop it, I'm always requiring an additional Ctrl+C.

Also, when used alongside concurrently, the SIGINT and SIGTERM is not being passed to the code in the onSuccess argument.

How do I tell tsc-watch, when run from the CLI, it should end the process and not remain hanging?

Answer 1 · 2020-11-07T12:16:21.000Z

That's interesting, as I encountered the same issue (Ctrl-C). never thought that the cause is tsc-watch.
But do you think that the SIGINT and SIGTERM is the same issue?

Can you organize a simple example repo to reproduce?

Thanks

Answer 2 · 2020-11-07T13:33:28.000Z

Sure @gilamran

I really think tsc-watch is the responsible for the Ctrl+C. If you were to run tsc --watch and exit with Ctrl+C everything is fine but tsc-watch gets hold up. I'm using tsc --watch as reference since it mentions in the documentation that it's being used underneath.

You can test this separately with npm run watch:ts (tsc-watch hangs) and npm run watch:tsc (tsc --watch exits) or together with npm run watch:*. No matter how you run it or if you add more tasks, watch:ts is always the last one to log and remains exiting forever.

Not always do the SIGINT and SIGTERM handlers are called, it looks random but maybe there's something.

src/index.ts

console.log(`Script has started`);

const intervalId = setInterval(() => {
  console.log('tick');
}, 1000);

process.on('SIGINT', () => {
  clearInterval(intervalId);
  console.log(`Script has ended`);
  process.exit();
});

process.on('SIGTERM', () => {
  clearInterval(intervalId);
  console.log(`Script has ended`);
  process.exit();
});

tsconfig.json

{
  "compilerOptions": {
    "incremental": true,
    "target": "ES2020",
    "module": "CommonJS",
    "strict": true,
    "declaration": true,
    "declarationMap": true,
    "sourceMap": true,
    "rootDir": "./src",
    "outDir": "./dist",
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["./src/**/*"],
  "exclude": ["./node_modules"]
}

package.json

{
  "scripts": {
    "start": "concurrently --kill-others yarn:watch:*",
    "watch:ts": "tsc-watch --onSuccess \"node ./dist\" --noClear",
    "watch:tsc": "tsc --watch"
  },
  "dependencies": {},
  "devDependencies": {
    "concurrently": "5.3.0",
    "tsc-watch": "4.2.9",
    "typescript": "4.0.5"
  }
}

Answer 3 · 2020-11-07T18:13:38.000Z

I have been continuing playing with it and sometimes even though I Ctrl+C it, the process has not been killed.

Answer 4 · 2020-11-07T20:19:55.000Z

Thanks! I'll look into it.

Answer 5 · 2020-11-09T10:48:19.000Z

I did a test (using your example code) and the Ctrl-C did terminate the process (Using SIGINT).
I'm using Mac. What's your OS?

Answer 6 · 2020-11-09T11:59:21.000Z

I'm on Catalina 10..15.7 (the latest one), node 15.1.0, typescript 4.0.5 and tsc-watch 4.2.9.

When running watch:ts it's more subtle, there are hints for example, after Ctrl+C and the line prompt appearing on the terminal that if you push the up arrow button, instead of brining the previous like it will print ^[OA which happens when there's a process running.

It's more noticeable on the start script. In this case it happens the same as previously but the line prompt will not appear.

Answer 7 · 2020-11-09T12:25:37.000Z

I'm using the exact same versions, and Ctrl-C just stops the process... I don't see what you're describing...
What am I missing?

Answer 8 · 2020-11-09T12:30:03.000Z

Does it work for you to video chat it on Zoom to check it out live?

Answer 9 · 2020-11-09T13:51:53.000Z

how can we do a private chat?

Answer 10 · 2020-11-09T13:54:12.000Z

On GitHub? I didn't know it has that feature.

Answer 11 · 2020-11-09T13:54:40.000Z

I see that you're online... lets do zoom now

Answer 12 · 2020-11-09T13:55:48.000Z

https://zoom.us/j/93636684173?pwd=Qlh2RGExTFVoK3JsY25ZQm1GaGg3QT09

Answer 13 · 2020-11-09T13:58:02.000Z

I'm in @gilamran

Answer 14 · 2020-11-09T14:20:38.000Z

Ok, after the Zoom meeting, it appears this issue is occurring only with the Yarn package runner. NPM works fine.

Answer 15 · 2020-11-09T14:59:05.000Z

I've pushed a branch test-kill please try it.

Answer 16 · 2020-11-09T15:34:06.000Z

It worked on the single script watch:ts. The concurrently one start still requires a second Ctrl+C using yarn, on npm it works.

Answer 17 · 2021-01-11T15:18:02.000Z

I'm experiencing this issue as well, is there a patch?

Answer 18 · 2021-02-19T09:47:20.000Z

Took a peek based on @ajotaos's comment, haven't attempted any fixes:

npm forwards sigint and sigterm: https://github.com/npm/cli/blob/e703362b02d672a14a98af8e2f99ae75c1bab945/node_modules/%40npmcli/run-script/lib/signal-manager.js#L4
yarn only forwards sigterm: https://github.com/yarnpkg/yarn/blob/a4708b29ac74df97bac45365cba4f1d62537ceb7/src/util/signal-handler.js#L11
concurrently has special handling for sigint: https://github.com/kimmobrunfeldt/concurrently/blob/b62a2a1c92caa590b78f336cc8fcef745e5a7832/src/flow-control/kill-on-signal.js#L20

Answer 19 · 2021-11-11T01:31:58.000Z

Having similar issue when ctrl + c with yarn

Answer 20 · 2023-07-28T19:00:39.000Z

We've had to move away from tsc-watch due to the number of loose process issues where exiting the process doesn't kill the running subprocess, so we have to manually kill the port after the fact. Also it sometimes just stops compiling at all.

Answer 21 · 2023-07-30T17:00:21.000Z

I've very sorry to hear that, maybe you can provide an example to reproduce the issue?

Answer 22 · 2023-08-14T20:25:46.000Z

We've had to move away from tsc-watch due to the number of loose process issues where exiting the process doesn't kill the running subprocess, so we have to manually kill the port after the fact. Also it sometimes just stops compiling at all.

same problem here.
when vscode is on Auto Attach mode with auto save, or using a debug terminal, each change on the file open a new debug process but don't close the previous one when using the --onSuccess with "npm start" or "node ./outDir".

Answer 23 · 2023-08-14T20:29:36.000Z

@Mujo I'm sorry but I don't understand your reproduction steps... can you give me clear instructions on how to reproduce this?

Answer 24 · 2023-08-14T20:47:09.000Z

Looks like something in most of the projects we use here in work is holding the process.
I tried to create a new project but couldn't reproduce yet. when i find it i will post here again.

Answer 25 · 2024-03-26T10:41:43.000Z

I'm facing the same issue using Turborepo.

Answer 26 · 2024-03-26T13:17:31.000Z

Hey all, tsx does not have any of these issues. It also has a watch mode. https://github.com/privatenumber/tsx

Answer 27 · 2024-03-26T15:41:05.000Z

Is anyone can provide a simple reproduction repo.?

Answer 28 · 2024-07-18T15:04:28.000Z

Hi,

I can't provide a simple reproduction repo right now, but I think you can reproduce the problem by loading a couple queue system. I think they launch subprocess to run and I think they are not close properly on the reload.

The project I'm working use Pubsub and bullmq to handle messaging and task.

You could try to run a project that run a lot of bullmq worker (I guess more than 10 should do it).