forward signals correctly (was: signals: ignore them) #419

stelcheck · 2017-09-07T08:04:55Z

signals are passed to the spawned child process; this means
that the main process should not react to them, and instead
wait for the spawned process to exit as a result of receiving
the forwarded signal.

coveralls · 2017-09-07T08:09:37Z

Coverage remained the same at 78.1% when pulling 79142b4 on stelcheck:fixes/signals into 2ee9575 on TypeStrong:master.

blakeembrey · 2017-09-07T15:49:32Z

Can you share the situation that this solves? I've never come across this being an issue myself, nor have I seen it handled in other libraries that spawn child processes (https://github.com/babel/babel/blob/777a9ae6e42db1c9d57bbbdca8b233c2dc9b89ac/packages/babel-node/src/babel-node.js).

stelcheck · 2017-09-08T04:07:54Z

Given the following code:

process.on('SIGINT', () => {
  console.log('received sigint')
  setTimeout(() => {
    console.log('exit')
    process.exit(0)
  }, 2000)
})

console.log('running')
require('http').createServer(() => true).listen(8080)

Running directly in node:

$ node index.ts   
running
^Creceived sigint
exit
$

While in ts-node

ts-node index.ts
running
^Creceived sigint

$ exit

As you can see, with ts-node, the exit log is shown after the process has been terminated. This is because the ts-node process need only to forward the signals, not react to them.

npm also suffered from the same problem until 4.5.0, for what it is worth: npm/npm@878aceb

blakeembrey · 2017-09-08T15:13:32Z

Awesome, thanks. Do you think we get add a test case so this doesn't occur in the future?

stelcheck · 2017-09-08T18:13:55Z

I wrote a quick sample test, but for some reason, the child process does not get killed at all. Will look into it a bit further.

coveralls · 2017-09-08T18:25:09Z

Coverage decreased (-32.2%) to 45.876% when pulling d3e5eb2 on stelcheck:fixes/signals into 2ee9575 on TypeStrong:master.

coveralls · 2017-09-08T18:30:05Z

Coverage decreased (-32.5%) to 45.596% when pulling 98ae8b8 on stelcheck:fixes/signals into 2ee9575 on TypeStrong:master.

coveralls · 2017-09-08T18:33:03Z

Coverage decreased (-32.6%) to 45.455% when pulling b91ccb8 on stelcheck:fixes/signals into 2ee9575 on TypeStrong:master.

stelcheck · 2017-09-08T18:35:12Z

src/index.spec.ts

+        return done()
+      })
+
+      setTimeout(() => proc.kill('SIGTERM'), 100)


For some reasons, the kill signal is not properly sent.

Would it work if you forwarded the signals to the child? It's possible that the current code change is just ignoring the signal.

stelcheck · 2017-09-09T08:00:41Z

The point of this test is to ensure that the signal is properly caught by the binary, not by the child.

I tried to use 'SIGKILL', and that didn't work either, so maybe Mocha is getting in the way...

coveralls · 2017-09-09T09:33:43Z

Coverage decreased (-32.5%) to 45.596% when pulling 7a6b94a on stelcheck:fixes/signals into 2ee9575 on TypeStrong:master.

stelcheck · 2017-09-09T12:12:49Z

Found the issue. In a nutshell, signals triggered by keyboard interrupts are sent to the process and all subprocesses at once, except if the suprocess was spawned in detached mode.

The solution is to detach the subprocess and manually forward relevant signals. I have found three so far:

SIGINT
SIGTERM
SIGWINCH (for cases where the terminal size is changed)

Will update the PR shortly, but have already updated its title. I am trying to add a test to verify that keyboard interrupts have the same behavior as sending a signal to the top process first to make sure behavior always remain consistent.

stelcheck · 2017-09-09T13:16:24Z

I gave up on testing specifically for keyboard interrupts. If you know of a way to test for that and would like me to do so, please let me know how I could set up the test.

coveralls · 2017-09-09T13:16:44Z

Coverage decreased (-32.4%) to 45.736% when pulling d84900b on stelcheck:fixes/signals into 2ee9575 on TypeStrong:master.

coveralls · 2017-09-09T13:26:48Z

Coverage decreased (-32.4%) to 45.736% when pulling 21bb4bc on stelcheck:fixes/signals into 2ee9575 on TypeStrong:master.

coveralls · 2017-09-09T13:29:17Z

Coverage decreased (-32.4%) to 45.736% when pulling 77b44d8 on stelcheck:fixes/signals into 2ee9575 on TypeStrong:master.

stelcheck · 2017-09-09T13:31:35Z

This passes just fine on my desktop (Linux), so I am not sure as to why it would fail on CI. Apologies for the spam.

coveralls · 2017-09-09T13:42:22Z

Coverage increased (+0.6%) to 78.718% when pulling 88bac37 on stelcheck:fixes/signals into 2ee9575 on TypeStrong:master.

stelcheck · 2017-09-09T13:49:48Z

travis-ci/travis-ci#704 (comment)

stelcheck · 2017-09-14T03:54:56Z

All tests are now passing. Please let me know if further changes are warranted before this can be merged.

blakeembrey · 2017-10-11T20:02:48Z

src/bin.ts

+  proc.on('close', (code: number, signal: string) => {
+    if (signal) {
+      process.kill(process.pid, signal)
+    } else if (code) {


Do we need to check the else if here? If it closes, shouldn't it have one or the other? In a hypothetical case it has neither, wouldn't we still want to exit?

I think we want the process to exit naturally (no process.exit) upon a signal, but to exit with a code when there is one.

blakeembrey · 2017-10-11T20:06:26Z

src/bin.ts

-    })
+  // Ignore signals, and instead forward them to the
+  // child process
+  const forward = (signal: string) => process.on(signal, () => proc.kill(signal))


Probably easier just to make this an array loop. The comments are super verbose and mostly unnecessary too. E.g.

['SIGINT', 'SIGTERM', 'SIGWINCH'].forEach(signal => process.on(signal, () => proc.kill(signal))

TBH I never remember what SIGWINCH does, hence why I wrote it in a slightly more verbose way. If you consider this a blocker, I will change it, of course.

blakeembrey · 2017-10-11T20:12:35Z

Are you absolutely sure we need to be running in detached mode? Even NPM doesn't run in detached mode and based on https://github.com/npm/lifecycle/blob/latest/index.js they just forward the two signals specifically.

Edit: This was based on a reference to NPM I can no longer see in the issue, sorry if I'm mixing the issues up 😄

stelcheck · 2017-10-12T03:15:50Z

#419 (comment) Gives the explanation. We forward terminal size change as well since programs may be long-running and meant to be executed within a terminal (e.g a REPL interface, or something like htop)

narthur157 · 2017-10-25T16:14:07Z

Would like to see this PR go in, currently this kills my workflow because I have a zombie proc every time I Ctrl+C out of ts-node, leaving the port binded

stelcheck · 2017-10-26T02:47:55Z

@narthur157 I take it you tested this PR against your use case? If not, could you give it a spin to confirm it would solve your problem properly?

endel · 2017-11-05T01:38:30Z

I've just sent a simpler alternative to the same problem here: #458

endel · 2017-11-11T18:41:10Z

src/bin.ts

-    })
+  // Ignore signals, and instead forward them to the
+  // child process
+  const forward = (signal: string) => process.on(signal, () => proc.kill(signal))


On the latest version of NodeJS type definitions, signal should be of type NodeJS.Signals instead of string. (it's not compiling)

endel · 2017-11-11T18:42:42Z

src/bin.ts

+
+  // If this process is exited with any other signals,
+  // kill the subprocess with the same signal
+  process.on('exit', (_code: number, signal: string) => proc.kill(signal))


On the latest version of NodeJS type definitions, the "exit" callback only accepts one argument. (it's not compiling)

signals are passed to the spawned child process; this means that the main process should not react to them, and instead wait for the spawned process to exit as a result of receiving the forwarded signal.

coveralls · 2017-11-22T10:35:05Z

Coverage increased (+0.8%) to 77.616% when pulling 31d5a34 on stelcheck:fixes/signals into c57ded2 on TypeStrong:master.

stelcheck · 2017-11-23T02:42:16Z

@endel fixed the two issues you reported.

What do we need to do to get this in? I'd like to do everything I can ASAP to get this merged (and hopefully released in a timely fashion), so if there is anything else I would need to do or any other concerns I would need to research or address, please let me know.

stelcheck · 2017-12-07T02:03:27Z

Apologies for insisting, but is there anything that needs to be done to get this merged?

coveralls · 2017-12-10T22:44:27Z

Coverage increased (+0.6%) to 77.427% when pulling 986ffa8 on stelcheck:fixes/signals into c57ded2 on TypeStrong:master.

stelcheck · 2017-12-10T23:06:20Z

Thank you! Let me know if I can ever be of any further help.

endel · 2018-01-20T18:20:24Z

@stelcheck @blakeembrey It seems the problem still persists when using child processes (cluster module). Here's an issue and example project demonstrating the problem: #519

stelcheck mentioned this pull request Sep 7, 2017

ts-node catches the signal and exits pre-emptively mage/mage#155

Closed

stelcheck force-pushed the fixes/signals branch from 79142b4 to d3e5eb2 Compare September 8, 2017 18:12

stelcheck force-pushed the fixes/signals branch from d3e5eb2 to 98ae8b8 Compare September 8, 2017 18:24

stelcheck force-pushed the fixes/signals branch from 98ae8b8 to b91ccb8 Compare September 8, 2017 18:29

stelcheck commented Sep 8, 2017

View reviewed changes

stelcheck force-pushed the fixes/signals branch from b91ccb8 to 7a6b94a Compare September 9, 2017 09:29

stelcheck changed the title ~~signals: ignore them~~ forward signals correctly (was: signals: ignore them) Sep 9, 2017

stelcheck force-pushed the fixes/signals branch from 7a6b94a to d84900b Compare September 9, 2017 13:14

stelcheck force-pushed the fixes/signals branch 2 times, most recently from 21bb4bc to 77b44d8 Compare September 9, 2017 13:25

stelcheck force-pushed the fixes/signals branch from 77b44d8 to 88bac37 Compare September 9, 2017 13:38

stelcheck force-pushed the fixes/signals branch from 88bac37 to be4e7e5 Compare September 9, 2017 13:47

blakeembrey reviewed Oct 11, 2017

View reviewed changes

endel reviewed Nov 11, 2017

View reviewed changes

forward signals correctly

31d5a34

signals are passed to the spawned child process; this means that the main process should not react to them, and instead wait for the spawned process to exit as a result of receiving the forwarded signal.

stelcheck force-pushed the fixes/signals branch from 4987bab to 31d5a34 Compare November 22, 2017 10:32

stelcheck mentioned this pull request Dec 7, 2017

When will be the next release? #468

Closed

blakeembrey added 2 commits December 10, 2017 14:35

Update bin.ts

2486cca

Update bin.ts

986ffa8

blakeembrey merged commit be7895c into TypeStrong:master Dec 10, 2017

This was referenced Dec 10, 2017

ts-node doesn't handle graceful shutdown properly #457

Closed

graceful shutdown #458

Closed

blakeembrey mentioned this pull request Dec 14, 2017

Does not work after upgrading to 4.0.0 #480

Closed

dickon mentioned this pull request Dec 19, 2017

Disable detaching sub-process on Windows #489

Merged

endel mentioned this pull request Jan 20, 2018

graceful shutdown using child processes #519

Closed

endel mentioned this pull request Jan 20, 2018

child process living despite of parent process interrupted. #509

Closed

anthonyalayo mentioned this pull request Jun 4, 2021

Forwarding signals correctly to child process wclr/ts-node-dev#269

Merged

anthonyalayo mentioned this pull request Jul 5, 2021

ts-node-dev doesn't allow graceful shutdowns when managed by external processes wclr/ts-node-dev#282

Open

forward signals correctly (was: signals: ignore them) #419

forward signals correctly (was: signals: ignore them) #419

Conversation

stelcheck commented Sep 7, 2017

coveralls commented Sep 7, 2017 • edited Loading

blakeembrey commented Sep 7, 2017

stelcheck commented Sep 8, 2017 • edited Loading

blakeembrey commented Sep 8, 2017

stelcheck commented Sep 8, 2017

coveralls commented Sep 8, 2017 • edited Loading

coveralls commented Sep 8, 2017 • edited Loading

coveralls commented Sep 8, 2017 • edited Loading

stelcheck Sep 8, 2017

Choose a reason for hiding this comment

blakeembrey Sep 8, 2017

Choose a reason for hiding this comment

stelcheck commented Sep 9, 2017

coveralls commented Sep 9, 2017 • edited Loading

stelcheck commented Sep 9, 2017

stelcheck commented Sep 9, 2017

coveralls commented Sep 9, 2017 • edited Loading

coveralls commented Sep 9, 2017 • edited Loading

coveralls commented Sep 9, 2017 • edited Loading

stelcheck commented Sep 9, 2017

coveralls commented Sep 9, 2017 • edited Loading

stelcheck commented Sep 9, 2017

stelcheck commented Sep 14, 2017

blakeembrey Oct 11, 2017

Choose a reason for hiding this comment

stelcheck Oct 12, 2017

Choose a reason for hiding this comment

blakeembrey Oct 11, 2017

Choose a reason for hiding this comment

stelcheck Oct 12, 2017

Choose a reason for hiding this comment

blakeembrey commented Oct 11, 2017 • edited Loading

stelcheck commented Oct 12, 2017

narthur157 commented Oct 25, 2017

stelcheck commented Oct 26, 2017

endel commented Nov 5, 2017

endel Nov 11, 2017

Choose a reason for hiding this comment

endel Nov 11, 2017 • edited Loading

Choose a reason for hiding this comment

coveralls commented Nov 22, 2017 • edited Loading

stelcheck commented Nov 23, 2017

stelcheck commented Dec 7, 2017

coveralls commented Dec 10, 2017 • edited Loading

stelcheck commented Dec 10, 2017

endel commented Jan 20, 2018

coveralls commented Sep 7, 2017 •

edited

Loading

stelcheck commented Sep 8, 2017 •

edited

Loading

coveralls commented Sep 8, 2017 •

edited

Loading

coveralls commented Sep 8, 2017 •

edited

Loading

coveralls commented Sep 8, 2017 •

edited

Loading

coveralls commented Sep 9, 2017 •

edited

Loading

coveralls commented Sep 9, 2017 •

edited

Loading

coveralls commented Sep 9, 2017 •

edited

Loading

coveralls commented Sep 9, 2017 •

edited

Loading

coveralls commented Sep 9, 2017 •

edited

Loading

blakeembrey commented Oct 11, 2017 •

edited

Loading

endel Nov 11, 2017 •

edited

Loading

coveralls commented Nov 22, 2017 •

edited

Loading

coveralls commented Dec 10, 2017 •

edited

Loading