Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Somewhere in the middle of my application, the framework I'm using (ROOT) gives me the following error:

 *** Break *** write on a pipe with no one to read it
SysError in <TUnixSystem::UnixSend>: send (Broken pipe)
SysError in <TUnixSystem::DispatchOneEvent>: select: read error on 24
 (Bad file descriptor)

How can I check which process is using this file descriptor, preferably without sudo?

share|improve this question
    
You will not be able to peek into other user's process internals without root obviously. lsof will only show actually useful information for the current user without sudo. –  Niels Keurentjes Apr 15 '13 at 17:23
    
the process's are mine –  RSFalcon7 Apr 15 '13 at 17:29
    
File descriptors are numbered per process, not for the system as whole, since a file descriptor is completely internal to a process; it is not shared externally (therefore, system wide references would not make any sense). The connection a file descriptor represents may involve other processes, but not the descriptor itself. –  goldilocks Apr 15 '13 at 17:31
    
@MichaelMrozek There are useful answers in question at SuperUser that may be interesting for future visitors –  RSFalcon7 Apr 16 '13 at 14:02
1  
@RSFalcon7 That's why we discourage crossposting in the first place. They're merged into this post now –  Michael Mrozek Apr 16 '13 at 14:16
add comment

3 Answers 3

up vote 4 down vote accepted

I am afraid that is impossible afterwards. After all "broken pipe" means that the other process is gone (or has at least closed its file descriptor).

While everything is still OK you can do this:

sleep 1000 | sleep 1000
PID=12345 # PID of one of the sleep processes
ls -l /proc/$PID/fd
# output [...]
l-wx------ 1 hl hauke 64 15. Apr 19:11 1 -> pipe:[108237859]
# output [...]
lsof -n | grep 108237859 # gives you all processes which have access to this pipe
sleep     12928     hl    1w     FIFO     0,8     0t0  108262866 pipe
sleep     12929     hl    0r     FIFO     0,8     0t0  108262866 pipe

Edit 1

If lsof is not available:

for dir in /proc/[1-9]*; do
  test -r "$dir"/fd || continue
  if ls -ln "$dir"/fd | grep -q 108355662; then
    echo "PID: ${dir#/proc/}"
  fi
done
share|improve this answer
    
unfortunately lsof is not available in the cluster –  RSFalcon7 Apr 15 '13 at 17:31
    
lsof does nothing magic, it's just convenient to have it do the work. You can do the proc-walk yourself. I edit my answer for better readability. –  Hauke Laging Apr 15 '13 at 17:45
    
The problem is as you said it is impossible, because the program have lots of files open and I only know the correct file descriptor id after the crash –  RSFalcon7 Apr 15 '13 at 17:57
    
@RSFalcon7 If you want to examine problems that occur with certain processes only then you could watch their /proc/$PID/fd (I don't know whether fileschanged works in /proc; that would be great), log changes and find the respective other process(es) when a new pipe occurs. –  Hauke Laging Apr 15 '13 at 18:00
add comment

Without lsof you could try:

find /proc -name <descriptor> | grep fdinfo

It should return some results of the form ./<pid>/fdinfo/<fd>

share|improve this answer
add comment

The lsof command will show you opened descriptors, then just grep it.

share|improve this answer
    
lsof is not installed in the cluster –  RSFalcon7 Apr 15 '13 at 17:29
    
then you can also use pidoff and look into the /proc/<processid>/fd (guessing the path right now, but it's something like that) –  Fiisch Apr 15 '13 at 17:33
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.