Assume that you have an application that upon startup creates a unix domain socket and starts listening to it. Then any subsequent instance of the application connects to that socket, passes data to the 1st instance and exits (or just exits if it detects another instance running).

As far as I understand it, this kind of socket is represented as a file on the filesystem. Let's assume that this file gets deleted by a random 3rd party program or by the user. Now subsequent processes won't be able to detect/communicate with the 1st instance.
Can the 1st somehow detect the deletion of the socket-file and then recreate it?


You cannot re-create a Unix socket file that was deleted.

In fact, you can create another socket file with the same path (by trying to bind() the socket file descriptor again to the same address), but any client trying to connect to it will get a "Connection refused" instead of connecting to the socket that was bound to it in the first place.

That's because Unix sockets are basically bound to inodes, not to paths. You can easily check that if your netcat supports Unix sockets:

nc -lU /tmp/old_sock &
[1] 19241
ln -f /tmp/old_sock /tmp/new_sock; rm /tmp/old_sock
     # or mv /tmp/old_sock /tmp/new_sock 
echo yup | nc -U /tmp/new_sock

All your program can do is to close the old socket, create another and bind it to the same address. In order to be notified of the removal of a file, you can use inotify(7) on Linux, kqueue(2) on BSD, or simply do a stat(2) periodically on the path (just like with any other file).

Notice that Linux also has "abstract" Unix sockets -- sockets which are bound to a sequence of bytes[1] instead of any file-system object, and which are not subject to any file-style access rights and cannot be "removed" or moved to a different address.

[1] you can call it a "string", but beware that it can also contain NUL bytes, unlike a file-system path.

  • Ofc, I meant recreate the socket with the same path. Clients will see it after it is recreated since it has the same path, right? (assuming the clients are run after the re-creation of the socket) Feb 3 '19 at 20:58
  • The only way to create a socket file is by bind()ing an AF_UNIX socket file descriptor to it, and you can only do that a single time. If someone deletes your socket file, you'll have to close the old socket and redo the whole socket/bind/listen/accept loop again. If someone removes the /tmp/.X11-unix/X0 file, you'll have to kill and restart the X11 server, you cannot simply re-create it with a different inode and expect the X11 server to listen on it. Please re-read my whole answer, I've explained why. Feb 4 '19 at 1:21
  • If you're going to test that on Linux, notice that new X11 servers and apps are using abstract sockets in preference, which cannot be removed or moved to a different address, as file-based sockets can. Feb 4 '19 at 1:30
  • I only meant that, once deletion has be detected, the listener will destroy the current socket and create a new one using the same name. This will re-create the file on disk and new instances will be able to find it and communicate back to the listener. Feb 6 '19 at 23:27
  • That's no different from any other file, and frankly, in that case I don't see the point of your question: that 3rd party could just kill your server instead of removing its socket (if it can do the latter it can also do the former). If you want an example on how to use inotify/kqueue/fstat from my 4th paragraph and cannot find any example, please ask a question on stackoverflow. Feb 7 '19 at 3:34

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.