[Gllug] Remounting readonly fails
Mike Brodbelt
mike at coruscant.demon.co.uk
Wed Apr 5 18:05:49 UTC 2006
On Wed, 2006-04-05 at 10:18 +0100, Tet wrote:
> On 4/4/06, Nix <nix at esperi.org.uk> wrote:
>
> > > Sure it isnt something silly like a shell having a directory on /usr
> > > as its 'curent working directory' (hwoever this SHOULD show up in 'fuser').
> >
> > That's most likely, yes.
>
> Nope, for two reasons:
>
> 1. The filesystem had been mounted readonly beforehand. It was
> remounted rw, a yum update was run, then the remount readonly failed.
> In that brief period of time, it's unlikely that any process on the
> system would have a cwd in /usr without me explicitly starting one
> that did. Furthermore, the chances of a process being in the state you
> described, such that it can hide from fuser are vanishingly small
> IMHO.
I had a disk refuse to unmount the other day, with no visible reason in
fuser. It's easy to replicate - boot Knoppix, mount your hard disk
under /mnt (or somewhere), chroot into /mnt, then mount the proc
filesystem within the chrooted environment, and finally exit the chroot
shell. Now try and unmount /mnt - it'll fail, and fuser shows nothing.
Obviosuly not fuser's fault, as it's the kernel which is preventing the
filesystem from unmounting, but it's an annoyance, as there seems to be
no way to tell why the fs won't unmount, if you didn't know the previous
events.
Mike
--
Gllug mailing list - Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
More information about the GLLUG
mailing list