WSL does not report EADDRINUSE properly

[aharbis]

Problem Description

When developing in WSL and running apps locally (such as Python or Node.js apps) from WSL, it seems that multiple apps can be started on the same port from within WSL, even though I would expect EADDRINUSE to be reported.

I can reproduce this by starting a very basic Node.js (express) app on port 3000, push that app to the background, then start another. The second does not yield an error, and both are running side by side.

Steps to Reproduce

Using the Hello world example app from express:

$ cat index.js
const express = require('express')
const app = express()
const port = 3000

app.get('/', (req, res) => res.send('Hello World!'))

app.listen(port, () => console.log(`Example app listening on port ${port}!`))

Running this and sending it to the background, then confirming the app is listening on that port:

$ node index.js &
[1] 8884

$ curl http://127.0.0.1:3000/
Hello World!

Starting a second app yields no errors, and I can confirm both apps are running side-by-side in the process list:

$ node index.js &
[2] 8897

$ ps aux | grep index.js
aharbis   8884  0.2  0.1 559904 25952 tty3     Sl   19:28   0:00 node index.js
aharbis   8897  0.7  0.1 559904 25648 tty3     Sl   19:30   0:00 node index.js

and curl still works, but of course only receive response from one (first?) app:

$ curl http://127.0.0.1:3000/
Hello World!

Just to confirm that this is a WSL issue, leaving one (or both) of these apps running in WSL, and trying to start the same app from Windows (cmd.exe) I get the expected error:

C:\Users\Aidan Harbison\test>node index.js
events.js:174
      throw er; // Unhandled 'error' event
      ^

Error: listen EADDRINUSE: address already in use :::3000

Expected Behavior

In WSL, trying to start multiple apps or processes that listen on the same port should yield an EADDRINUSE error.

Actual Behavior

In WSL, multiple apps or processes can be started which listen on the same port. No EADDRINUSE error is seen from WSL by starting the second or subsequent processes.

Windows build number

Microsoft Windows [Version 10.0.17763.615]

[aharbis]

I found #2249 as potentially related (or maybe underlying root cause), but did not find any similar reports of the above behavior.

[aharbis]

Just found #2915 which seems to be a match. Sorry for the DUP issue.