What happens when I set up two processes to listen to the same Berkeley socket?

Do messages get routed to both? Neither? One of the two? If so, how?

Concretely, I can start two gunicorn processes with the same path for --bind unix: and no obvious error occurs:

gunicorn --bind=unix:/path/to/some/socket 

This seems like a very simple question, although I have not been able to find a clear-cut answer on SE or elsewhere.

1 Answer 1


Two processes cannot bind (and listen) to the same unix socket. A process which tries to bind to an already existing unix socket will get an EADDRINUSE error.

Concretely, I can start two gunicorn processes with the same --bind unix:/ and no obvious error occurs

It's probable that your gunicorn process is actually removing the socket file before binding to it, and so it ends up binding to a different unix socket.

Keep in mind that the actual address of a unix socket is the device_id:inode tuple, not the path through which it was accessed. If you remove a unix socket, a program which binds to the same path will end up creating a different socket file, with a different inode.

Note: all this applies to "normal", filesystem-resident Unix sockets. Linux also has abstract unix sockets, where the name of the socket is its actual address, and which do not use any kind of filesystem object. For these too, you won't be able to bind two sockets to the same address.

  • 1
    For IP sockets you can have two processes bind, there is a flag for it. And in ether case you could fork after bind. In the case of IP sockets, I have read that the kernel will load balance the work load (this may be simple alternation). My guess is that other socket types are the same. Oct 19, 2020 at 20:24
  • 2
    Your guess is wrong.
    – user414777
    Oct 19, 2020 at 20:24
  • 1
    I mean fork after the bind. Oct 19, 2020 at 20:31
  • 2
    Then both processes could use the same socket, just like two threads of a multithreaded program do. Open files are not per-process objects; any file can be shared between multiple processes. Don't mix that up with SO_REUSEADDR and SO_REUSEPORT which do not work on Unix sockets.
    – user414777
    Oct 19, 2020 at 20:36
  • 1
    @ijoseph if you're on Linux, you can easily check with strace -fe trace=unlink gunicorn .... Most programs which listen on a Unix socket remove it before binding to it; there's no other robust way to do it.
    – user414777
    Oct 19, 2020 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.