Bug 142637
Summary: | gam_server prevents removal of CF card | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andrew D. Stadler <stadler> |
Component: | gamin | Assignee: | Daniel Veillard <veillard> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | ben, liste, orion, walovaton |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-03-01 22:07:13 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: |
Description
Andrew D. Stadler
2004-12-11 08:02:27 UTC
I'm having exactly the same problem on FC3 (up to date as of the time/date stamp on this post). I can't unmount a USB disk which has the title "NO_NAME" (an old Microsoft Windows 98SE system disk, judging by the contents). I can't unmount it from Nautilus, when I lsof I get: # lsof |grep -i NO_NAME gam_serve 16998 jbn 60r DIR 8,33 12288 1 /media/NO_NAME So it appears that gamin keeps the drive from being unmountable. Killing gamin confirms this: # kill 16998 # lsof |grep -i NO_NAME # And the drive is easily unmounted. Ironically, I had exactly the same problem with fam in previous versions of Fedora Core. I'm running FC3 on an Asus P2B-D with 2 500MHz Pentium III chips (Katmai core) and I'm using the on-board USB (USB1.1, I believe). I have the same problem. It happens not only with removable media but with hard disk partitions too. I usually have a CD-ROM, a USB pen drive and a Windows filesystem in my disk. This problem show up often specially when you browse those filesystems for a while in nautilus. gam_server will have to do that open if it uses dnotify kernel interface to watch the given directory: 1/ you need a client (nautilus) asking to watch that directory 2/ gam_server should not use dnotify for anything under /mnt/ or /media/ subtrees this was added in 0.0.9 So if the media are mounted at the wrong place or if nautilus failed to release the watch for the directory, the behaviour you are seeing is normal and cannot be avoided. The kernel does *not* tell the gamin server that an umount was requested. Triple check: - your media mounting points - the version of gamin used Daniel Mr. Veillard, it wasn't clear if your comment #3 was directed at the bug reporters or various module authors. However, from my perspective (original reporter) I can answer the two things you asked to triple-check: - your media mounting points I have not modified anything to do with these - it is using the default FC3 behavior of mounting the CF card at /media/idedisk and /media/idedisk1. - the version of gamin used gamin-0.0.17-1.FC3 When you say "the behavior you are seeing is normal" can you elaborate? Stuck/unmountable filesystems doesn't seem very normal. Please let me know if I need to submit a bug against some other component (e.g. nautilus). Okay, gamin should not use dnotify to monitor anything under /media so I don't understand why this happens. Can you test the 0.0.19 update available in the test update channel. Daniel OK, now testing with 0.0.19. I haven't gotten it to hang, as originally reported, but still definitely seeing some odd behavior. Here is a log of a session, as I try it: insert CF card with two partitions. Nothing shows up on desktop. cat /etc/mtab: both partitions are shown. umount /dev/hde1 umount /dev/hde2 mount /dev/hde1 mount /dev/hde2 both partitions mounted, but don't show on desktop manually eject the card cat /etc/mtab - both partitions still showing umount /dev/hde1 - "umount: /dev/hde1: not mounted" umount /dev/hde2 - no error So as you can see, the behavior of inserting/removing a CF card is still somewhat flaky. I will monitor it and update with any specific reproducible cases. I see exactly this behaviour after updating to 0.0.24 with a card reader and an SD-Card. The only way to unmount the partition is to kill gam_server - if I just pull out the SD-card, gam-server stops responding to insert/remove events on the card reader until restarted. /proc/bus/usb/devices info: T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=55aa ProdID=b004 Rev=10.00 S: Manufacturer= S: Product=USB MMC/SD S: SerialNumber=02F671D7F6 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms Make sure you read http://www.gnome.org/~veillard/gamin/config.html Make sure your device is mounted under /mnt/ or /media/ subtree. If it is not the case, nautilus/gnome-vfs is supposed to stop the FAM monitoring when umounting the device. If you eject the device while the monitoring is active you are in trouble yes. Daniel I'm using the completely default configuration, the SD-card is being mounted as
/media/THESISWORK. Creating a .gaminrc with "poll /media/*" makes no difference.
In fact, it only seems to happen on the second time I insert/unmount the card:
it works fine the first time, then fails the second time. I've tested that with
two cards, both read-write and read-only. I was using 0.0.20 previously, which
worked most of the time.
>If you eject the device while the
>monitoring is active you are in trouble yes.
Isn't that a bit of a design flaw? So if a user accidentaly pulls a card out,
they have to log in/log out in order to make auto-detection work again. Wouldn't
some sort of timeout be a better idea? I know the user's not meant to do that,
but it would be best to at least minimise the damage done, wouldn't it?
> Isn't that a bit of a design flaw?
yes, induced by the dnotify kernel API. The kernel API requires to
open() a file descriptor to the monitored directory. So You have an open
descriptor on the mounted device. Which also mean that if you eject without
unmounting first at the nautilus level, nautilus doesn't stop the monitoring,
the file descriptor stay open, so umounting also fails. A new kernel interface
based on the inotify is being tested for inclusion in kernel-2.6 . Until this
goes into the mainstream kernel we are stuck trying to cope with a kernel
design flaw at the API level.
Daniel
However there is a problem with gamin-0.0.24 if this is mounted under /media/... since it should not use dnotify in that case, I will need to investigate. Daniel Same problem for me using kernel-2.6.10-1.766 and new gamin-0.0.24 with my USB memory stick. No problem with the previous version (gamin-0.0.17). I have this problem with devices mounted _in_ /media and gamin-0.0.24 I have the same problem with my USB flash drive (mounts under /media/usbdisk). I use completely default settings for everything. Kernel is 2.6.10-1.766_FC3smp and gamin is gamin-0.0.24-1.FC3. The machine is kept always up to date with all updates. Same problem, with LACIE 160 gb USB hard disk. The kernel is 2.6.10- 1.766_FC3 and gamin is 0.0.24-1.FC3. Same as original problem. Umount will not work, "device busy". On repeated attempts gamin will not remain down long enough after kill to umount. A new process starts almost instantly. 60gB external USB hard disk mounted in /media/EXTERNAL1. The kernel is same as above "2.6.10-1.766_FC3" and gamin version 0.0.24. I have the same problem with unmounting of the CDROM (/media/cdrecorder). When I mount and unmount for the first time, there is no problem, but the second (, third, etcetera) CD I mount does not want to be unmounted (device busy). Killing the gam_server does not help because a new gam_server is spawned. I have selected KDE as window manager. I must say that it sounds strange to me that nautilus is operational while I am using KDE; I thought it was a GNOME program?! This was a regression in 0.0.24, this should be fixed in 0.0.25 which is in Rawhide or at http://www.gnome.org/~veillard/gamin/sources/ Daniel Confirmed fixed for me with 0.0.25. Thank you. |