47

I'm trying to trace some odd behavior of a few processes and ran into a point I'm not sure how to trace past. The hung process, which I attached to using strace -p showed this:

Process 7926 attached - interrupt to quit
read(3, 

Okay, so it's waiting for input on fd 3, so I went to check what it is:

$ ls -l /proc/7926/fd/3
lr-x------ 1 user grp 64 Mar 15 10:41 /proc/7926/fd/3 -> pipe:[20043922]

Okay, so it's a pipe... now the question -- who is the writer of this pipe? I recall that on Linux there is a special feature for unix domain sockets where you can request a file path that starts with a NUL byte to access the "abstract socket namespace" (mentioned here: http://tkhanson.net/cgit.cgi/misc.git/plain/unixdomain/Unix_domain_sockets.html). I'm not sure if there's something similar for pipes that I could take advantage of, but I haven't found anything.

I was hoping a tool like fuser or lsof might help, but I haven't gotten anywhere.

Any ideas?

3 Answers 3

51

The symlink contents "pipe:[20043922]" are a unique ID; the other end of the pipe will have a matching ID.

(find /proc -type l | xargs ls -l | fgrep 'pipe:[20043922]') 2>/dev/null

should show you both ends of the pipe.

5
  • 1
    Good thinking, thanks! While investigating I also came across this thread here serverfault.com/questions/48330/… so I thought I'd drop the link here too just ffr for others too.
    – FatalError
    Commented Mar 22, 2012 at 13:54
  • Why use find? ls -l /proc/*/fd/* | fgrep 'pipe :[20043922]' is simpler. Commented Aug 12, 2021 at 21:27
  • 1
    @DevenT.Corzine Wildcard expansion might result in a line that is too long, either for the shell or the operating system.
    – Kyle Jones
    Commented Aug 13, 2021 at 23:21
  • Oh, good point. If the wildcard expansion is too much, your find command will still work. Commented Aug 18, 2021 at 3:05
  • find can do the filtering find /proc -lname 'pipe:\[20043922]' 2>/dev/null.
    – Lauri
    Commented Dec 2, 2023 at 10:58
6

You can get the list of processes using the pipe by using lsof command:

lsof | grep 'FIFO.*20043922'

The output will show the readers (in the FD column with entries like 1r) and writers (same columns with entries like 2w).

1
  • This takes long time to get processed, the answer that traverses /proc with find is much faster (or the answer with px for that matter, even though apparently px makes use of lsof as well — it mentions lsof in the output. Presumably it uses some args to narrow down the amount of processing lsof has to do).
    – Hi-Angel
    Commented Nov 17, 2023 at 8:51
4

I'd use px.

Disclaimer: I wrote it, so of course I'm recommending it.

px will tell you which other processes yours is talking to, sudo px 7926 would have gotten you the answer.

Example output (not your PID obviously, but still), scroll to the bottom for pipes tracing:

~ $ sudo px 76572
cat

kernel(0)               root
  launchd(1)            root
    iTerm2(39341)       johan
      iTerm2(39343)     johan
        login(39344)    root
          -fish(39346)  johan
----------> cat(76572)  johan

14.62s ago cat was started, at 2020-09-12T16:20:12+02:00.

Other processes started close to cat(76572):
  CoreServices/mdworker_shared(76468) was started 4m32s before cat(76572)
  CoreServices/mdworker_shared(76475) was started 4m02s before cat(76572)
  CoreServices/mdworker_shared(76541) was started 1m55s before cat(76572)
  cat(76573) was started just after cat(76572)
  sudo px(76583) was started 14.0s after cat(76572)

Users logged in when cat(76572) started:
  johan

2020-09-12T16:20:26.739132: Now invoking lsof, this can take over a minute on a big system...
2020-09-12T16:20:27.052847: lsof done, proceeding.

Others sharing this process' working directory (/Users/johan)
  cat(76573)
  -fish(39346)
  iTerm2(39343)
  login(39344)
  sudo px(76583)

File descriptors:
  stdin : [CHR] /dev/ttys000
  stdout: [PIPE] -> cat(76573) (0x204c1334a30aa50d)
  stderr: [CHR] /dev/ttys000

Network connections:

Inter Process Communication:
  cat(76573): [PIPE] ->0x204c1334a30aa50d

For a list of all open files, do "sudo lsof -p 76572", or "sudo watch lsof -p 76572" for a live view.
~ $
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .