Xref: utzoo comp.unix.admin:1600 comp.unix.questions:30418 comp.unix.wizards:24910
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!batcomputer!cornell!uw-beaver!mit-eddie!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.unix.admin,comp.unix.questions,comp.unix.wizards
Subject: Re: How can you tell who has what files open?
Message-ID: <689@minya.UUCP>
Date: 13 Apr 91 16:52:32 GMT
References: <1991Apr04.201719.3587@ka3ovk> <19168@rpp386.cactus.org>
Followup-To: s
Lines: 35

In article <19168@rpp386.cactus.org>, jfh@rpp386.cactus.org (John F Haugh II) writes:
> In article <1991Apr04.201719.3587@ka3ovk> albers@ka3ovk.irs.gov.UUCP (Jon Albers) writes:
> >Is there a way to find out the process id of a process that has a file open?
> >Is there a way to list open files by process id, name, and/or inode?  I
> >want to be able to find out where the error starts.
> 
> Two commands will tell you has a file open - "fuser" and "ofiles".  "fuser"
> is standard with System V.  "ofiles" I believe is mostly a SunOS command,
> I'm sure someone from that universe can fill you in.
 
If your Sys/V is like this one, you may have to do  some  tweaking  to  get
fuser  to  a usable state.  When I typed it into a non-super-user window, I
got a "not found" message. Hunting about turned it up quickly, in /etc, but
when I typed /etc/fuser, the response was:
	/etc/fuser: /dev/kmem: Permission denied
Investigating further showed:
	-r-xr-xr-x   1 bin      bin        13404 Sep 20  1989 /etc/fuser
As a result, fuser as installed is only usable by a super-user; it  totally
fails  for  all  other  users.   I linked it into bin and modified it to be
setgid-kmem, and now it works.  Unfortunately, it still isn't exactly  what
I'd  call  a  user-friendly  program.   It  produces a process id.  This is
understandable, but for most users, this implies typing ps -ef and grepping
for the output of fuser. So I wrote a little script. At least I didn't have
to grovel through fuser's output with sed or awk  to  strip  away  assorted
junk;  they  were  programmer-friendly  if  not  user-friendly in having it
produce just the process id and nothing else.

Sometimes saying that a command is "standard with System V" is not quite all 
you need to know for a user to be able to make use of it.

-- 
All opinions Copyright (c) 1991 by John Chambers.  Inquire for licensing at:
Home: 1-617-484-6393 
Work: 1-508-486-5475
Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc