-
Notifications
You must be signed in to change notification settings - Fork 7.3k
net.Server doesn't properly close unix socket on process.exit #3686
Comments
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. |
@bnoordhuis I see that you said..
..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. |
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. |
@bnoordhuis More so dangerous and unpredictable than a TCP port? |
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. |
@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: |
This script (obviously) creates a server and listens on a unix socket.
But when the process exits, if I run the same script again, I get
Calling
server.close()
beforeprocess.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 oftenThe text was updated successfully, but these errors were encountered: