Hi,
Jean-Loup Risler has already posted a summary on this topic, including
the post by Vic Abell discussing the situation. I have included a ksh script
that someone posted to me. Sorry I haven't kept your name whoever you are.
Don't you just hate mime attachments.
My question;
Hello,
I have lsof installed on a couple of DEC's running DU 3.2b,
and a heap of sgi's. On the DU machines it does not produce the
names of files, just the device names. This is useless.
<snip>examples of the lsof output<snip>
Can any one give me a hint. lsof is a very usefull tool but I need it to
"list open files" not devices.
=======================================================================
>From Keith_MCCABE_at_paribas.com Fri Jan 10 20:21:29 1997
Subject: Re: Correctly using lsof
No it's not useless.
See the column marked inode name? - well that will give you the
filename.
In your first example try this
find /usr -inum 1352414 -exec ls -ldi {} \;
You should be able to determine the file in the /usr filesystem which
corresponds to that inode number.
As to why it doesn't respond the same on an alpha as SGI I dunno.
Cheers
Keith McCabe
Banque Paribas
========================================================================
>From abe_at_vic.cc.purdue.edu Tue Jan 14 03:31:07 1997
Subject: Re: Correctly using lsof
Brian,
I came across your posting via DejaNews -- I don't read
muc.lists.osf-Managers. (I've abbreviated your posting slightly to
conserve space.)
>Subject: Correctly using lsof
>From: "Brian James O'Connor" <boc_at_ironbark.bendigo.latrobe.edu.au>
>Date: 1997/01/10
>...
>
> I have lsof installed on a couple of DEC's running DU 3.2b,
>and a heap of sgi's. On the DU machines it does not produce the
>names of files, just the device names. This is useless.
I hope you were indulging in hyperbole here. Lsof isn't useless
without paths. No UNIX tool that I know -- fuser or ofiles, for
examples -- had any device/inode path reduction until lsof's revision
3.19 began trying to capitalize on the information stored in the
kernel's name cache. Doing that is a very tricky business that
makes some vendor reps wince.
Without a path name, however, the device and inode number *does*
most accurately identify a file and can be used in a brute force
method -- e.g., with find's -inum option -- to derive a path name.
Deriving a path name is a costly operation, and one not casually
applied. Please read the description of what lsof does for path
name lookup in the 00FAQ file. I believe few people would be
prepared to pay the cost associated with an lsof that would do a
path name lookup by traversing the entire file name tree, starting
at its root. I'm not sure I'm prepared to attempt to code such an
operation for 25+ different UNIX dialects, even as an option.
>...
>
>on DU(edited)
>DEC>lsof -u boc
>lsof: WARNING: name cache truncated at 10240 entries
This is an interesting error message. It can sometimes indicate
a problem with what lsof read from kernel space, and it can also
indicate a very large kernel name cache. Lsof tries to be conservative
in its approach to how much name cache information it will accept
from the kernel, and stops at what should be a reasonably large
limit.
The Digital UNIX (nee DEC OSF/1) kernel name cache is a linked
list. If the cache changes while lsof is following the links, lsof
can be tricked into following an infinite link loop. Hence lsof
has a safety valve that allows it to bail out after the name cache
has grown to a "ridiculous" size, usually 16 times what the kernel
says it has in its name cache.
>lsof on a file works, eg
>
>on DU
>DEC>lsof /usr/staff/boc/.elm/aliases
>COMMAND PID USER FD TYPE DEVICE SIZE/OFF INODE NAME
>elm 23216 boc 6r VREG 11, 6 336 1652125 /usr/st
>aff/boc/.elm/aliases
Yes, this will always work, but for the same reason that a
`find ... -inum` using lsof output will also work. Lsof finds the
named file by converting it to device/inode and searching for that
doublet. The device/inode pair *is* the file's unique identity as
far as the UNIX kernel is concerned.
>so the information must be there, but I must have either incorrectly compiled i
>t on the DU machine
>or need another switch.(I suspect that the "lsof: WARNING: name cache truncated
> at 10240 entries"
>warning has something to do with this)
While the warning about a very large cache has some bearing on your
problem, the sad truth of the matter is that lsof is never going
to be able to identify the full path of all open files using the
kernel's name cache information, and sometimes the information
really isn't there. Lsof will be able to shed some light on paths,
but it all depends on how dynamically the system is being used and
what's in the kernel name cache.
>Can any one give me a hint. lsof is a very usefull tool but I need it to "list
>open files"
>not devices.
UNIX files are device/inode pairs, not path names, as far as lsof
and the kernel are concerned. If you really need path names and
can pay the price, you might consider using lsof output to do
`find .. -inum` operations. You can automate that in an AWK or Perl
script, getting data from lsof in a form more easily processed by
such scripts and feeding it to find.
Next time you have a question about lsof, please feel free to
follow the comments in the "Bug Reports" section of the lsof
distribution's 00README file, and contact me directly.
Vic Abell <abe_at_purdue.edu>
===========================================================================
#!/bin/ksh
Translate()
{
# set -x
while read line
do
if echo "$line" | grep -q '([A-Za-z0-9_+-]*.#[A-Za-z0-9_+-]*.)$'
then
inode=`echo "$line" | awk '{print $(NF-2)}'`
mpoint=`echo "$line" | awk '{print $(NF-1)}'`
fset=`echo "$line" | awk '{print $NF}'`
name=`/usr/field/tag2name $mpoint/.tags/$inode 2>/dev/null`
if test ! -z "$name"
then
beg="`echo "$line" | awk -F / '{print $1}'`"
echo "${beg}${name}" $fset
else
beg="`echo "$line" | awk -F / '{print $1}'`"
echo "${beg}$mpoint/.tags/$inode" $fset
fi
elif echo "$line" | grep -q '(/dev/.*)$'
then
inode=`echo "$line" | awk '{print $(NF-2)}'`
if test "$inode" -eq "2"
then
echo "$line"
else
mpoint=`echo "$line" | awk '{print $(NF-1)}'`
fset=`echo "$line" | awk '{print $NF}'`
sfset=`echo "$fset" | sed 's/(//' | sed 's/)//' | sed 's;/dev/;/dev/r;'`
name=`/usr/sbin/ncheck -i $inode $sfset 2>/dev/null | grep '^'$inode | awk '{print $2}'`
if test ! "$mpoint" = "/"
then
name=`echo "${mpoint}$name"`
fi
if test ! -z "$name"
then
beg="`echo "$line" | awk -F / '{print $1}'`"
echo "${beg}${name}" $fset
else
echo "$line"
fi
fi
else
echo "$line"
fi
done
}
/usr/local/bin/lsof $* | Translate
Thanks to all who replied.
boc
--
------------------------------------------------------------
Brian O'Connor, Unix Systems Consultant
Latrobe University,Bendigo
boc_at_ironbark.bendigo.latrobe.edu.au
------------------------------------------------------------
Received on Tue Jan 21 1997 - 02:17:10 NZDT