You might also try lsof.  It will give more information about AFS
files than will fuser.  Neither application needs root permission.
Neither needs /vmunix.

Lsof uses the kvm_*() library, so it requires permission to read
/dev/kmem -- e.g., be setgid(sys).  Lsof doesn't get kernel symbol
information from /vmunix, but from /dev/ksyms.

Fuser relies on the /dev/kstat interface and the undocumented
utssys() system call, so it doesn't need either /dev/kmem or /vmunix.

The f_user structure, returned by utssys(), limits the information
fuser can provide to process ID, user ID, and file usage.  Lsof
reads the kernel file structure, follows it to the vnode, and
follows the vnode to the file-system-specific node structure for
the file.  Thus it can provide more information than fuser.

Lsof comes with full source code:

    ftp://vic.cc.purdue.edu/pub/tools/unix/lsof

Vic Abell

In message <[EMAIL PROTECTED]>you wr
ite:
>
>  SunOS has the "fuser" command, which lists processes using a file or
>file structure.
>
>  fuser /afs 
>
>  should reveal what might be going on here.
>
>  You'll need to run this as root, as you have to open /vmunix.
>
>  -b.
>
>On Wed, 11 Sep 1996, Joseph L Jackson wrote:
>
>> There's a helpful clue hidden in the last message. The number inside the
>> parens is actually the "errno" value set by the failing "mount()" call.
>> On a Solaris machine, 16 translates to "device busy":
>> 
>> [~] translate_et 16
>> 16 ().16 = Device busy
>> [~] grep 16 /usr/include/sys/errno.h
>> #define EBUSY   16      /* Mount device busy                    */
>> 
>> The errno values don't always match across different OSs, so you'll want
>> to check on your SunOS 4.1.4 machine to be sure of the meaning.
>> 
>> You get a "device busy" error when the /afs directory is in use already.
>> Use the "mount" command to see if someone has already started AFS. Or
>> perhaps someone NFS mounted /afs while you weren't looking. Also be sure
>> that no one has their current working directory set to /afs when you
>> start it up. That's all I can think of off the top of my head.
>
>--
>       Brian W. Spolarich - ANS - [EMAIL PROTECTED] - (313)677-7311
>                Look both ways before crossing the Net.

Reply via email to