Bug 112861 - umount of loopback mounted ISO images hangs
umount of loopback mounted ISO images hangs
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
: 111762 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-04 11:18 EST by Florian La Roche
Modified: 2007-11-30 17:10 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-11 03:50:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Florian La Roche 2004-01-04 11:18:07 EST
Description of problem:
I have a server with many ISO images mounted loopback. It happened
twice today that first a reboot got stuck at "umounting loopback"
devices, the other time a manual "umount -t iso9660 -a" freezed the
kernel (nothing in the log files, ping still worked, no network
and also the local keyboard did not work, no output).

Trying a umount directly after a reboot worked fine, so this is
not 100% reproducable.

kernel 2.4.22-1.2135


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Kevin Street 2004-01-06 13:34:09 EST
I am also seeing intermittent hangs in umount, some on normal
filesystems.  I've only seen this during shutdown so far.  Some have
been in /etc/init.d/autofs and some in /etc/init.d/halt.  I've added
-v to all the umounts to see if it says anything more & I'll try some
additional shutdowns.
Comment 2 Kevin Street 2004-01-07 19:19:31 EST
I've just had it hang again in halt.  It was doing:
umount -v -f /var /usr /tmp /s1 /home /boot
/dev/lvg0/lvvar unmounted
/dev/lvg0/lvusr unmounted

so I assume it hung on umounting /tmp

kernel 2.4.22-1.2140.nptlsmp
Comment 3 Gene Czarcinski 2004-01-10 15:36:02 EST
I am also seeing umount hangs ... for nfs mounts, real ide disk
mounts, and iso loop mounts.  I have now seen it on a dual Athlon and
a dual P-III system.  Both systems have some but not a great deal of
mounts.

I have also seen it trying to umount a floppy.

When it hangs (freezes), nothing moves.  Nothing in logs either.

I am going to close my previous report 111762 as a dup of this since
others are documented here.
Comment 4 Gene Czarcinski 2004-01-10 15:36:52 EST
*** Bug 111762 has been marked as a duplicate of this bug. ***
Comment 5 Ronny Buchmann 2004-01-17 16:29:42 EST
duplicate of bug 109962
Comment 6 Ronny Buchmann 2004-01-17 16:30:42 EST
maybe not the initial report
Comment 7 Scott R. Godin 2004-02-02 05:43:20 EST
I too just noticed this when mounting some old partitions on a spare
2g drive I still have lurking deep in the box somewhere. :)

I decided to make use of the drive, and was peeking thru it to see if
I had left anything behind I might want, and discovered that when
umounting them, umount hangs. (they are stock IDE drives, nothing
special, no weird hdparm settings (I've never used hdparm on them)) 

Fortunately I was using aterm for these, and quitting the term window
and checking with top shows a very busy umount (consuming about half
the cpu).. possibly updating access times? no clue. Could be fam but I
haven't checked it. It was *very* disconcerting, since I've not yet
had any problems mounting/unmounting cd-rom disks. (though normally I
use rox-filer to mount/unmount CD's rather than the CLI) 

Eventually it does finish doing whatever it was doing.. 

However even after what appeared to be a successfully completed
umount, when I went to fdisk the partition and write a new table, it
barked that : 
==
Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device
or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.
==

so obviously something was still confused. 

df -h showed what appeared to be BOTH /dev/hdb1 and /dev/hdb2 mounted
to the same mountpoint. even though both umounts had succeeded and
were no longer listed in ps. I tried re-running the umounts, and after
a bit, those disappeared too, although umount complained that they
were NOT mounted.

5:31am {25} pcp01723902pcs:/root># umount /dev/hdb1
umount: /dev/hdb1: not mounted
5:32am {26} pcp01723902pcs:/root># umount /dev/hdb2
umount: /dev/hdb2: not mounted

this really needs to be addressed, and I have NO idea how you guys
managed to break this thing >:) 

I think the severity should be raised on this. (by the way I'm on a
Duron 1.1ghz system: 

$>uname -a 
Linux pcp01723902pcs.univde01.de.comcast.net 2.4.22-1.2149.nptl #1 Wed
Jan 7 12:57:33 EST 2004 i686 athlon i386 GNU/Linux
Comment 8 István Tóth 2004-02-27 07:38:39 EST
I am seeing umount hang when mkinitrd makes a new initrd image.

[root@elemer stoty]# uname -a
Linux elemer 2.4.22-1.2174.nptl #1 Wed Feb 18 16:38:32 EST 2004 i686
i686 i386 GNU/Linux

The end of output from make install

warning: kernel is too big for standalone boot from floppy
sh -x ./install.sh 2.4.25 bzImage /usr/src/linux-2.4.25/System.map ""
+ '[' -x /root/bin/installkernel ']'
+ '[' -x /sbin/installkernel ']'
+ exec /sbin/installkernel 2.4.25 bzImage
/usr/src/linux-2.4.25/System.map ''
<hangs here>

Top shows:
  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
10135 root      25   0   436  436   376 R    99.5  0.0   6:56   0 umount
 3450 root      15   0  107M  31M  8128 S     2.9  6.3   2:28   0 X
10251 root      16   0  1116 1116   892 R     0.9  0.2   0:00   0 top

I've seen this behaviour with all fedora kernels, perhaps even with RH9.
Comment 9 István Tóth 2004-02-27 07:40:22 EST
One more thing: As you can see from the above, neither my system, nor
the installed kernel is SMP.
Comment 10 István Tóth 2004-02-27 07:52:10 EST
After leaving the hung process to run for about 10 minutes, it
accepted ctrl-c, and exited. When I tried to run make install again,
it hung again, but this time I could ctrl-c it after about 1 minute.
If I reboot machine, the command usually completes without problem
Comment 11 Andrew Schultz 2004-04-02 10:05:58 EST
while umount is frozen, you can actually do umount again, and it will
work...

% df | grep loop
/dev/loop0            31688340   6918400  23160228  24%
/tmp/initrd.mnt.qiC732
% umount /dev/loop0
umount: /dev/loop0: not mounted
% df | grep loop
%

after doing this, umount will (eventually) exit
Comment 12 Stephen Darlington 2004-04-17 14:01:39 EDT
I'm seeing the same as Istvan but not the same as Andrew. The loopback does not appear 
in the mount list yet umount has been running for some time (see last line):

 2224 ?        SN     0:00 /bin/bash /usr/bin/run-parts /etc/cron.daily
 2504 ?        SN     0:00 /bin/sh /etc/cron.daily/yum.cron
 2505 ?        SN     0:00 awk -v progname=/etc/cron.daily/yum.cron progname {??
 2507 ?        SN     2:30 /usr/bin/python /usr/bin/yum -R 120 -e 0 -d 0 -y upda
 2525 ?        SN     0:00 /bin/sh /var/tmp/rpm-tmp.89983 3
 2541 ?        SN     0:00 /bin/bash /sbin/new-kernel-pkg --mkinitrd --depmod --
 2545 ?        SN     0:00 /bin/bash /sbin/mkinitrd -f /boot/initrd-2.4.22-1.217
 2640 ?        SWN    0:00 [loop0]
 2692 ?        RN   336:27 umount /tmp/initrd.mnt.mf263

Killing 2692 has no effect.

Also note this situation arose when yum automatically downloaded a kernel update. 
Running pretty much standard Core 1 on a VIA C3/mini-itx machine.
Comment 13 Dave Jones 2004-04-17 16:51:25 EDT
I'm pretty sure this bug is fixed in the 2179 kernel.
Comment 14 Gene Czarcinski 2004-04-17 17:02:48 EDT
I had it occurring for me pretty regularly but also unpredictably.  I
am running the 2179 kernel now so it is somewhat of a wait and see.

You might want to close it and then, if it is still occurring, it can
be reopened.  If I had opened the origiinaly report, I could close it now.

The platform specified is i686 but for me it was occurring on dual
athlon system.
Comment 15 Florian La Roche 2004-06-11 03:50:26 EDT
No occuring anymore for me, closing down.
Comment 16 Pádraig Brady 2004-12-02 13:48:03 EST
The following seems to suggest that it was the
removal of the low latency patch that fixed this issue?
http://www.redhat.com/archives/fedora-devel-list/2004-April/msg01142.html

For the record I noticed the problem intermittently on SMP and UP,
on FC1 base (kernel-2.4.22-1.2115.nptl, util-linux-2.11y-29).

On UP (my laptop) the umount process would spin sometimes between
10s and 10mins, but would eventually finish. However on SMP
(Dell 1750) when umount started to spin it would have a much more
adverse affect on system responsiveness, and would never finish.

Attaching using strace gave no output which confused me
(making me think that umount wasn't in a syscall?).
Kill -9 never worked either. Also I could not attach with gdb.

I always noticed it with loop devices (ext2) but this was
by far the most frequent [u]mounting I was doing.

Using strace I was able to determine that after umount came
out of its 100% CPU usage state it did:
open("/dev/loop0")=3
ioctl(3,0x4C01)
....updating of /etc/mtab
exit()

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