net.Server doesn't properly close unix socket on process.exit

[aslilac]

This script (obviously) creates a server and listens on a unix socket.

var server,
net = require( "net" );

server = net.createServer()

server.listen( "/usr/lib/example", function () {
  console.log( "listening" )
  process.exit()
} )

But when the process exits, if I run the same script again, I get

->  ~  node unix-test.js
Error: listen EADDRINUSE

Calling server.close() before process.exit() fixes it, but if the process crashes without giving me a chance to close the server, or if I use Control C to exit, I can no longer listen to that address.

Running rm /usr/lib/example fixes it, but that's a lot of extra work every time if you have to do it often

[bnoordhuis]

It's a deliberate change, see #3540 for details. Actually, I'm of the opinion that any automatic unlinking is an inherently bad idea so expect this to change even more in the future.

[aslilac]

@bnoordhuis I see that you said..

server.close() unlinks the socket (which perhaps isn't a great idea, either)

..but I don't see an actual reason for why the socket shouldn't be cleared when the server closes. If you run a TCP server (say, for http) and close it, it doesn't claim that :80 is in use. The behavior is inconsistent.

[bnoordhuis]

Because it's dangerous and unpredictable in multi-process setups (and not just cluster). Search the bug tracker and mailing list for reports, there have been a few.

[aslilac]

@bnoordhuis More so dangerous and unpredictable than a TCP port?

[bnoordhuis]

Yes. UNIX sockets are file system entities. There is an inherent race window between closing the socket and unlinking it because you cannot do both at once. You don't have that problem with TCP sockets, it's all handled inside the kernel and hence fully atomic.

The upside is that in node, we first unlink, then close the socket. That works okay in most cases - unless you're in a clustered setup with multiple processes listening on the same socket.

[aslilac]

@bnoordhuis OH, right, the kernel has to reach out to the file system to open and close the socket. I didn't think about that. I'm not sure what problems come from unlinking the socket first, but I'll just trust you. You're the expert c: