[comp.unix.questions] How can I find out who is on a filesystem when I can't umount it?

fredrick@acd.acd.ucar.edu (Tim Fredrick) (03/01/91)

We have a CDROM on our Sun SPARCstation where I constantly have the problem
where umount yields:

  umount /cdrom
  /cdrom: Device busy

How can I find out what process is using that filesystem, and is there a
way to force the umount to happen anyway?  So far I've had to reboot the
system each time.  --Tim

jik@athena.mit.edu (Jonathan I. Kamens) (03/01/91)

  First of all, about finding out what processes are using a filesystem -- the
best utility I've seen for doing that is "ofiles".  You can find out where to
get the source to "ofiles" by telnet'ing to quiche.cs.mcgill.ca (132.206.2.3
or 132.206.51.1) and logging in as "archie".  Type "help" once you get a
prompt to find out how to use archie.  If you don't want to do that, you can
just get the version of ofiles (you probably want "ofiles.new") available in
the comp.sources.unix archives.

  Second, no, you can't force the unmount of a filesystem while it's busy, at
least not on the systems with which I'm familiar (mostly 4.3BSD).  There is
great potential for lossage if you allow that.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710

tchrist@convex.COM (Tom Christiansen) (03/01/91)

From the keyboard of fredrick@acd.acd.ucar.edu (Tim Fredrick):
:We have a CDROM on our Sun SPARCstation where I constantly have the problem
:where umount yields:
:
:  umount /cdrom
:  /cdrom: Device busy
:
:How can I find out what process is using that filesystem, and is there a
:way to force the umount to happen anyway?  So far I've had to reboot the
:system each time.  --Tim

You can use fuser(missed'em five), ofiles(public domain), or fstat(l^Hbsd).
Of these, the last seems the nicest to use, as it does these things:

    given a partition, find out what's open there
    given a proc, find what files (including pipes etc) it has open
    given a file, find what procs has it open
    give a user, find out what file he has open
    trace down netstat -aA output to a given process
    plus more

You can get fstat from the bsd sources on uunet, but that won't work 
for suns.  I got my sun version from Vic Abell, abe@mace.cc.purdue.edu,
that he posted to comp.sources.something a couple years ago.

This should really go in the FAQ.

--tom
--
"UNIX was not designed to stop you from doing stupid things, because
 that would also stop you from doing clever things." -- Doug Gwyn

 Tom Christiansen                tchrist@convex.com      convex!tchrist

willcr@bud.sos.ivy.isc.com (Will Crowder) (03/08/91)

In article <1991Feb28.205352.26287@athena.mit.edu>, jik@athena.mit.edu
(Jonathan I. Kamens) writes:

|> First of all, about finding out what processes are using a filesystem -- the
|> best utility I've seen for doing that is "ofiles".  You can find out where to
|> get the source to "ofiles" by telnet'ing to quiche.cs.mcgill.ca (132.206.2.3
|> or 132.206.51.1) and logging in as "archie".  Type "help" once you get a
|> prompt to find out how to use archie.  If you don't want to do that, you can
|> just get the version of ofiles (you probably want "ofiles.new") available in
|> the comp.sources.unix archives.

The ofiles.new in the last comp.sources.unix archive I saw won't run under
SunOS 4.1.x.  This is due to the change in the user area u_ofile pointer.
Under SunOS 4.1.x, u_ofile is a pointer to either u_ofile_arr, which is
an array in the user area, or some piece of kernel-allocated memory.  This 
is to allow the number of open file descriptors to exceed the available
space for file descriptors in the u area.  (That value is #defined as
NOFILE_IN_U and under 4.1.1 is 64.)

The problem is that the kvm_getu() call used in ofiles doesn't adjust the
u_ofile pointer to point to the copy of the u_ofile_arr.  u_ofile still
points somewhere in kernel memory, and causes a SEGV when ofiles tries to
access it.  The fix is to determine if the pointer pointed somewhere in the
u area and if so, just adjust it to point to the local copy, or do a 
kvm_read() (or whatever) to read the real array into user space and then
point u_ofile at it.

|> Jonathan Kamens			              USnail:
|> MIT Project Athena				11 Ashford Terrace
|> jik@Athena.MIT.EDU				Allston, MA  02134
|> Office: 617-253-8085			      Home: 617-782-0710

Will
----
Will Crowder, INTERACTIVE Systems Corporation
willcr@ivy.isc.com

guy@auspex.auspex.com (Guy Harris) (03/19/91)

>The ofiles.new in the last comp.sources.unix archive I saw won't run under
>SunOS 4.1.x.

But SunOS 4.1[.x] comes with the S5 "fuser" commmand, which does much of
the same sort of thing.  You may have to install some particular
software category to get it (e.g., the S5 category).