Bug 106936
Summary: | Unable to umount cdroms | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | louisgtwo | ||||
Component: | fam | Assignee: | Alexander Larsson <alexl> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | borkows, cefrodrigues, elwoo, igalmarino, marius.andreiana, mishu, mitr, monkiki5, rudi, sayao, twaugh, wendigo3 | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | 2.6.10-1 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2004-02-04 15:35:40 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: | 100643 | ||||||
Attachments: |
|
Description
louisgtwo
2003-10-13 20:15:57 UTC
It applies to floppies too. This bug was present in RHL9 beta too. How can these be stopped from recurring? This works for me... do you have a window open with the cd's mountpoint (or a shell with cwd under the cd's mount point)? No. lsof|grep floppy shows only fam using it. This seems to be fixed in FC3, at least with cdroms. I don't use floppys that much. I think I know how to reproduce this bug (or, at least, a very similar one). I have a single test file in a "mp3" directory on a Flash drive. Today I plugged the drive in a Windows box and, without telling me, it wrote two pictures in the same directory (one for the song, one for the album, I think). I checked the pictures using the command "eog /mnt/flash/mp3". After I quit eog, it wouldn't let me unmount the disk, because it was apparently busy. After some investigation, the "fuser" command pointed to the culprit: fam, which still had /mnt/flash/mp3 open. I am confident that, besides mounting, I had made no other accesses whatsoever to /mnt/flash or /mnt/flash/mp3. I just reproduced it once more: mount, use only eog to access the directory -> fam keeps it open. The only way out is to actually delete the directory (renaming it isn't enough). It looks as if eog doesn't withdraw its notification request AND fam doesn't notice that eog has quit leaving requests pending (I am not sure if it is supposed to notice that kind of things, but it'd likely be more robust if it were so). No, i think its an actual bug in fam where it somehow leaks the monitor, or at least the open fd on the dir. Fam should detect clients that disconnect and free the clients monitors. There are some other bugs in bugzilla related to this to i think. *** Bug 107174 has been marked as a duplicate of this bug. *** Is this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107844 ..possibly a duplicate?? (I get nothing relating to fam from fuser) Don This seems NOT TO BE FIXED in FC3. The fam server block unmounting of cdroms. I saw sam behavior in RHL 9. Severity CRITICAL for lame desktop users (like me :) ). *** Bug 108030 has been marked as a duplicate of this bug. *** This bug is still persistent in Fedora Core Release 1 (Yarrow). I see this too. Forgot... I see this too in Fedora Core 1. Sometimes I close the nautilus window that is showing the cdrom folder and I can't eject the cdrom until I "service xinetd restart" as root. Will somebody fix unmounting bug in the next releases of Fedora or even better in upodates of fam and others stuff? In addition I wonder why the Gnome use its own automounting utulity, KDE using own while there are three lower level tools like autofs, automount ant somethikg else (I don't remember the name of). I think it shoulb be OS not window manager case to mount and unmount devices. Actual way of doing it makes mess and problems. Is there a howto describing config of autofs and HOW TO DISABLE window manager automounting functionality in Gnome and KDE? In nautilus-monitor.c:135 one can read this: /* * Don't monitor URIs on a read-only volume. * This is a hack to avoid FAM keeping open fds to CD-ROMs, * causing unmount/eject to fail. */ This clearly isn't working. Besides this I'm thinking that this may be caused by nautilus not releasing a monitor before trying to unmount. This bug has annoyed me to the point of making me dig through nautilus source, not an easy task for someone not familiar with it. But this bug is biting me every other time. Even if it were working, it is not enough. USB memory sticks should not be monitored either. The thing is they are and should be monitored, in fact everything should be monitored. The only exceptions are stuff on a read-only volume, so this isn't really a hack, it's side effect is the hack. The problem is that there is a bug somewhere making nautilus sometimes think that a volume is read-write when it is not and another making nautilus keep monitors alive after the views that were showing them are closed. Provided that the two supposed bugs above are eliminated (or whatever is causing this anomalous behavior) the only this that remains is the impossibility to unmount volumes from anywhere but nautilus while a nautilus view is open on them but that shouldn't really be a problem as the users can easily perceive a nautilus view as the cause of the "busy" error. I just hope someone with a deep knowledge in nautilus/gnome-vfs fixes this fast... Oh, anyway. Nautilus does not seem to be the culprit, opening and closing a nautilus window still allows the volume to be unmounted. But after opening a file there (using ggv or gpdf, IIRC) the volume can't be unmounted. IIRC these problems were earlier caused by monitoring the recent file list in panel. Actually, I've had some occasions where I mounted the volume (the cdrom) navigated through it a bit and then I couldn't unmount it. Aditionally, lsof shows fam as having a handle to a directory (mostly /mnt/cdrom but sometimes some directory below /mnt/cdrom). I'm not saying here that nautilus is the culprit but I'm also not saying that it isn't as this is a transient and difficult to reproduce bug (it could be a race, or a corner case or something, I'm not going to elaborate on that as I don't know how nautilus works in sufficient detail). Your reference to the recent files list gave me an idea and I found a way to reproduce this deterministically (it is a rather long list of steps but not too tricky): 1. remove the ~/.recently_used file and logoff and login to clean the recently open files list 2. now mount a cd which has a tar.gz somewhere 3. navigate to that directory and double-click the file to open it with file-roller 4. the file is added to the "Open Recent..." list in the gnome menu 5. close everything (nautilus and file-roller) 6. unmount the cdrom (you can't, it is busy - if you can unmount it just keep reading) 7. open a terminal, "su" to root and "service xinetd restart" 8. unmount the cdrom (you can now and as fam was restarted the recent files list isn't updated to remove the file that has been opened on the cdrom) 9. logoff 10. just to prove a point login in the console and umount the cdrom to make sure you can and then mount it again 11. log back on 12. the cdrom is mounted so unmount it (you can't, it is busy) What can we conclude from steps 10. and 12? It is the recent files list that is grabbing the cdrom. I think that the recent files list is trying to be too smart here, only the list should be monitored not the items themselves, am I missing something? Created attachment 96641 [details]
Prevent the recent files menu from monitoring its files
One can read this in the gnome-panel package changelog:
"remove recent-monitor patch now upstream"
It doesn't look like it is so I reapplied the patch. It appears to work ok.
I've submitted a bug report in the GNOME bugzilla which is at http://bugzilla.gnome.org/show_bug.cgi?id=129684 and one reply says that this problem does not happen in nautilus >= 2.4.1 and fam >= 2.7.0 (hint, hint). *** Bug 112545 has been marked as a duplicate of this bug. *** *** Bug 114231 has been marked as a duplicate of this bug. *** *** Bug 109984 has been marked as a duplicate of this bug. *** *** Bug 109687 has been marked as a duplicate of this bug. *** This is a complicated issue. Fam is often blamed because some app has a monitor open on some directory, but killing that app makes fam release the monitor. Such a problem is really not the fault of fam. However, there *is* a bug in the dnotify code in fam that sometimes made it forget that it had a monitor on a directory, so you had to kill fam itself (as root) to fix it. This is really bad, but I finally sat down and tracked down the bug. The fix is in fam-2.6.10-1, which will be in rawhide shortly. No doubt there are still ways to get fam to lock unmounts, however thats not the fault of fam anymore, so i'm closing this bug. Just an idea - what if fam had an option (turned on by default), that made it look into fstab and ONLY open mountpoints who is'nt "noauto", such as cdroms, floppies, and USB stics (why aren't these in the fstab by default?). I know it is done on NFS volumes... Hate telling my users to "always copy your documents of your floppy etc. before opening them, and remember to copy them back afterwards. And remember to unmount". We are talking second-time-linux-users who has been so lucky to get an account on my scools LDAP/NFS server... Most of them don't event try to use floppies on linux, and some asks "can you surf the internet from Linux? Where is the big, blue, E icon to internet?" Hmmm... Downloaded the fam-2.6.10-3.i386 from some site (the rpm claims it was built by redhat), and tried to upgrade. When I insert an DVD (which for some reason don't get automounted?!?) , and I browse the webpage on it with Mozilla (could be mozilla's fault as well?), and when I then try to unmount it, it won't do it. The message is that the device is busy. Opening OpenOffice documents is no problem then (as far as I have tried) Here is some info: [root@kyrre root]# rpm -qi fam Name : fam Relocations: (not relocateable) Version : 2.6.10 Vendor: Red Hat, Inc. Release : 3 Build Date: ons 25-02-2004 22:56:39 CET Install Date: tir 09-03-2004 22:34:15 CET Build Host: porky. devel.redhat.com Group : Systemmiljø/Demoner Source RPM: fam-2.6.10-3. src.rpm Size : 189284 License: GPL/LGPL Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://oss.sgi.com/projects/fam/ Summary : FAM, en filendringsovervåker. Description : FAM, the File Alteration Monitor, provides a daemon and an API which applications can use for notification of changes in specific files or directories. [root@kyrre root]# lsof | grep cdrom fam 2481 kyrre 32r DIR 22,64 4096 264192 /mnt/cdrom [root@kyrre root]# Maybee the bug should be reopened? Are e.g. no nautilus windows open on the cdrom, or e.g. the recent files issue can be cause this sort of thing. If something tells fam to monitor the device it will, thats not a bug in fam itself. I have looked again. The real reason for this is that the gnome-panel in FC1 has an old copy of egg-recent that attempts to monitor all entries in the recent file list. gnome-panel in current CVS (so something like the upcoming 2.6 release) has this fixed. There was a similar problem with a vfat usb filesystem connected as a scsi device. The computer: FC3 workstation in use since June 2005, some updates applied, kernel version 2.6.9-1.667, currently up for 77 days. The symptoms: In Jan 2006 suddenly unmounting /media/usbdrive stopped working "almost always". Following the advice found here, used lsof which shows open files on the drive. Below the username and filenames that are irrelevant are replaced with <username> and <filename> respectively. The lsof output shows either an open DIR entry for /media/usbdrive/.Trash-<username> held by gam_server or, after a file was deleted using nautilus, an open REG entry held by nautilus: nautilus 16480 <username> 26r REG 8,17 24889 59021 /media/usbdrive/.Trash-<username>/<filename> (deleted) An update from gamin-0.0.15-1 to gamin-0.1.1-3 did not solve the problem. Killing the holding process, i.e. gam_server or nautilus respectively helps. Either gam_server or nautilus get themselves restarted immediatedly, but the device is not held any more. |