lkml.org 
[lkml]   [1997]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[: Re: lsof doesn't work without module support?]
Working notes, more or less, on lsof/linux kernel interface.

Comment excerpted from response when I asked if this was
ok to repost:

"
I've floated the idea of doing this to my test system provider to
see how he feels about my having root permission to do lsof testing.
His response might sqaush this idea. :-)
"

--
Raul

-----Forwarded message from Vic Abell <abe@purdue.edu>-----

Reply-To: "Vic Abell" <abe@purdue.edu>
From: "Vic Abell" <abe@purdue.edu>
To: "Raul Miller" <rdm@test.legislate.com>
Subject: Re: lsof doesn't work without module support?
Date: Thu, 18 Dec 1997 15:57:49 -0500

Raul,

You write (ion part):
>
>...
>
>The kernel dependent stuff should go *inside* the kernel, then, so
>that you can have a consistent binary in user space.


This comment made me wonder about the progress of the Linux /proc file
system, so I took another look at in on a Linux 2.1.72 system this
afternoon.

To my surprise, /proc *almost* provides enough data for lsof. So far
I have found missing only these things:

* The file offset, which lsof gets from the file struct. This
ought be provided via /proc/<pid>/fd somehow.

* The socket protocol. If all protocol files in /proc/net
had inode entries, this might not be necessary by doing a reverse
lookup on inode number. But, while proc/net/{tcp,udp,raw,unix}
have inode numbers, /proc/net/ipx doesn't. (I need to support
IPX with lsof, because one test system provider uses it.)

* The peer to which a FIFO is connected. Since a stat(2) of
a FIFO's /proc fd entry yields an inode number, this may not
be necessary.

It seems to me there should be a /proc/fifo file or directory,
ala /proc/net/tcp, that describes all open FIFOs.

I suspect there may be other data missing from /proc that lsof currently
gets via /dev/kmem, but I don't see what they might be at the moment.

One thing I did find is that the symbolic links in /proc/<pid>fd now
point to file names. That's an asset in providing file names, but a
debit in that it used to provide device and inode numbers. An extra
stat(2) will get those values.

One down-side of using /proc is that lsof would need to be setuid(root)
to be able to read info on all processes. Right now lsof only needs
permission to read /dev/kmem, typically by being setgid(kmem). I don't
like setuid(root) and don't know the root password on the systems where
I test lsof -- I'm in the kmem group.

The second down-side is that the use of /proc by lsof would require
it to assume some relationships between pieces of /proc that might not
be there by design or remain. The inode numbers in some, but not
all /proc/net files is a good example.

The whole subject certainly deserves more thought. It might even be
worth my spending time to see how far I could get coding a /proc based
lsof.


Vic


-----End of forwarded message-----

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.034 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site