Bug 106936

Summary: Unable to umount cdroms
Product: [Fedora] Fedora Reporter: louisgtwo
Component: famAssignee: Alexander Larsson <alexl>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: 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 Flags
Prevent the recent files menu from monitoring its files none

Description louisgtwo 2003-10-13 20:15:57 UTC
Nautilus can't eject cdroms. An error appears stating the cdrom is busy. I think
fam is monitoring the drive and should only be in read only mode.

Comment 1 Marius Andreiana 2003-10-20 18:41:42 UTC
It applies to floppies too.

This bug was present in RHL9 beta too. How can these be stopped from recurring?

Comment 2 Jeremy Katz 2003-10-21 19:43:36 UTC
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)?

Comment 3 Marius Andreiana 2003-10-21 19:51:33 UTC
No. lsof|grep floppy shows only fam using it.

Comment 4 louisgtwo 2003-10-21 20:16:55 UTC
This seems to be fixed in FC3, at least with cdroms. I don't use floppys that much.

Comment 5 rudi 2003-10-22 02:20:06 UTC
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).

Comment 6 Alexander Larsson 2003-10-22 10:03:56 UTC
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.


Comment 7 Alexander Larsson 2003-10-22 10:20:26 UTC
*** Bug 107174 has been marked as a duplicate of this bug. ***

Comment 8 Don Vanco 2003-10-23 19:03:05 UTC
Is this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107844
..possibly a duplicate?? (I get nothing relating to fam from fuser)
Don

Comment 9 bednar 2003-10-24 09:30:23 UTC
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 :) ).

Comment 10 Bill Nottingham 2003-10-27 03:01:28 UTC
*** Bug 108030 has been marked as a duplicate of this bug. ***

Comment 11 Elton Woo 2003-11-18 19:04:39 UTC
This bug is still persistent in Fedora Core Release 1 (Yarrow).

Comment 12 Carlos Rodrigues 2003-12-19 00:24:31 UTC
I see this too.

Comment 13 Carlos Rodrigues 2003-12-19 00:26:31 UTC
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.

Comment 14 bednar 2003-12-19 08:45:27 UTC
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?


Comment 15 Carlos Rodrigues 2003-12-19 14:12:57 UTC
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.

Comment 16 Miloslav Trmac 2003-12-19 14:41:12 UTC
Even if it were working, it is not enough.
USB memory sticks should not be monitored either.

Comment 17 Carlos Rodrigues 2003-12-19 15:23:06 UTC
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...

Comment 18 Miloslav Trmac 2003-12-19 15:28:05 UTC
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.

Comment 19 Carlos Rodrigues 2003-12-19 16:20:30 UTC
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).

Comment 20 Carlos Rodrigues 2003-12-19 17:08:39 UTC
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?

Comment 21 Carlos Rodrigues 2003-12-19 19:19:47 UTC
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.

Comment 22 Carlos Rodrigues 2003-12-19 21:31:52 UTC
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).

Comment 23 Aleksey Nogin 2004-01-19 05:39:15 UTC
*** Bug 112545 has been marked as a duplicate of this bug. ***

Comment 24 Alexander Larsson 2004-02-04 10:59:12 UTC
*** Bug 114231 has been marked as a duplicate of this bug. ***

Comment 25 Alexander Larsson 2004-02-04 10:59:32 UTC
*** Bug 109984 has been marked as a duplicate of this bug. ***

Comment 26 Alexander Larsson 2004-02-04 11:17:48 UTC
*** Bug 109687 has been marked as a duplicate of this bug. ***

Comment 27 Alexander Larsson 2004-02-04 15:35:40 UTC
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.

Comment 28 Kyrre Ness Sjøbæk 2004-03-02 20:57:31 UTC
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?"

Comment 29 Kyrre Ness Sjøbæk 2004-03-10 20:05:37 UTC
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?

Comment 30 Alexander Larsson 2004-03-11 09:24:22 UTC
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.

Comment 31 Miloslav Trmac 2004-03-24 15:06:19 UTC
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.

Comment 32 Dmitri Chubarov 2006-02-06 09:52:43 UTC
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.