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.

May be a regression of #860, #1360?

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 21
  • Comments: 90 (45 by maintainers)

Commits related to this issue

Most upvoted comments

will be fixed for webpack@5

still in 3.2.1 my solution:

// webpack.development.js
const kill = require('tree-kill')

const pid = process.pid
process.on('SIGINT', function () {
  kill(pid, 'SIGKILL')
})

Problem found, we use server.close before run process.exit (close all connections, watchers and etc stuff). server.close use webpackDevMiddleware.close method, what use watching.close (when you in not lazy mode - using webpack-dev-server), but watching.close wait until all was compiled.

What we need to fix all problem with CRTL+C:

  1. Implement Watching.kill() method in webpack
  2. Add kill option to webpackDevServer.close (by default false)
  3. Use webpackDevServer.close(cb, true) in Server.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 that server is getting passed by value as undefined into the setupExitSignals 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 or next?

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.

process.on('SIGINT', () =>{
    devServer.stop().then(() => {
        process.exit(0);
    });
});

Maybe it is worth mentioning that if i send the SIGINT from htop or kill 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 have index.ts, then you want to use index.tsx, if you add them we need rerun compilation, same for other

In 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:

const { watch } = require('fs');

// Ctrl + C is super duper slow because it has to close a bunch of fs.watch handles. Let's just skip
// all that.
// https://github.com/webpack/webpack-dev-server/issues/1479
process.once('SIGINT', () => {
    Object.getPrototypeOf(watch('.')).close = () => {};
    return true;
});

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:

const fs = require('fs');
const watchers = [];

for (let n = 0; n < 1200; n += 1) {
  watchers.push(fs.watch(process.cwd()));
}

console.time('close');
for (let w of watchers) {
  w.close();
}
console.timeEnd('close');

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

The error (in this case, at least) appears to occur when the dev server gets stuck compiling. Ctrl+C at this point doesn’t actually end any processes - all 3 processes listed above remain active after sending SIGINT to the yarn process.

The same happens for me on Linux (up-to-date ArchLinux). Also it drains 100% of one CPU core.