New version (2.8.1) fails with error EADDRINUSE on Windows

[mdudek]

Do you want to request a feature or report a bug?
bug

What is the current behavior?
The version 2.7.1 works flawlessly, but v2.8.1 could not be started with following exception:

Error: listen EADDRINUSE 127.0.0.1:8080
at Object.exports._errnoException (util.js:1024:11)
at exports._exceptionWithHostPort (util.js:1047:20)
at Server.setupListenHandle [as _listen2] (net.js:1319:14)
at listenInCluster (net.js:1367:12)
at GetAddrInfoReqWrap.doListen (net.js:1493:7)
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:97:10)

If the current behavior is a bug, please provide the steps to reproduce.
npm run start

Please mention your webpack and Operating System version.
Webpack 3.5.6
Webpack-dev-server: 2.8.1
Windows 10

[shellscape]

@mdudek I understand that this works differently (at all) between the two versions. However, you haven't really given us much to go off of here. I'm afraid we're going to need a stripped down test repo from you in order to reproduce this. I'd recommend starting with a bare bones project and slowly adding components of your project back in, and that should reveal the culprit. This issue isn't something we're seeing in our tests or examples. We usually close questions (reports of things not behaving without any additional info, or general questions) but we'll leave this open in case your investigation reveals anything out of sorts.

[hallids]

Related: https://stackoverflow.com/questions/46270587/webpack-dev-server-runs-twice/46334672

[httpete]

This is a real issue after I upgraded to node.js 8.5, with wds 2.8.2 on windows 7. if I try to run webpack-dev-server directly it dies. If I do:

"dev-start": "npm run webpack-dev-server -- --config webpack.config.ts --progress --profile --watch",
"webpack-dev-server": "node --max_old_space_size=4096 node_modules/webpack-dev-server/bin/webpack-dev-server.js",

its fine.

[tombarton]

I'm experiencing the same issue on OS X.

Versions:

Node 7.9.0
Webpack 3.6.0
Webpack-dev-server: 2.8.2
OS X 10.12.6

I've put together a really simple repo, that can be found at the link below:

https://github.com/tombarton/webpack-port-issues

I can supply logs if necessary.

As soon as I downgrade to 2.7.1, it works perfectly.

[httpete]

still fails on the latest 2.9.0. EADDRINUSE.

webpack output is served from /
Content not from webpack is served from c:\Users\peters1\bench\um_kb\dist
404s will fallback to /index.html
Error: listen EADDRINUSE 127.0.0.1:9000
at Object._errnoException (util.js:1026:11)
at _exceptionWithHostPort (util.js:1049:20)
at Server.setupListenHandle [as _listen2] (net.js:1343:14)
at listenInCluster (net.js:1391:12)
at GetAddrInfoReqWrap.doListen (net.js:1500:7)
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:100:10)
npm ERR! code ELIFECYCLE

[shellscape]

@tombarton your test repo has a few issues;

1. the package name "test repo" is invalid, npm errors on that.

→ npm install
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN Invalid name: "test repo"

2. your npm script to run it is incorrect:

→ npm run webserver

> testrepo@1.0.0 webserver /Users/powella/Code/github/webpack-port-issues
> node api/src/server.js

module.js:473
      throw err;
      ^

Error: Cannot find module '/Users/powella/Code/github/webpack-port-issues/api/src/server.js'
    at Function.Module._resolveFilename (module.js:527:15)
    at Function.Module._load (module.js:453:25)
    at Function.Module.runMain (module.js:665:10)
    at startup (bootstrap_node.js:187:16)
    at bootstrap_node.js:607:3

  "scripts": {
    "webserver": "node api/src/server.js", <<< bad path and filename
    "test": "echo \"Error: no test specified\" && exit 1"
  },

I'm not sure if you tested this after you created it, but it's completely non-functional even after fixing the errors.

We're going to need a functional, simplistic (meaning no react, no angular, no docker) repo that can consistently, or even semi-consistently, reproduce this issue in order to triage on our end. If that isn't supplied, there's little we can do.

For triaging on your side of the glass, you'll want to debug the port that webpack-dev-server is trying to use and compare that against a list of ports in use on your machines. on OSX that can be achieved by running lsof -i | grep LISTEN. I'm too far removed from Windows to remember how to do the same via CMD.

[tombarton]

I'm an idiot, sorry about that. Will put together a repo that actually works.

[Jotakuun]

I'm having this same issue since I upgraded webpack-dev-server from v.2.6.1 to the latest v.2.9.1.

I figured out I also had webpack-dev-server installed globally, but even uninstalling it I still can't get it working...

Anyway, @httpete solution of running wds script manually from node_modules works in my case but I'm going to downgrade a few versions until we get to a real solution in next version.

OS: Windows 10, Version 1703, Build 15063.608
Node 8.6.0 
Webpack 3.6.0
Webpack-dev-server: 2.9.1

[shellscape]

@Jotakuun you may be stuck on an older version for a while going with that option. no one has produced a reproducible test repo that can be run on a non-windows machine (I haven't run windows in 10 years) and no one who runs Windows has stepped up to debug this as yet. Until one of those two things happens, this is going to be a pervasive issue for the few it effects.

[httpete]

You can't use wds with the command line on windows without this hack. Seems to be a pretty big issue, even on modern versions of node and wds.

[shellscape]

@httpete I understand that this is impacting you directly, but that's quite the dramatic statement considering we've only had a handful of user reports of this 😉 we'd love it if someone could direct their energies into triaging/debugging the root cause of this on their specific Windows environments.

We had another issue that was similar, for example, that was related to a GitBash SIGINT problem on Windows; whereby GitBash wasn't handling that properly and wasn't terminating WDS correctly, which left the server running as a background process that resulted in EADDRINUSE on the next run - that might be something to look into for the cases here as well.

Another route to take might be to look at the running apps and which process is using the port you're attempting to use (default is 8080) by running netstat -a -b.

I'm happy to try and help, answer questions on the code from my end, but this is going to take some effort from one of you all affected to solve.

[httpete]

There is nothing running on that port. This works if I run >npm run dev-start .

"dev-start": "npm run webpack-dev-server -- --config webpack.config.ts --progress --profile --watch", "webpack-dev-server": "node --max_old_space_size=4096 node_modules/webpack-dev-server/bin/webpack-dev-server.js",

this does not: (note how here I use the bin directly, not invoking the other npm run command.

"dev-start": "webpack-dev-server --config webpack.config.ts --progress --profile --watch", "webpack-dev-server": "node --max_old_space_size=4096 node_modules/webpack-dev-server/bin/webpack-dev-server.js",

[shellscape]

@httpete you may wish to try putting a return after line 20 here. That came up as a potential fix in an issue not long ago. Other than that I'm out of ideas.

[shellscape]

Should be fixed by a3f7277, version 2.9.3

[amsterdamharu]

Note that when I had this on Windows with 2.7.1 I could kill node process in task manager and continue. Control + C would "close" webpack dev server but process stays active.

[truetechcode]

I had the same issue on Ubuntu with node 8.16.1 and webpack 4.39.3, I solved it by closing my terminal and reopen it, then it worked as expected, I think this supports what @amsterdamharu noted above.