Subject: Re: umount
bryan@ak.net
Date: Sat Nov 24 2001 - 14:16:25 AKST
JOHN MUELLER wrote in <cb6b2c8274.c8274cb6b2@sentinel.uaa.alaska.edu>:
>
> Seems that all this hype about "how dangerous it is to remove media
> before umounting" is pure hogwash !! Once I mount, nothing I do will
> make the device not busy. So I might as well just yank it out, because
> I try "umount -f" to try to force it, but even that doesn't work.
It's a valid warning. If you disconnect a filesystem without
flushing the buffers, your files can get corrupted. Obviously
with read-only media like cdroms, this isn't a concern.
I've had the same frustrating problem with not being able to
umount, so let me share what I've learned so far. A device is
busy if some part of it is "in use" by some process. But that
may not mean accessing files. For example, if your shell's
working directory is somewhere in or under /cdrom (for example),
you can't umount /cdrom -- what would your working directory
be then?
But this doesn't only apply to your shell. Any process that is
started has certain enviroment variables associated with it,
including the current working directory. This means that if you
are in /cdrom, and start netscape from there, even if you change
directories later, netscape will still be associated with /cdrom.
This setting can't be changed, and the /cdrom device will be busy
until netscape exits.
I unfortunately started my ppp connection from /cdrom/... the other
day, and I wasn't able to umount the cdrom until I killed ppp.
It certainly is an inconvenience. If anyone knows a better solution,
I'd love to hear it. Otherwise, just try to remember not to start
any long-term processes from a directory you plan to umount.
Whoops! I almost forgot this part: the fuser command will show
you which processes are using certain files. For example,
'fuser -mv /cdrom' should show you which processes (or the kernel)
are using anything in the /cdrom filesystem. You may need to be
root to see root-owned processes. Once you see the list, you'll
know what needs to be killed to umount the filesystem.
-- Bryan Medsker bryan@ak.net
This archive was generated by hypermail 2a23 : Sat Nov 24 2001 - 14:15:34 AKST