Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 132740 - gamin stuck in D state on cifs
Summary: gamin stuck in D state on cifs
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Steve Dickson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-16 15:53 UTC by Laurent Jacquot
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-03-19 01:32:58 UTC

Attachments (Terms of Use)

Description Laurent Jacquot 2004-09-16 15:53:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040803 Firefox/0.9.3

Description of problem:
I have a cifs share defined in my fstab. This share appears correctly
in mycomputer:///

As soon as i click on this share, gnome-vfs mounts the volume and
opens a window showing the content.

But gam_server enters D state and I have to reboot (with alt-sysrq-s
to keep my datas in place).

lsof|gam gives:

gam_serve 20205    alex  cwd       DIR        3,8       4096   
3604481 /home/alex
gam_serve 20205    alex  rtd       DIR        3,3       4096          2 /
gam_serve 20205    alex  txt       REG        3,5      35016    
113626 /usr/libexec/gam_server
gam_serve 20205    alex  mem       REG        3,3     106544    
176362 /lib/
gam_serve 20205    alex  mem       REG        3,5      21544   
1249438 /usr/lib/gconv/gconv-modules.cache
gam_serve 20205    alex  mem       REG        3,5     511976   
1220956 /usr/lib/
gam_serve 20205    alex  mem       REG        3,3    1493072    
179352 /lib/tls/
gam_serve 20205    alex  mem       REG        3,3      47224    
176477 /lib/
gam_serve 20205    alex    0r      CHR        1,3                  
885 /dev/null
gam_serve 20205    alex    1w     FIFO        0,7                
41671 pipe
gam_serve 20205    alex    2w     FIFO        0,7                
41671 pipe
gam_serve 20205    alex    3r     FIFO        0,7                
61113 pipe
gam_serve 20205    alex    4r     FIFO        0,7                
42374 pipe
gam_serve 20205    alex    5w     FIFO        0,7                
42374 pipe
gam_serve 20205    alex    6r     FIFO        0,7                
42375 pipe
gam_serve 20205    alex    7w     FIFO        0,7                
42375 pipe
gam_serve 20205    alex    8r     FIFO        0,7                
42376 pipe
gam_serve 20205    alex    9w     FIFO        0,7                
42376 pipe
gam_serve 20205    alex   10r     FIFO        0,7                
42377 pipe
gam_serve 20205    alex   11w     FIFO        0,7                
42377 pipe
gam_serve 20205    alex   12w     FIFO        0,7                
61113 pipe
gam_serve 20205    alex   13u     unix 0x25eb9dc0                
61116 socket
gam_serve 20205    alex   14u     unix 0x33159dc0                
61128 socket
gam_serve 20205    alex   15u     unix 0x330204c0                
61129 socket
gam_serve 20205    alex   16u     unix 0x2421fdc0                
76399 socket
gam_serve 20205    alex   17r      DIR        3,5       4096   
1104668 /usr/share/mime-info
gam_serve 20205    alex   18r      DIR        3,5       4096   
1155580 /usr/share/control-center-2.0/capplets
gam_serve 20205    alex   19r      REG        3,5       3293   
1049610 /usr/share/applications/defaults.list
gam_serve 20205    alex   20r      REG        3,5       6245    
210935 /usr/share/applications/mimeinfo.cache
gam_serve 20205    alex   21r      DIR        3,5       4096   
1038403 /usr/share/applications
gam_serve 20205    alex   22r      DIR       0,18       8192         
2 /home/alex/webMaint
gam_serve 20205    alex   26r      REG        3,3        482    
481850 /etc/mtab
gam_serve 20205    alex   27r      REG        3,3       1440    
481748 /etc/fstab
gam_serve 20205    alex   31r      DIR        3,5       4096   
1104677 /usr/share/desktop-directories
gam_serve 20205    alex   32r      DIR        3,5       4096   
1153124 /usr/share/applnk
gam_serve 20205    alex   33r      DIR        3,3       4096    
480994 /etc/X11/applnk
gam_serve 20205    alex   40u     unix 0x30e21940                
61132 socket

/home/alex/webMaint is the culprit..

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
0:have a working rawide (with a working gamin install)
1.configure a (real) cifs share in fstab
2.double click in the created icone in nautilus
3:the window showng the share opens
3.gam_server never recovers from its D state

Actual Results:  gam_server never recovers from its D state
cannot safely reboot or halt the system as the mounts are "busied" by
the gam_server opened FDs

Expected Results:  gam_server should monitor the rep like all the
others rep

Additional info:

didn't have time to strace gam_server, will do it if needed

Comment 1 Daniel Veillard 2004-09-16 20:24:53 UTC
Can you tell me how to "configure a (real) cifs share in fstab" ?
Pointer to example would help, I never used such filesystem.


Comment 2 Daniel Veillard 2004-09-16 20:28:09 UTC
What kernel version are you using too ? Because stuck in D state
mean some of the syscalls blocks. And I'm only using classic stuff
like directories listing, stat and dnotify, and getting in D state
there mean some of the kernel operations just fails.


Comment 3 Laurent Jacquot 2004-09-16 21:06:24 UTC
cifs is the "new" way to share folders under windows. It is a samba
like protocol (on the 445 tcp port instead of 139). My fstab looks like:
//    /home/alex/Alex_ASN           cifs  
0 0

man 8 mount.cifs (part of the samba-client package)

my kernel is a fedora distributed package: kernel-2.6.8-1.541

I guess (but tomorrow i will strace the process) it is the dmotify
call that fails, because using the share works fine (meaning open read
write, stat et al. sucess)

Comment 4 Laurent Jacquot 2004-09-16 21:52:07 UTC
Ok, more infos:
Gam_server seems to work fine with cifs.
To trigger the bug I must:
open the computer:/// window while the share is not mounted _and_
double click on that share. The share is then mounted by gnome_vfs and
then gam_server enters D state...

I straced gam_server, it got stuck on a poll syscall:

read(28, "GIOP\1\2\1\0\332\3\0\0", 12)  = 12
read(28, "p\362\377\376\3\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0G\364\220"...,
986) = 986
time(NULL)                              = 1095370666
stat64("", 0xfefff23c)                  = -1 ENOENT (No such file or
stat64("/usr/lib/bonobo/servers", {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
writev(28, [{"GIOP\1\2\1\1(\0\0\0", 12},
{"p\362\377\376\0\0\0\0\1\0\0\0\1\0\0\0\f\0\0\0\1\1\1\1\1"..., 40}],
2) = 52
poll( <unfinished ...>

Perhaps it is the mount taking over the directory wich is already
inotified, leaving unpollable fds behind? Kernel bug?

Comment 5 Daniel Veillard 2004-09-16 22:05:12 UTC
No idea, GIOP substrings are weird, it's some corba stuff ... I do not
see how/why gam_server, would do corba, it makes no sense to me.
are you sure it's a gam_server trace ? 
See for help on
debugging gamin client or server side.


Comment 6 Daniel Veillard 2004-09-17 08:57:33 UTC
At this point seem it's more likely to be a kernel bug or cifs 
related bug. Reassigning following arjan's suggestion,


Comment 7 Daniel Veillard 2004-09-17 09:03:04 UTC
Note also that if the straced process was the wrong one alex seems
to think it might be a race between nautilus mounting the share and 
monitoring it. perhaps we start monitoring before the mount
starts/finishes or, its just due to the mount just finishing.


Comment 8 Mark McLoughlin 2004-09-17 09:09:58 UTC
My guess is that the strace is of bonobo-activation-server rather than
gam_server - only b-a-s would stat /usr/lib/bonobo/servers. Laurent,
are you sure you straced the correct process?

Comment 9 Laurent Jacquot 2004-09-17 10:50:43 UTC
I'm really sorry :-( i traced the wrong process.
Here's the correct one and it makes much more sense:

gettimeofday({1095417654, 710281}, NULL) = 0
poll([{fd=28, events=0}, {fd=29, events=POLLIN}, {fd=35,
events=POLLIN}, {fd=28, events=POLLIN}, {fd=40, events=POLLIN},
{fd=34, events=POLLIN, revents=POLLIN}, {fd=3, events=POLLIN}], 7,
926) = 1
gettimeofday({1095417654, 835866}, NULL) = 0
read(34, "\35\0\1\0\24\0\1\0\23\0/home/alex/Alex_ASN", 4106) = 29
gettimeofday({1095417654, 837302}, NULL) = 0
poll([{fd=28, events=0}, {fd=29, events=POLLIN}, {fd=35,
events=POLLIN}, {fd=28, events=POLLIN}, {fd=40, events=POLLIN}, {fd=3,
events=POLLIN}, {fd=34, events=POLLIN}], 7, 0) = 0
time(NULL)                              = 1095417654
stat64("/home/alex/Alex_ASN", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open("/home/alex/Alex_ASN", O_RDONLY)   = 30
fcntl64(30, F_SETSIG, 0x21)             = 0
fcntl64(30, 0x402 /* F_??? */

A this point gam_server enters the D state...

Comment 10 Fabien MARTY 2005-07-13 10:34:34 UTC
Exactly the same problem here with a RHEL 4 (U0 and U1). We are ok to test new
kernel if it can help.

Comment 11 Dave Jones 2005-10-06 02:55:59 UTC
Laurent, is this still happening on current releases ?

Fabien, please file a seperate bug for RHEL4 problems if its still an issue
there, even if it seems like the same issue.

Comment 12 Laurent Jacquot 2005-10-06 17:57:59 UTC
cannot reproduce right now as I have no shares at hand:-( But last time I
checked the pb was still there.
If I remember correct, it was with around mid september (the 11 sept) with a
current fedora-devel and the kernel built with the following:

wget kernel-version.tar.bz2
tar xjf kernel-version.tar.bz2
cd kernel-version
cp /boot/config-version-1 .config
make oldconfig
make rpm
rpm -ivh /usr/src/redhat/i386/kernel-version.rpm
/sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install version

Tell me if you want more infos, I'll try to get the windows laptop.

Comment 13 Laurent Jacquot 2006-03-18 11:50:38 UTC
Actually, I can no longer reproduce this D state with current kernels (lots of
them via rawhide).
So I guess we can close it

Note You need to log in before you can comment on or make changes to this bug.