pipe in /proc

pipe in /proc

Post by Sushanth Ra » Sun, 04 Feb 2001 14:49:21



Hi,

Following is o/p of  "ls -l " command  on a /proc/<pid>/fd directory
which lists all the files opened by the process.

 ls -l
total 0
lrwx------   1 srai     games          64 Feb  2 20:26 0 -> /dev/pts/1
lrwx------   1 srai     games          64 Feb  2 20:26 1 -> /dev/pts/1
lrwx------   1 srai     games          64 Feb  2 20:26 2 -> /dev/pts/1
lr-x------   1 srai     games          64 Feb  2 20:26 3 ->
pipe:[143877]
l-wx------   1 srai     games          64 Feb  2 20:26 4 ->
pipe:[143877]
lrwx------   1 srai     games          64 Feb  2 20:26 5 ->
socket:[143896]
lrwx------   1 srai     games          64 Feb  2 20:26 6 ->
socket:[143897]

Last fours entries are associated with pipes and opened sockets. I am
curious to know what the numbers following the string "pipe" or "socket"
are ?

Sushanth

 
 
 

pipe in /proc

Post by Arthur H. Gol » Mon, 05 Feb 2001 04:18:55



> Hi,

> Following is o/p of  "ls -l " command  on a /proc/<pid>/fd directory
> which lists all the files opened by the process.

>  ls -l
> total 0
> lrwx------   1 srai     games          64 Feb  2 20:26 0 -> /dev/pts/1
> lrwx------   1 srai     games          64 Feb  2 20:26 1 -> /dev/pts/1
> lrwx------   1 srai     games          64 Feb  2 20:26 2 -> /dev/pts/1
> lr-x------   1 srai     games          64 Feb  2 20:26 3 ->
> pipe:[143877]
> l-wx------   1 srai     games          64 Feb  2 20:26 4 ->
> pipe:[143877]
> lrwx------   1 srai     games          64 Feb  2 20:26 5 ->
> socket:[143896]
> lrwx------   1 srai     games          64 Feb  2 20:26 6 ->
> socket:[143897]

> Last fours entries are associated with pipes and opened sockets. I am
> curious to know what the numbers following the string "pipe" or "socket"
> are ?

> Sushanth

MOst likely an inode number.
--ag
--
Artie Gold, Austin, TX  (finger the cs.utexas.edu account
for more info)

--
A: Yes I would. But not enough to put it out.

 
 
 

pipe in /proc

Post by Sushanth Ra » Mon, 05 Feb 2001 12:31:27




> > Hi,

> > Following is o/p of  "ls -l " command  on a /proc/<pid>/fd directory
> > which lists all the files opened by the process.

> >  ls -l
> > total 0
> > lrwx------   1 srai     games          64 Feb  2 20:26 0 -> /dev/pts/1
> > lrwx------   1 srai     games          64 Feb  2 20:26 1 -> /dev/pts/1
> > lrwx------   1 srai     games          64 Feb  2 20:26 2 -> /dev/pts/1
> > lr-x------   1 srai     games          64 Feb  2 20:26 3 ->
> > pipe:[143877]
> > l-wx------   1 srai     games          64 Feb  2 20:26 4 ->
> > pipe:[143877]
> > lrwx------   1 srai     games          64 Feb  2 20:26 5 ->
> > socket:[143896]
> > lrwx------   1 srai     games          64 Feb  2 20:26 6 ->
> > socket:[143897]

> > Last fours entries are associated with pipes and opened sockets. I am
> > curious to know what the numbers following the string "pipe" or "socket"
> > are ?

> > Sushanth
> MOst likely an inode number.

Nope !! Not really. inode numbers look different.
 
 
 

pipe in /proc

Post by Kasper Dupon » Mon, 05 Feb 2001 21:39:09





> > > Hi,

> > > Following is o/p of  "ls -l " command  on a /proc/<pid>/fd directory
> > > which lists all the files opened by the process.

> > >  ls -l
> > > total 0
> > > lrwx------   1 srai     games          64 Feb  2 20:26 0 -> /dev/pts/1
> > > lrwx------   1 srai     games          64 Feb  2 20:26 1 -> /dev/pts/1
> > > lrwx------   1 srai     games          64 Feb  2 20:26 2 -> /dev/pts/1
> > > lr-x------   1 srai     games          64 Feb  2 20:26 3 ->
> > > pipe:[143877]
> > > l-wx------   1 srai     games          64 Feb  2 20:26 4 ->
> > > pipe:[143877]
> > > lrwx------   1 srai     games          64 Feb  2 20:26 5 ->
> > > socket:[143896]
> > > lrwx------   1 srai     games          64 Feb  2 20:26 6 ->
> > > socket:[143897]

> > > Last fours entries are associated with pipes and opened sockets. I am
> > > curious to know what the numbers following the string "pipe" or "socket"
> > > are ?

> > > Sushanth
> > MOst likely an inode number.

> Nope !! Not really. inode numbers look different.

Does the term inode number make any sense in this situation
where it does not reside on any filesystem?

If you look in linux/fs/proc/link.c you will however see
that the value comes from the i_ino variable in an inode
structure.

As far as I can tell the value originates in the function
get_empty_inode() in linux/fs/inode.c. This function just
has a static variable that is 0 when the kernel is booted,
every time get_empty_inode() sucessfully returns an inode
the variable is incremented.

Most of the inode numbers assigned in this way I beleive
is overwritten by the filesystem using them. Only in cases
like pipes and sockets where there is no approriate value
to put in the variable the value is left unchanged.

The value can be used to identify connected endpoints of
sockets and pipes. And they can be used to see which one
was created first.

--
Kasper Dupont

 
 
 

pipe in /proc

Post by Omkar Sath » Fri, 09 Feb 2001 21:42:14


Hello,

I have a strange/interesting  problem due to these pipes.

I have a standard daemon which when invoked, creates a child and the child
tries to write to STDERR/STDOUT. Pls note that I do not close stderr/stdout.
When this daemon is invoked in the standard way by init, whenever the child
tries to write to stdout/err, it gets a sigpipe. I checked that before
invoking the child, the STDOUT  and STDERR points to some pipe as can be
seen in the /proc/<pid>/fd. Now when it forks a process which writes to
STDOUT/ERR, it(the child, not the parent) gets a SIGPIPE  and gets killed. I
could not figure out why Linux is behaving like this !

BUT if after the system startup, I start the daemon at prompt, everything
works OK.

Can somebody explain why this is happening ?
I can send the code upon request. I invoke the daemon by sending a TSTP to
the daemon.

Thanks in advance,
-omkar sathe





 
 
 

pipe in /proc

Post by Kasper Dupon » Fri, 09 Feb 2001 22:43:12



> Hello,

> I have a strange/interesting  problem due to these pipes.

> I have a standard daemon which when invoked, creates a child and the child
> tries to write to STDERR/STDOUT. Pls note that I do not close stderr/stdout.
> When this daemon is invoked in the standard way by init, whenever the child
> tries to write to stdout/err, it gets a sigpipe. I checked that before
> invoking the child, the STDOUT  and STDERR points to some pipe as can be
> seen in the /proc/<pid>/fd. Now when it forks a process which writes to
> STDOUT/ERR, it(the child, not the parent) gets a SIGPIPE  and gets killed. I
> could not figure out why Linux is behaving like this !

> BUT if after the system startup, I start the daemon at prompt, everything
> works OK.

> Can somebody explain why this is happening ?
> I can send the code upon request. I invoke the daemon by sending a TSTP to
> the daemon.

> Thanks in advance,
> -omkar sathe






If a process writes to a pipe which has no readers
the process will get a SIGPIPE signal.

When an (unnamed) pipe is created with the pipe()
system call, the creating process is the only
reader and writer.

Children will inherit the fd's from their parent,
and thus become readers and/or writers. When there
is no readers it is because all readers have died
or closed their conection to the pipe.

Try the command: ls -l /proc/*/fd/* | grep pipe:
and look for readers connected to the pipe.

Do you know which program creates the pipe, and
which program is supposed to read from the pipe?

--
Kasper Dupont

 
 
 

1. PROPOSAL: /proc standards (was dot-proc interface [was: /proc

Just think about it for a minute.

There are three ways to address "/proc":
 - 100% binary interface
  * human interaction doesn't belong in the kernel - period.
 - optimally formated text
  * not designed for humans, but in human format ("text")
 - human readable
  * thus the entire OS is reduced to "cat" and "echo"

Providing more than one interface/format means code duplication.  It doesn't
matter how much is actually compiled.  Someone has to write it.  Others have
to maintain it.  Suddenly a change in one place becomes a change in dozens
of places.

Personally, I vote for a 100% binary interface. (no surprise there.)  It
makes things in kernel land so much cleaner, faster, and smaller.  Yes,
it increases the demands on userland to some degree.  However, printf/scanf
is one hell of a lot more wasteful than a simple mov.

For my worst case scenerio, answer this:
  How do you tell how many processors are in a Linux box?

The kernel already knows this, but it isn't exposed to userland.  So, one
must resort to ass-backward, stupid shit like counting entries in
/proc/cpuinfo.  And to make things even worse, the format is different for
every arch! (I've been bitching about this for four (4) years.)

And for those misguided people who think processing text is faster than
binary, you're idiots.  The values start out as binary, get converted to
text, copied to the user, and then converted back to binary.  How the hell
is that faster than copying the original binary value? (Answer: it isn't.)

And those who *will* complain that binary structures are hard to work with,
(you're idiots too :-)) a struct is far easier to deal with than text
processing, esp. for anyone who knows what they are doing.  Yes, changes
to the struct do tend to break applications, but the same thing happens
to text based inputs as well.  Perhaps some of you will remember the stink
that arose when the layout of /proc/meminfo changed (and broke, basically,
everything.)

--Ricky

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. How to execute a command n times in Bourne shell?

3. PROPOSAL: /proc standards (was dot-proc interface [was: /proc stuff])

4. 2 Gig File Size Limitations in Unix - help needed by newbie

5. dump pipe gzip pipe ssh pipe dd... blocksize?

6. Dumb newbie question

7. socket vs pipe difference in /proc/pid/fd

8. Problem using the Chooser to select a host CDE login

9. /proc/stat description for proc.txt

10. /proc/mounts or /proc/mtab

11. what does /proc or proc stand for?

12. /proc/net/tcp and /proc/net/udp

13. /proc/kcore vs. /proc/meminfo