Hi all,
I'm attempting to track down a spooky problem with some code that I've
written (running under the 2.6.11.12 kernel) and am wondering if there's a
way to track (via /proc) both ends of an open pipe that was created with a
pipe(2) system call... It appears that I've got a bunch of spawned
processes stuck in some kind of sleep caused by a read(2) on the
read-end of a pipe and would like to eliminate the possibility that I've
done something truly bone-headed in my code like leaving the write-end
of the pipe open in another process. (I don't think I did, but want to
be sure :).
I know that the symlinks in the /proc/<pid>/fd directory point to
bogus filenames for pipes (i.e. 'pipe:[64682]') and am wondering if
every process that reads and writes from that pipe will share the same
bogus symlink name.
In essence, I'm wondering if there's any way to list all of the pid's
of processes using an anonomous pipe.
Please CC me on any answers.
Thanks,
John
John Schmerge <[email protected]> wrote:
> I know that the symlinks in the /proc/<pid>/fd directory point to
> bogus filenames for pipes (i.e. 'pipe:[64682]') and am wondering if
> every process that reads and writes from that pipe will share the same
> bogus symlink name.
yes
> In essence, I'm wondering if there's any way to list all of the pid's
> of processes using an anonomous pipe.
man find. I don't know a bettre way.
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
Bodo,
Thanks for the answer... I've got one more question: will the symlinks
to the pipe be the same for both the read and write ends in all
processes sharing the pipe?
I've got some sort of funky race condition occurring between the read
from the pipe and the exiting of the process on the write-end of the pipe...
The read-process is supposed to exit after the write-process finishes
(and does in about 1/2 the time), but I think I'm seeing the read-process
blocked by something even after the write-process completes... Both top
and ps give no indication that the read-process is blocked on a read(2).
I've got some digging to do, but I'm thinking that this might actually be
a kernel bug.
Thanks,
John
On Wed, 8 Feb 2006, Bodo Eggert wrote:
> John Schmerge <[email protected]> wrote:
>
> > I know that the symlinks in the /proc/<pid>/fd directory point to
> > bogus filenames for pipes (i.e. 'pipe:[64682]') and am wondering if
> > every process that reads and writes from that pipe will share the same
> > bogus symlink name.
>
> yes
>
> > In essence, I'm wondering if there's any way to list all of the pid's
> > of processes using an anonomous pipe.
>
> man find. I don't know a bettre way.
> --
> Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
> verbreiteten L?gen zu sabotieren.
>
On Wed, 8 Feb 2006, John Schmerge wrote:
> Thanks for the answer... I've got one more question: will the symlinks
> to the pipe be the same for both the read and write ends in all
> processes sharing the pipe?
It seems like yes. You can find it out by sinply trying it out.
> I've got some sort of funky race condition occurring between the read
> from the pipe and the exiting of the process on the write-end of the pipe...
> The read-process is supposed to exit after the write-process finishes
> (and does in about 1/2 the time), but I think I'm seeing the read-process
> blocked by something even after the write-process completes... Both top
> and ps give no indication that the read-process is blocked on a read(2).
> I've got some digging to do, but I'm thinking that this might actually be
> a kernel bug.
Do you close() the writing end in the process that's supposed to read?
--
Top 100 things you don't want the sysadmin to say:
98. What the hell!?
>
>> I know that the symlinks in the /proc/<pid>/fd directory point to
>> bogus filenames for pipes (i.e. 'pipe:[64682]') and am wondering if
>> every process that reads and writes from that pipe will share the same
>> bogus symlink name.
>
It is not really bogus. And it is not really real at the same time.
This is how it works AFAIU: pipes get created in pipefs (cat
/proc/filesystems) (as do sockets in sockfs), and their dentry IS named
"pipe:[46682]". You just can't see it because 1. you are prevented from
mounting pipefs, 2. there are no readdir/etc. functions for pipefs
implemented ATM.
>> In essence, I'm wondering if there's any way to list all of the pid's
>> of processes using an anonomous pipe.
>
Hm. Do you mean list "all pids of procs using an anynymous pipe" or
"list all pids [...]" using an anonymous pipe... :)
AFAICS, the first is not possible; the latter is (a fork-and-exec
thing) is something different.
Jan Engelhardt
--