Web server address already in use

Heya, there seems to be an issue with the web server for testing Babylon not shutting down properly. When I try to start it again, I get the “address already in use” error. Or maybe I’m doing something wrong? I’m using (Ctrl + C) to stop the server, like the guide says (in the “Test and Debug” section). Edit: for now, I’m just closing and restarting the CLI before starting the server again…

Here is the CLI output after starting the server and stopping it with (Ctrl + C)

[18:30:01] webpack is watching for changes


sh-3.2# [12:09:31] Server stopped

[12:09:31] The following tasks did not complete: run, webserver

[12:09:31] Did you forget to signal async completion?

And here is the CLI output when I try to start the server again:

[12:12:20] Server started http://localhost:1338
[12:12:20] Running server
[12:12:20] 'webserver' errored after 21 ms
[12:12:20] Error: listen EADDRINUSE: address already in use
    at Server.setupListenHandle [as _listen2] (net.js:1320:16)
    at listenInCluster (net.js:1368:12)
    at GetAddrInfoReqWrap.doListen (net.js:1505:7)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:71:8)
    at GetAddrInfoReqWrap.callbackTrampoline (internal/async_hooks.js:131:17)
[12:12:20] 'run' errored after 1.17 s
npm ERR! errno 1
npm ERR! babylonjs-gulp@0.0.0 start: `gulp run --max-old-space-size=8192 "run"`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the babylonjs-gulp@0.0.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /var/root/.npm/_logs/2021-09-15T19_12_20_828Z-debug.log

w00t this is weird indeed never had it on Windows will try again on MAC

1 Like

This has happened to me as well. I had to restart windows and it started to work. I bet I had something already using that port running.

1 Like

It’s happening for me every time I start the server, stop it, and try to start it again. LOL so now I just leave it running all the time :man_shrugging: :beers:

Maybe @RaananW would have an idea ?

1 Like

Really it works well enough to just leave it running, and if I close the CLI I can start it again when I need to. I was just worried maybe there was a bug or maybe I did something wrong :sweat_smile:

Is it happening if you stop the server and immediately start it? There is a 3 minutes gap between stopping and starting. In my case there were several hours… 3 minutes is enough for a lot of things :sunglasses: EDIT: Ok, this was an idiotic question :smiley:

1 Like

That’s really interesting. the one thing that I am interested in is this:

which seems to be the core of the issue.

I never experienced this behavior. Can I ask about your work environment? node version, os? anything you feel comfortable to share :slight_smile:

I want to try reproducing this. stopping gulp should stop all tasks. if it doesn’t, it might be an issue on our side.

(EDIT - though it sounds like a “developer answer”, the fact that i don’t experience this issue does NOT mean it doesn’t exist :-))

1 Like


I’m on MacOS, with Node 6.14.15, Gulp CLI version: 2.3.0, Local version: 4.0.0 : :slightly_smiling_face:

Hmm, I’m pretty sure it happens no longer how long I wait, rather right a way or even a few hours later…

EDIT: I just tried to start after waiting 10 mins or so after stopping and it started back up again fine, like you said Roland :+1:

Yep, that’s why I’ve edited my question :smiley:

1 Like

Hmm, well now it’s working, even if i stop and start again right away. IDK, I don’t think I did anything different to produce the error before…

1 Like

seem like the spawned process is forked and running orphan for some reasons only on Linux based devices ?

1 Like

I started to test this and I think it behaves correctly with Administrator rights, it has correctly stopped the server, however w/o admin I got that message I posted before. On Windows obviously :slight_smile:

1 Like

interesting it is only W/O admin rights, I hope @RaananW will have a nice idea :slight_smile:

1 Like

That’s interesting, “npm run start” fails as normal user, so I’ve been using “sudo npm run start”. Is that the recommonded usage I wonder? Or maybe I installed it with the wrong user/permissions?

I never started VS code as admin before. This issue or feature must have been introduced in the near past.

A bit off topic but I had a wtf situation, not with bjs, where npm run start didn’t work but yarn start did…

Another wtf situation. :joy::joy:

1 Like