/proc/PID/fd/X link number
Solution 1
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.
Solution 2
For sockets you can find more information about the inode in /proc/net/tcp
, /proc/net/udp
or /proc/net/unix
. For example:
ls -l /proc/<pid>/fd
lrwx------ 1 root root 64 May 26 22:03 3 -> socket:[53710569]
We see inode is 53710569.
head -n1 < tcp ; grep -a 53710569 tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
155: 0100007F:001B 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 53710569 1 ffff88011f52c200 300 0 0 2 -1
In this case, this is a listening socket (no remote address), listening on local port 27 (0x1B). IP addresses are 4 bytes in hex in "network notation", you can use inet_ntoa
function to convert it to standard a.b.c.d notation (127.0.0.1 in this case).
Note that these files appear to be 0 bytes but have content if you read them.
Also note that -a
is required with grep since they may (e.g. with unix
) appear to be binary.
Related videos on Youtube
Comments
-
Thanatos almost 2 years
In Linux, in
/proc/PID/fd/X
, the links for file descriptors that are pipes or sockets have a number, like:l-wx------ 1 user user 64 Mar 24 00:05 1 -> pipe:[6839] l-wx------ 1 user user 64 Mar 24 00:05 2 -> pipe:[6839] lrwx------ 1 user user 64 Mar 24 00:05 3 -> socket:[3142925] lrwx------ 1 user user 64 Mar 24 00:05 4 -> socket:[3142926] lr-x------ 1 user user 64 Mar 24 00:05 5 -> pipe:[3142927] l-wx------ 1 user user 64 Mar 24 00:05 6 -> pipe:[3142927] lrwx------ 1 user user 64 Mar 24 00:05 7 -> socket:[3142930] lrwx------ 1 user user 64 Mar 24 00:05 8 -> socket:[3142932] lr-x------ 1 user user 64 Mar 24 00:05 9 -> pipe:[9837788]
Like on the first line: 6839. What is that number representing?
-
Thanatos over 13 yearsThe example, I think, was
pidgin
-- it had a lot of pipes & sockets and other stuff, so was a nice example. One last question: inodes are specific only in the context of a particular filesystem, correct? As in, I could have inode 3 on my/
filesystem, and another (different) inode 3 on my/boot
filesystem. -
Warren Young over 13 yearsYes. In the case of the
/proc
filesystem, inode numbers are just made up on the fly (seeget_next_ino()
infs/inode.c
in the kernel), starting from 0 when the system is freshly booted. The mechanism that makes them up is shared by several of Linux's impersistent filesystems (proc, configfs, ramfs, autofs...) among which inode numbers are unique even though POSIX semantics don't demand it. That's a rather special case, however. The rule you're talking about is typically referenced in connection with normal persistent filesystems like ext3. -
Ohmen about 8 yearsThere's also
/proc/net/tcp6
and/proc/net/udp6
for IPv6. -
matt almost 4 yearsPlease add a reference to confirm that that's indeed an inode.
man page
and search for ` /proc/[pid]/fd/` -
matt almost 4 yearsPlease note that in the case of containers referencing
/proc/net/{pid,tcp,unix}
might not be valid. At least in the case of Docker, each container seems to keep its own version of those files. First, one needs to find PID of the container (docker inspect --format '{{.State.Pid}}' my-container
and then check/proc/{PID}/net/{unix,tcp,udp}
. Note that on host/proc/net
is itself a symlink to/proc/self/net
which is a symlink to/proc/{some_pid}/net
. -
Warren Young almost 4 years@matt The reference is in my comment above: the Linux kernel source code.