Bug 61794 - cannot umount after using nfs mount to loop mount
cannot umount after using nfs mount to loop mount
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
Blocks: 61901
  Show dependency treegraph
Reported: 2002-03-24 12:01 EST by Gene Czarcinski
Modified: 2007-04-18 12:41 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-09 06:09:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output from mount on the fresh-install system (253 bytes, text/plain)
2002-03-24 17:08 EST, Gene Czarcinski
no flags Details
output from mount on the 7.2->beta3 install system (253 bytes, text/plain)
2002-03-24 17:08 EST, Gene Czarcinski
no flags Details
fresh install install.log (24.10 KB, text/plain)
2002-03-27 14:33 EST, Gene Czarcinski
no flags Details
fresh install anaconda-ks.cfg (3.63 KB, text/plain)
2002-03-27 14:34 EST, Gene Czarcinski
no flags Details
fresh install strace umount (7.33 KB, text/plain)
2002-03-27 14:35 EST, Gene Czarcinski
no flags Details
upgrade install 7.2 install.log (12.65 KB, text/plain)
2002-03-27 14:36 EST, Gene Czarcinski
no flags Details
upgrade install beta3 upgrade.log (52.16 KB, text/plain)
2002-03-27 14:36 EST, Gene Czarcinski
no flags Details
upgrade install anaconda-ks.cfg (2.46 KB, text/plain)
2002-03-27 14:37 EST, Gene Czarcinski
no flags Details
upgrade install strace umount output (7.62 KB, text/plain)
2002-03-27 14:37 EST, Gene Czarcinski
no flags Details

  None (edit)
Description Gene Czarcinski 2002-03-24 12:01:25 EST
I am not sure what component to report this against.

The problem described below occured on a UPGRADE system (7.2 -> beta3).  I could
NOT get it to happen EVERY TIME on a similar FRESH install system (similar
components installed) -- but it has happened.

Description of Problem:
Having mounted a directory tree as a nfs export from a 7.2 system, I mounted an
iso image in the nfs mounted tree as a loopback mount.  I then did a rpm -qip
against a file on the loopback mount.  I then umounted the loopback and tried to
umount the nfs mount but got "umount: /mnt/images: device busy"

Version-Release number of selected component (if applicable):
7.2 upgraded to beta3

How Reproducible:
every time I tried

Steps to Reproduce:
1. upgrade install beta3
2. nfs mount (ro) a directory exported on a 7.2 system with iso images on it
3. loop mount (ro) an iso image
4. do rpm -qip on some package on the loop mounted tree
5. umount the loop mount
6. umount the nfs mount

Actual Results:
umount ... device busy

Expected Results:
nfs mount umounted.

Additional Information:
On the fresh install system, nautilus started for the loop mounted iso9660 tree
BUT on the upgraded system it DID NOT start.  I killed magicdev in case that was
the problem.

I am suspicious of nautilus.
Comment 1 Elliot Lee 2002-03-24 14:33:08 EST
There are three possible reasons I know of why a filesystem is considered to be
1. A process is using it (either current directory or an open file).
 '/sbin/fuser -muv /the/mount/point' run as root will tell you what that process is.

2. Another filesystem is mounted in a subdirectory of the filesystem

3. The filesystem is being exported by knfsd (not the case here).

Please let me know which the problem is.
Comment 2 Gene Czarcinski 2002-03-24 15:57:59 EST
1. The sequence of commands are the only ones executed before the last umount
was issued.

2. I tried logging off and then logging in as root but still cannot umount.


3. running /sbin/fuser -muv /mnt/images
produced no output.

4. df shows only /, /dev/shm, and /mnt/images (nfs mount)

5. /etc/exports is a null file.
Comment 3 Elliot Lee 2002-03-24 16:21:03 EST
Run 'mount' or 'cat /proc/mounts' to show all mounted filesystems, just in case.

But, I can't reproduce the problem here with a beta3-ish system. I need evidence
that the problem isn't just an oversight on your end.
Comment 4 Gene Czarcinski 2002-03-24 17:06:59 EST
I am going to put something out on the public beta mailing list to see if anyone
else sees this problem.
Comment 5 Gene Czarcinski 2002-03-24 17:08:09 EST
Created attachment 50005 [details]
output from mount on the fresh-install system
Comment 6 Gene Czarcinski 2002-03-24 17:08:49 EST
Created attachment 50006 [details]
output from mount on the 7.2->beta3 install system
Comment 7 Gene Czarcinski 2002-03-25 04:29:05 EST
Sorry but this is a bug. See testers mailing list.
Comment 8 Gene Czarcinski 2002-03-25 04:37:43 EST
I was FINALLY able to get rid of the mount by going to single user mode --

telinit 1

Comment 9 Gene Czarcinski 2002-03-25 05:40:56 EST
I have been playing with this some more.  Sometimes it happens and then
sometimes it does not.

I get get the mount to go away by switching to telinit 1 or telinit 2.  During
the switch, the first message from nfs says that "umount2 failed because devise
busy" and is immediately followed by a message from "mount" that "/mnt/images
not mounted".

This is followed by a message that nfs (retry) OK.  But at the end of the
switch, there are three more nfs (retry) OK messages.

Any suggestions on determining what this is will be helpful.
Comment 10 Elliot Lee 2002-03-27 13:41:30 EST
If it is a bug, I need information on reproducing it on my system. So far that
hasn't been possible :(
Comment 11 Gene Czarcinski 2002-03-27 14:32:42 EST
OK, I can get this problem to occur on two separate systems -- one a fresh
install and the other a 7.2->beta3 upgrade.  I will attach the install and
upgrade logs for the two installs, the anaconda-ks.cfg files from the two
systems, and strace output from the failing umount for each system.

I was hoping you could have me do something to help isolate the problem.  I
expect it is something strange since I assume that redhat uses nfs a lot.

Please note that it is only after I access some file on the loop mounted
filesystem (pointing to an iso file on the nfs mounted filesystem) that the
problem occurs.
Comment 12 Gene Czarcinski 2002-03-27 14:33:52 EST
Created attachment 50964 [details]
fresh install install.log
Comment 13 Gene Czarcinski 2002-03-27 14:34:26 EST
Created attachment 50965 [details]
fresh install anaconda-ks.cfg
Comment 14 Gene Czarcinski 2002-03-27 14:35:14 EST
Created attachment 50966 [details]
fresh install strace umount
Comment 15 Gene Czarcinski 2002-03-27 14:36:10 EST
Created attachment 50967 [details]
upgrade install 7.2 install.log
Comment 16 Gene Czarcinski 2002-03-27 14:36:47 EST
Created attachment 50968 [details]
upgrade install beta3 upgrade.log
Comment 17 Gene Czarcinski 2002-03-27 14:37:12 EST
Created attachment 50969 [details]
upgrade install anaconda-ks.cfg
Comment 18 Gene Czarcinski 2002-03-27 14:37:41 EST
Created attachment 50970 [details]
upgrade install strace umount output
Comment 19 Elliot Lee 2002-03-27 14:45:44 EST
It's clear that the umount is failing because _something_ is still using the
filesystem, because there's no reason yet to assume that the kernel is lying :)

I think it just requires sufficient poking with fuser, etc. If going to runlevel
1 solves the problem, and you can't get fuser to produce useful information, try
stopping services/processes one by one until the umount succeeds, etc. etc.
Comment 20 Gene Czarcinski 2002-03-27 15:29:40 EST
OK, switching to run level 1 (telinit 1) does free up the device according to
"df".  However, /proc/mounts still shows the mount.  In fact, it shows a whole
bunch of them (I did a bunch of runlevel switching).

Executing /etc/init.d/netfs stop fails but the runlevel switch says it fails the
first time but the succeeds.  However, it keeps doing retrys since there are
still entries in /proc/mounts.

I have tried stopping everything in sight with no effect.  In all cases, fuser
-vamu /mnt/images shows NOTHING.
Comment 21 Jay Turner 2002-03-27 16:10:15 EST
OK, the good news is that we are able to replicate this now.  The bad news is
that it is a kernel bug.  More good news, there's a workaround in the mean time.

Just to clarify, here are the steps to reproduce:
1) mount an NFS export
2) on your local machine, navigate to an ISO image in that NFS export
3) loopback mount this ISO (so you have loopback mounted a NFS-exported file)
4) touch a file in the loopback mount with rpm or one of its derivatives
5) unmount the loopback mount
6) attempt to unmount the NFS export

You will get a message that the device or resource is busy, but fuser shows
nothing for that filesystem.

The workaround is to just remount the loopback mount, then immediately unmount
it.  You will then be able to unmount the NFS export.
Comment 22 Elliot Lee 2002-03-27 16:13:31 EST
jkt reproduced it, the trick seems to be to use rpm to access some files
inside the loopback-mounted ISO.

Clearly a kernel bug, SEP.
Comment 23 Gene Czarcinski 2002-04-08 13:33:54 EDT
Confirmed it is still present in beta4
Comment 24 Gene Czarcinski 2002-04-08 16:16:32 EDT
Something odd happened.  Running under kde, I did the nfs mount, loop mount iso
image thing and everything accessed fine.  I then umounted the loop mount and
remounted it but this time the kde equivalent of nautilus did not come up.  I
could umount the loop mount but the nfs mount was "busy".

I then logged off and logged in as root under gnome.  I remounted the loop mount
and nautilus came up (closed it) and umounted the loop mount. I could then
umount the nfs mount.
Comment 25 Arjan van de Ven 2002-04-09 06:09:37 EDT
question: does
rpm -e autorun

help for the kde case ?
Comment 26 Arjan van de Ven 2002-04-14 08:40:34 EDT
Ok culprit found, identified and exterminated.
Should appear in rawhide as 2.4.18-0.25

Note You need to log in before you can comment on or make changes to this bug.