How can you tell who has what files open?
John Chambers
jc at minya.UUCP
Sun Apr 14 02:52:32 AEST 1991
In article <19168 at rpp386.cactus.org>, jfh at rpp386.cactus.org (John F Haugh II) writes:
> In article <1991Apr04.201719.3587 at ka3ovk> albers at 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
More information about the Comp.unix.questions
mailing list