Gatsby: [gatsby develop] Exiting via Ctrl-C leaves terminal/shell in a bad state (Linux/Mac)

[rjray]

Description

When exiting gatsby develop via ^C, the terminal is almost always left in a noecho state. I have observed this on MacOS and Linux both.

Steps to reproduce

Run gatsby develop. After it has entered the server loop, hit ^C. Terminal is no longer echoing prompts, etc. back to the console. Running either tset or reset is required.

Expected result

Terminal should return to the state it was in before gatsby changed it.

Actual result

Terminal is unusuable.

Environment

System:
OS: Linux 3.13 Ubuntu 14.04.6 LTS, Trusty Tahr
CPU: (12) x64 Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
Shell: 4.3.11 - /bin/bash
Binaries:
Node: 12.6.0 - /home/linuxbrew/.linuxbrew/bin/node
npm: 6.9.0 - /home/linuxbrew/.linuxbrew/bin/npm
Languages:
Python: 2.7.6 - /usr/bin/python
Browsers:
Chrome: 76.0.3809.100
Firefox: 66.0.3
npmPackages:
gatsby: ^2.13.42 => 2.13.42
gatsby-cli: ^2.7.21 => 2.7.21
gatsby-image: ^2.2.7 => 2.2.7
gatsby-plugin-manifest: ^2.2.4 => 2.2.4
gatsby-plugin-mdx: ^1.0.18 => 1.0.18
gatsby-plugin-offline: ^2.2.4 => 2.2.4
gatsby-plugin-optimize-svgs: ^1.0.3 => 1.0.3
gatsby-plugin-react-helmet: ^3.1.2 => 3.1.2
gatsby-plugin-sharp: ^2.2.9 => 2.2.9
gatsby-plugin-styled-components: ^3.1.2 => 3.1.2
gatsby-plugin-typography: ^2.3.2 => 2.3.2
gatsby-remark-images: ^3.1.10 => 3.1.10
gatsby-source-filesystem: ^2.1.6 => 2.1.6
gatsby-transformer-sharp: ^2.2.5 => 2.2.5

[Js-Brecht]

That's interesting 🤔. I don't have that issue, but I am running Ubuntu 18.04, and I don't use bash very often; I mostly spend my time in zsh.

Does it matter what point you send the interrupt? i.e. does it happen during compilation, after the server has started, or both?

It could be caused by this:

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).

gatsby develop is using the readline node interface to listen for the SIGINT signal. Perhaps It is overwriting node's default behavior... and resetting the terminal is not included in the new behavior; it just does a simple process.exit().

There's some things I want to try, but I'm in the middle of work right now, so it will have to wait till later tonight.

[Js-Brecht]

I was able to replicate this problem by simply running gatsby develop with a bash shell.

As I suspected, node's termination process is being overridden by listening for the SIGINT interrupt via readline. As a result, when the process exits, the stdio streams are not reconnected to the shell. It's interesting that this problem only seems to occur when using bash. Perhaps zsh is a little more greedy when cleaning up after a process exits.

Also curious is that this hasn't been noticed before now. That SIGINT code was added 2 years ago.

@rjray can you clone my fork, and see if it fixes the problem?

[terrykwon]

I'm having the same problems as well. Additionally, gatsby develop quitting due to an error (such as Can't resolve ... leaves the terminal in the same state.

(System: MacOS with bash shell)

[Js-Brecht]

@terrykwon Can you clone my fork and try see if it fixes the problem? If you aren't familiar with setting up a dev version of Gatsby, let me know. Note: It's also important to run the command in the context of the site you configured to use the dev Gatsby cli (i.e. npx gatsby develop).

I have been able to replicate the issues using a bash shell, including making a test site generate errors such as Failed to compile (Can't resolve ...) due to not being able to resolve a dependency; not certain if you are referring to any other error. Using my fork fixes the problem, for me. I do not have MacOS, though, and my version of Ubuntu is later than 14.04. Theoretically, it should work for all, but I'd like to know if it resolves the issue in other OS's before issuing a PR.

[terrykwon]

@Js-Brecht Just tried it with both the ctrl-c and Failed to compile... cases and the problem seems to be fixed! Thanks 👍

[Js-Brecht]

Good to hear :slightly_smiling_face:

[wardpeet]

Just to make sure I understand the issue here. When running bash and calling ctr+c it won't close the session? Any problems with windows?

[Js-Brecht]

Every other shell that I've used works. Bash seems to be the culprit here.

[danboyle8637]

I have been dealing with this issue. After ctl+c out of Gatsby develop... my bash shell works but I can't see typing. The development session does successfully close for me.

If I type reset (even though I can't see it) everything resets... ha... and it works again.

[wardpeet]

Published in [email protected], thanks to @Js-Brecht's hard work

[vprasanth]

Thank you, that was so annoying!

[sesteva]

I got the latest 2.12.31 version of gatsby-cli and this problem persists

[Js-Brecht]

What version of Gatsby?

[Korede-TA]

same issue for me using Zsh on MacOS ([email protected], [email protected])

[Js-Brecht]

@Korede-TA what is it that it’s doing/not doing?

[Korede-TA]

@Js-Brecht every so often the hot reloading hangs, and it can't be triggered by refreshing the page. if i hit ctrl-c to kill the gatsby serve command, it doesn't respond either.

[Js-Brecht]

Hmm, gatsby serve doesn't do hot reloading. Do you mean gatsby develop?

[Korede-TA]

yeah that's correct, i mean gatsby develop

[Js-Brecht]

@Korede-TA what version of node are you running?

if i hit ctrl-c to kill the gatsby serve command, it doesn't respond either.

Do you mean that hitting CTRL-C fails to end the process? Or does it successfully end the process and leaves the terminal in an unusable state (output mangled/input hidden)?

One way to test would be to start your process, then do a ps -ef |grep gatsby and take note of your process id (second column). Now, when you hit CTRL-C, go look at the output of that command again, and see if the process is still there.

Another thing you can do, after you hit CTRL-C, type reset and hit enter. See if it restores your terminal.

Does it do the same thing if you use bash or sh? I'm also curious to know if it happens every time you run gatsby develop, or if it's intermittent.

[Korede-TA]

node == v11.0.0

i think it's still running because port 8000 is still open but unresponsive. and lsof -i :8000 still returns the same PID as the gatsby process.

I've only tried Zsh so far. And the error only seems to pop up intermittently, but it disrupts my programming flow significantly because the only way to recover is to terminate the terminal process (which doesn't seem to kill the child process), and hopping into a new terminal session and running kill on the PID

[Js-Brecht]

@Korede-TA this sounds like it's not really related to the original post here; the end result seems similar, but the cause/effect are actually different. It seems like it's more related to the changes made in #22759. I think what you're experiencing really should have its own issue, if you don't mind opening one, because it deserves further investigation. It should get more attention then.