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:
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.
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
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.
*** Bug 111762 has been marked as a duplicate of this bug. ***
duplicate of bug 109962
maybe not the initial report
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
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.
One more thing: As you can see from the above, neither my system, nor the installed kernel is SMP.
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
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
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.
I'm pretty sure this bug is fixed in the 2179 kernel.
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.
No occuring anymore for me, closing down.
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()