Determining process preventing umount of busy partition

[Mel]

On Wednesday 11 February 2009 22:34:11 Polytropon wrote:
> First of all, I checked both lsof's and fstat's output: NOTHING seems to
> have a file open in the /usr partition. Very strange. Of course, I've tried
> the copies of both tools in /root/bin so they don't cause any access on
> /usr theirselves.
>
> On Thu, 12 Feb 2009 00:08:58 -0700, Tim Judd <tajudd at gmail.com> wrote:
> > Most commonly for me is because my $PWD (or CWD) is in the filesystem i
> > intend to umount
>
> I've checked this: In SUM, $CWD was /, and root's $HOME is /root on
> the / partition. Users' home directories are on /home which is separated
> from /usr (and can be unmounted without problems). At no time, a $CWD
> was on /usr partition.
>
> > so as a habit now, i move myself to the root partition (when logged in
> > as root) via the following, and assuming I want to umount /usr
> >
> >
> > # umount /usr
> > umount: unmount of /usr failed: Device busy
> > # cd
> > # umount /usr
> >
> >
> > cd, with no arguments, move you to ~ (aka $HOME)
>
> Which would be /root in case of SUM.
>
>
>
> As I said, very strange...

Is this a one-time event or 100% reproducable?
A likely scenario is:
- You have squid running
- You have rc_shutdowntimeout at default (30 seconds)
- rc hits the watchdog while squid is being shutdown
- you unmount
- get busy
- call fstat at which point squid has been shutdown.

Replace squid with anything that takes 30+ seconds to shutdown. Allthough, 
they would probably already fail at umount /var. Squid with defaults is fully 
contained in /usr/local.

-- 
Mel

Problem with today's modular software: they start with the modules
    and never get to the software part.