Bug 64426
| Summary: | umount gives erroneous device is busy, nautilus-1.0.6-15 | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Ted Kaczmarek <tedkaz> |
| Component: | fam | Assignee: | Daniel Veillard <veillard> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.2 | CC: | tao, us_linux_engineering |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-09-08 16:57:26 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 67218, 79579, 100644 | ||
With MHarris tip of using lsof, I found a .Trash file that was their. I removed it and was still unable to umount the parttion. Went to init 1 and was able to umount it. Mounted all the partitions again, and a different partiton that had a .trash is doing the same thing. I will delete that .trash go to init 1 and run the same test again. I am using nautilus-1.0.6-15, think this has nothing to do with the kernel :-). Strange, I reproduced the device busy on a different partiton. Again I found a .Trash with lsof. But this time after removing the directory I was able to umount the partiton. I will try the same test again. Mount all the partitions then try umounting them. If I create the .Trash on /dev/hbd9 which is mounted as /mnt/hdb9 and create the .Tash with Nautilus I then can't unmount it. I created a .Trash in /mnt/hdb3 and did an rm -r on the dir and am again not able to umount the partiton. Hope this will be useful to someone. Thanks, Ted Yes this looks like nautilus... However it would be interesting to find out why not everybody+dog sees this... Probably FAM. We also need to be sure right-clicking a removable media icon on the desktop and choosing unmount works. This could potentially be fixed in nautilus 2.0.5-4, which would mean this is a dup of bug 70667. Ted, can you try the fam and nautlius RPMS that shipped in 8.0 to see if that fixes the problem? Newer nautilus seems to have resolved this issue, when testing gnome2 from ximian this problem has never shown up with them. Nautilus 2.0.X and up. Also have 8.0 running and not seen it as well. Thanks, Ted Thanks for staying on top of this, would seem to make sense to close as upstream :-) Yes, seems to be fixed in latest (RHL 9 and upstream) This issue can be reproduced in RHEL3 gold by mounting a USB floppy, deleting a file from it using nautilus, emptying the trash, and then attempting to umount the usb floppy. At this point it is still saying that the device is busy. An `lsof /mnt/floppy` implicates fam as holding onto a /mnt/floppy/.Trash directory and if you kill the pid, you can then unmount the drive. Perhaps there is a USB edge case which was not resolved when this was closed or perhaps this is a separate bug? Reopening...please advise. This seems to have reappeared in FC2 as well, it is espescially touchy with samba mounts, killing fam does fix it. I've been reproducing this on RHEL3-U2 with a regular floppy disk. Once there is a .Trash-root directory on the floppy's fs it gets picked up automatically on mount by nautilus/gnome-vfs/fam for monitoring, and so can only be unmounted using nautilus, since /bin/mount doesn't know to cancel the monitor on /mnt/floppy/.Trash-root. This is especially aggravating if you mount it from the commandline and then cannot unmount from the commandline. It has something to do with the virtual trash URI in gnome-vfs/eel2 as used by nautilus. I'm having a hard time tracking down the source of the problem, but it's got something todo with the virtual trash folder and use of dnotify by fam for monitors. As a (probably annoying) note, the problem disappears for me if I rebuild fam without dnotify. dnotify kernel API requires to open() the file to monitor. This is a very bad kernel API side-effect. This can be worked around at the eel/gnome-vfs level by not using the FAM API, or could be fixed by using a better kernel API like inotify and the gamin library replacing fam. Getting the right kernel API is the ultimate fix, this is a work in progress at this point. Daniel gamin now obsolete fam in Rawhide and the upcoming Fedora Core 3. I believe that the current fixes at the gamin level and nautilus fixes bugs of this kind. Daniel Is this resolved in RHEL4? Please reclose issue if it is. This should be closed in RHEL4 for the same reason, you should double-check the RHEL4 betas and reopen this bug if for some reason it doesn't work. But this should work. Daniel I just replicated this on FC2. Is there a way this wouldn't be fixed in fc2 but still somehow be fixed in RHEL4? Perhaps we should re- open. FC2 does not have gamin. FC3 will, Rawhide does. That's normal. http://www.gnome.org/~veillard/gamin/ Daniel |
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.1 (X11; Linux i686; U;) Gecko/20020417 Description of problem: I installed an old 20 gig drive I had laying around. /dev/hdb1 * 1 10 80293+ 83 Linux /dev/hdb2 11 137 1020127+ 83 Linux /dev/hdb3 138 647 4096575 83 Linux /dev/hdb4 648 2434 14354077+ 5 Extended /dev/hdb5 648 902 2048256 83 Linux /dev/hdb6 903 953 409626 83 Linux /dev/hdb7 954 1001 385528+ 83 Linux /dev/hdb8 1002 1030 232911 82 Linux swap /dev/hdb9 1031 2434 11277598+ 83 Linux I mounted all the partitons that were mountable as /mnt/hdb1,2 etc. I am unable to unmount /dev/hdb9, all the other partitions unmounted no problem. fuser -u /mnt/hdb9 /mnt/hdb9: No process references; use -v for the complete list fuser -v /mnt/hdb9 USER PID ACCESS COMMAND /mnt/hdb9 root kernel mount /mnt/hdb9 The box also has an 18gig scsi, 89 gig ide and two ide cdroms. The cdroms are not presently mounted. /dev/sda7 1004024 324236 628784 35% / /dev/sda1 46636 15323 28905 35% /boot /dev/sda3 2016044 817884 1095748 43% /home none 257212 0 257212 0% /dev/shm /dev/sda8 774040 17628 717056 3% /tmp /dev/sda2 11551080 3113368 7850940 29% /usr /dev/sda5 1209572 358128 790000 32% /var /dev/hda1 4031656 118468 3708392 4% /mnt/hda1 /dev/hda2 3780056 450360 3137672 13% /mnt/hda2 /dev/hda3 70973608 37052028 30316244 55% /mnt/hda3 /dev/hdb9 11100384 9112516 1423992 87% /mnt/hdb9 Version-Release number of selected component (if applicable): How reproducible: Didn't try Additional info: I will try to reproduce, trying to figure out a workaround for know. More to follw.