webpack-dev-server: can't close webpack-dev-server --progress with Ctrl + C
- Operating System: macOS High Sierra (10.13.6)
- Node Version: v10.9.0
- NPM Version: 6.2.0
- webpack Version: 4.16.5
- webpack-dev-server Version: 3.1.5
- This is a bug
- This is a modification request
Code
Running the dev server with: yarn webpack-dev-server --progress
. I’m not including webpack configs since seems to be reproducing on a variety of projects, so I assume it’s something that happens regardless of the config? (Happy to provide more info otherwise).
Expected Behavior
Ctrl + C stops the dev server.
Actual Behavior
Ctrl + C does not do anything, dev server continues to compile modules.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 21
- Comments: 90 (45 by maintainers)
will be fixed for webpack@5
still in 3.2.1 my solution:
Problem found, we use
server.close
before runprocess.exit
(close all connections, watchers and etc stuff).server.close
usewebpackDevMiddleware.close
method, what usewatching.close
(when you in not lazy mode - usingwebpack-dev-server
), butwatching.close
wait until all was compiled.What we need to fix all problem with
CRTL+C
:Watching.kill()
method in webpackkill
option towebpackDevServer.close
(by defaultfalse
)webpackDevServer.close(cb, true)
inServer.close
.If somebody have time to help with this issue PRs welcome
Any update on this?
The offer on eating my hat still stands. I just can’t imagine a scenario in which a file would be corrupted by a dangling inotify handle. In fact, I’d go so far to say that any such corruption would warrant a CVE in the Linux kernel followed by a hushed patch by Google’s top minds.
On the other hand calling process.exit will almost definitely cause partially written files to be flushed to the filesystem since the process terminates with open descriptors (of the mode == “w” kind).
I have a great deal of respect for your contributions to Webpack but I do think that leaving the watch handles open is a safer workaround in this case.
Seeing the same happening with webpack-dev-server 3.10.1, webpack 4.41.5 on Linux, compilation progress continues. FWIW, <kbd>Ctrl</kbd>+<kbd>\ </kbd> (sends SIGQUIT) works immediately for me. (same caveats apply as other “kill” solutions)
Having the issue on Linux and Mac with webpack-dev-server
v3.1.8
.@evilebottnawi A bug was introduced when the
setupExitSignals
helper was added, related to this issue. The problem is thatserver
is getting passed by value as undefined into thesetupExitSignals
function, and the function will never see the defined server object:https://github.com/webpack/webpack-dev-server/blob/a28800dbe3b490360fd41c41802483c14e7d01db/bin/webpack-dev-server.js#L21-L23
Should we fix this on
master
ornext
?Hi, I am having an issue with might be related.
I start WebpackDevServer from a script, but when I Cmd+C to close it, the script stops immediately (at least the terminal looks like it did), but then not only additional output appears from webpack (the line with “gracefully shutdown”) but also, if i try to input characters such as up/down arrows they appear as
[OB^[OB
.I am wondering if i need to wait for webpack in anyway from within my script.
I tried but did not work.
Maybe it is worth mentioning that if i send the SIGINT from
htop
orkill
it does works as expected: it prints the “gracefully shutdown message” then waits for the file watches to close, and even prints a “done” afterwards.In your opinion, is this related to the webpack - script interaction, or is it a terminal/zsh related issue (given that SIGINT is handled correct when coming from a source different than Cmd+C) ?
Yes, because you can add
index.ts
and we need to watch these adding, for example you haveindex.ts
, then you want to useindex.tsx
, if you add them we need rerun compilation, same for otherIn stage when webpack try to write caches, it is based on many metrics, hard to say, but I think in this case webpack should skip broken cache and try to create new
I’m working around this now by adding this to my webpack.config.js:
yes I passed here https://github.com/webpack/watchpack/blob/master/lib/watchEventSource.js#L194 then https://github.com/webpack/watchpack/blob/master/lib/watchEventSource.js#L75
So I can now reproduce easily the slowness on my laptop:
These fs.FSWatcher instances are slow to close (~4.7s on my laptop)
yes sorry I try to debug this more and more deeply between my meetings 😅
Still the same issue in Webpack 4.46.0 + webpack-dev-server 3.11.2 on Win 10. Pretty frustring to not being able to stop a process when
--progress
is true and have to wait for it everytime. Can’t switch to Webpack 5, unfortunately, but anybody perhaps knows if this is already fixed in Webpack 5? thanks!@danburzo Awesome, reproduce problem on
linux
(Ubuntu
) too@evilebottnawi here you go: https://github.com/danburzo/webpack-dev-server-repro (instructions in Readme)
The same happens for me on Linux (up-to-date ArchLinux). Also it drains 100% of one CPU core.