Try the following shell commands:
mkfifo /tmp/test.pipe ls -1 /tmp > /tmp/test.pipe & rm /tmp/test.pipe mkfifo /tmp/test.pipe cat /tmp/test.pipe & jobs
ls command is just an example and could be any process, that wants to write into the named pipe. The point here is, that the process will block trying to open the pipe for writing. Now, another process comes along and removes the pipe. A new pipe of the same name gets created, and the
cat process (i.e. any process trying to open it for reading) will block waiting for another process to write into the new pipe of the same name. Both processes are waiting for their respective pipe connection. This can be verified by listing the background
I'm not so much concerned about the blocking
cat (or whatever process is trying to read from the pipe), because in reality the process reading from the pipe is actually the one replacing it in the first place. In fact, I don't care about reading processes at all. The
cat only serves my example to prove that indeed both process refer to the same pipe filename, but are obviously using distinct pipe instances. However, note that this deadlock example would block in the inverse case, as well, i.e. a reading process would block forever if the pipe gets deleted without ever being opened for writing.
My focus is on the blocking write process (the
ls in my example). It never gets a chance to realize that the original pipe it is trying to write to has been replaced by a new one of the same name.
Is there any Linux way to identify such situations, i.e. a situation where a process blocks for writing access to a named pipe that doesn't exist anymore? You may assume root privileges, and that I know the PIDs of all processes involved. In particular, I know the writing process that may or may not have run into such a situation. However, I don't know (which is what I want to find out), whether the process actually ran into that problem or not, so I can terminate it. How can I find processes that are blocking for access to a named pipe that doesn't physically exist on the file system anymore?
ls /proc/<PID>/fd doesn't list the file descriptor for either process' access to either pipe, except when both ends of a pipe are connected, i.e.
ls /proc/<PID>/fd will list the file descriptors to a pipe for both processes only after the system call has successfully returned on both its ends. Since in my example there are two distinct half-connected pipes of the same name, neither is listed for either process.