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 (Show other bugs)
(Show other bugs)
Version: 5
Hardware: i686 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:
Story Points: ---
Clone Of:
Last Closed: 2006-03-19 01:32:58 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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/ld-2.3.3.so
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/libglib-2.0.so.0.400.6
gam_serve 20205    alex  mem       REG        3,3    1493072    
179352 /lib/tls/libc-2.3.3.so
gam_serve 20205    alex  mem       REG        3,3      47224    
176477 /lib/libnss_files-2.3.3.so
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 http://www.gnome.org/~veillard/gamin/debug.html 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.