mjhjmtu

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
yup

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.