File descriptor linked to socket or pipe in proc

Question

Possible Duplicate:
/proc/PID/fd/X link number

i have a question regarding the file descriptors and their linkage in the proc file system. I've observed that if i list the file descriptors of a certain process from proc ls -la /proc/1234/fd i get the following output:

  lr-x------ 1 root   root   64 Sep 13 07:12 0 -> /dev/null
  l-wx------ 1 root   root   64 Sep 13 07:12 1 -> /dev/null
  l-wx------ 1 root   root   64 Sep 13 07:12 2 -> /dev/null
  lr-x------ 1 root   root   64 Sep 13 07:12 3 -> pipe:[2744159739]
  l-wx------ 1 root   root   64 Sep 13 07:12 4 -> pipe:[2744159739]
  lrwx------ 1 root   root   64 Sep 13 07:12 5 -> socket:[2744160313]
  lrwx------ 1 root   root   64 Sep 13 07:12 6 -> /var/lib/log/some.log

I get the meaning of a file descriptor and i understand from my example the file descriptors 0 1 2 and 6, they are tied to physical resources on my computer, and also i guess 5 is connected to some resource on the network(because of the socket), but what i don't understand is the meaning of the numbers in the brackets. Do the point to some property of the resource? Also why are some of the links broken? And lastly as long as I asked a question already :) what is pipe?

Solution 1

Do they point to some property of the resource?

Yes. They're a unique identifier that allows you to identify the resource.

Also why are some of the links broken?

Because they're links to thinks that don't live in the filesystem, you can't follow the link the normal way. Essentially, links are being abused as a way to return the resource type and unique identifier.

what is pipe?

As the name suggests, a pipe is a connection between two points such that anything put in one end comes out the other end.

Solution 2

Try looking here how you can get more information about open pipes:

how-can-i-get-more-info-on-open-pipes-show-in-proc-in-linux

lsof | grep 2744159739

Both commands which are "piped" together must be working correctly, if one of them is not then the pipe is broken. The pipe might be broken also by something else, this was just first that come up in my mind.

Pipes (e.g. in bash/ksh shell it is represented by vertical bar) allow separate processes to comunicate together, to pass information received from one command to another command for next processing. For example:

ls -l | grep testfile