I don't think they're closed, because I would expect that after a close() the fd would disappear, but I see a bunch of lingering fd -> socket[xxxxx] entries with broken symlinks which don't seem to be going away quickly. What causes this state?
Linux – why do I find (under /proc/pid//fd) sockets with broken symlinks
linuxprocsocket
Related Solutions
That's the inode number for the pipe or socket in question.
A pipe is a unidirectional channel, with a write end and a read end. In your example, it looks like FD 5 and FD 6 are talking to each other, since the inode numbers are the same. (Maybe not, though. See below.)
More common than seeing a program talking to itself over a pipe is a pair of separate programs talking to each other, typically because you set up a pipe between them with a shell:
shell-1$ ls -lR / | less
Then in another terminal window:
shell-2$ ...find the ls and less PIDs with ps; say 4242 and 4243 for this example...
shell-2$ ls -l /proc/4242/fd | grep pipe
l-wx------ 1 user user 64 Mar 24 12:18 1 -> pipe:[222536390]
shell-2$ ls -l /proc/4243/fd | grep pipe
l-wx------ 1 user user 64 Mar 24 12:18 0 -> pipe:[222536390]
This says that PID 4242's standard output (FD 1, by convention) is connected to a pipe with inode number 222536390, and that PID 4243's standard input (FD 0) is connected to the same pipe.
All of which is a long way of saying that ls
's output is being sent to less
's input.
Getting back to your example, FD 1 and FD 2 are almost certainly not talking to each other. Most likely this is the result of tying stdout (FD 1) and stderr (FD 2) together, so they both go to the same destination. You can do that with a Bourne shell like this:
$ some-program 2>&1 | some-other-program
So, if you poked around in /proc/$PID_OF_SOME_OTHER_PROGRAM/fd
, you'd find a third FD attached to a pipe with the same inode number as is attached to FDs 1 and 2 for the some-program
instance. This may also be what's happening with FDs 5 and 6 in your example, but I have no ready theory how these two FDs got tied together. You'd have to know what the program is doing internally to figure that out.
/proc/<pid>/exe
does not follow the normal semantics for symbolic links. Technically this might count as a violation of POSIX, but /proc
is a special filesystem after all.
/proc/<pid>/exe
appears to be a symlink when you stat
it. This is a convenient way for the kernel to export the pathname it knows for the process' executable. But when you actually open that "file", there is none of the normal procedure of reading the following the contents of a symlink. Instead the kernel just gives you access to the open file entry directly.
Notice that when you ls -l
a /proc/<pid>/exe
pseudofile for a process whose executable has been deleted the symlink target has the string " (deleted)" at the end of it. This would normally be non-sensical in a symlink: there definitely isn't a file that lives at the target path with a name that ends with " (deleted)".
tl;dr The proc
filesystem implementation just does its own magic thing with pathname resolution.
Best Answer
The socket[xxxxx] symlinks are always broken. There isn't a path you can provide to open a socket with a given inode number.
I tried it and it seems you can't open the file
/proc/pidX/fd/Y
which refers to a socket. However you can if it refers to a real file, even if the file has been deleted. It's not exactly a symlink. It's magic (i.e. a special case).