If its target is deleted, an entity in /proc/$PID/fd/
appears as a broken symbolic link when you use ls(1)
or file(1)
, but it indeed acts differently when being opened with open(2)
.
On my Debian 9 I used strace(1)
to see what happens when I try to read a symlink. The command is sudo strace cat "$symlink"
. The relevant line from stderr is
either OK
open("$symlink", O_RDONLY) = 3
or ENOENT
open("$symlink", O_RDONLY) = -1 ENOENT (No such file or directory)
(note: I'm not saying these are all possible outcomes of open(2)
in general).
The results:
| regular symlink | /proc/$PID/fd/$N |
---------------+-----------------+------------------+
exists, valid | OK | OK |
exists, broken | ENOENT | OK | <- the difference
doesn't exist | ENOENT | ENOENT |
---------------+-----------------+------------------+
I also learnt that when I run file "$symlink"
, it calls lstat(2)
, readlink(2)
and stat(2)
. These are system calls that base on paths, not file descriptors. If the symlink exists (valid or broken), open(2)
is never called to open it or its target. ENOENT
from stat(2)
indicates the link is broken.
My conclusion is: "broken link" is a property derived from the output of some system call(s); but when you open a link from /proc/$PID/fd/
, open(2)
just knows what to do with it and doesn't care what other tool(s) would yield.
Note the entire /proc
only fakes a "normal" filesystem. Few quirks:
- Files may have dynamic content, yet they are not being modified with system calls (try
inotifywait
).
- Objects may (dis)appear, yet they are not being created nor deleted with system calls (again
inotifywait
).
- In some sense objects may not exist until you interact with them. Run
bash
and wait few minutes. Invoke ls -l /proc/$$/fd
to see its file descriptors. Probably ctimes will show "this very moment". Yet if you repeat the command every few seconds, you will notice the ctimes never change. (Trivia: at first I though I could answer this question Determine how long a file has been open with stat
and symlinks in /proc/$PID/fd/
but I was wrong; now you know why).
No wonder these symlinks you ask about don't behave like regular symlinks in some circumstances. The entire /proc
was designed to behave somewhat differently. I suppose open(2)
was deliberately given the ability to take advantage of it.