GNOME Bugzilla – Bug 172365
nautilus/gamin fail to monitor directories after some time
Last modified: 2005-08-24 22:34:19 UTC
Version details: 0.0.26 Distribution/Version: Ubuntu Hoary After some time, nautilus windows and the desktop are not automatically updated any more after file changes. If this happens, it helps to press Control-R to reload manually, and/or to killall gam_server to restart gamin. A test case which reliably reproduces it on my i386 and ppc machine, and also on sb else's box is while true; do echo Hallo > Desktop/baz; sleep 1; rm Desktop/baz; sleep 1; done This works a couple of times, then the icon simply stops (dis)appearing. Interestingly enough, if I replace "echo Hallo >" with "touch", then this works ad infinitum (zero file size, different MIME type, I don't know why). https://bugzilla.ubuntu.com/show_bug.cgi?id=7078 has some logs attached which show what happens when running nautilus with GAM_DEBUG. I was not able to reproduce the bug (i. e. stopping Created/Removed) messages with testgam. We already discussed this in IRC, probably the cause is the concurrent access and the multiple dir/file monitors of nautilus.
I get the issue too. That's not specific to ~/Desktop.
New comments on bugzilla.ubuntu.com: "Hi guys, I have been testing this bug and experienced the following: - machine A (very fast processor): cannot reproduce at all. - machine B (very slow processor): reproducible in 1 Martin's loop. attempting to isolate the problem, i noticed that killing either gam_server or nautilus will restore the standard operations. ... The problem is located in the gamin remove_subscription code or around that area. While running the loop, all of a sudden gamin deregisters my entire home from being polled. This also explain Martin's error message from nautilus: "Failed to find request N" ( i get different values of N) nautilus has no knowledge that gamin has stopped monitoring the dir and requestes will fail since there is no data entry for it anymore. restarting nautilus will readd /home/$user to the gamin list of dirs to poll. restarting gamin will do the same. So now.. we need to understand why gamin decides that it is time to stop monitoring $HOME. Fabio Note that i am talking about polling here, since gamin is using dnotify as monitoring backend. I did also test the inotify variant (please do NOT do that if you are not 100% of what you are doing) and the backend tends to survive longer (a bunch of more loops) but still dies at end. .. I have isolated the problem to the dnotify and inotify backends."
The Ubuntu bug at https://bugzilla.ubuntu.com/show_bug.cgi?id=7078 has new comments which pinpoint the bug source pretty well. Now there is also a patch which works around the broken signal handling; the patch is not a good final solution for upstream, though.
Hmm, I wonder if this could be causing http://bugzilla.gnome.org/show_bug.cgi?id=171201
> Hmm, I wonder if this could be causing > http://bugzilla.gnome.org/show_bug.cgi?id=171201 Indeed, we had a similar bug report in Ubuntu which now was closed since our patched gamin fixes it.
from the distro bugzilla: " while running the usual test case: 0 shows a remove signal, 1 an add signal. gam_dnotify_file_handler /home/fabbione/Desktop/baz : 0 gam_dnotify_file_handler /home/fabbione/Desktop/baz : 1 gam_dnotify_file_handler /home/fabbione/Desktop/baz : 0 [here is missing an add event] gam_dnotify_file_handler /home/fabbione/Desktop/baz : 0 [bum] It looks like once there are 2 decrements with a missing call the server simply can't recover from that situation and it stops monitoring the entire directory. None of the clients seem to care to readding it back. .... Getting more close. Using the same scenario i noticed that refcount is bong: Add: gam_dnotify_file_handler /home/fabbione/Desktop/baz : 1 not a dir using parent /home/fabbione/Desktop Jumping to gam_dnotify_directory_handler_internal Adding /home/fabbione/Desktop to dnotify found incremented refcount: 3 Removal: gam_dnotify_file_handler /home/fabbione/Desktop/baz : 0 not a dir using parent /home/fabbione/Desktop Jumping to gam_dnotify_directory_handler_internal Removing /home/fabbione/Desktop from dnotify found decremented refcount: 2 [Missing add] Removal: gam_dnotify_file_handler /home/fabbione/Desktop/baz : 0 not a dir using parent /home/fabbione/Desktop Jumping to gam_dnotify_directory_handler_internal Removing /home/fabbione/Desktop from dnotify found decremented refcount: 1 Add: gam_dnotify_file_handler /home/fabbione/Desktop/baz : 1 not a dir using parent /home/fabbione/Desktop Jumping to gam_dnotify_directory_handler_internal Adding /home/fabbione/Desktop to dnotify found incremented refcount: 2 Remove: gam_dnotify_file_handler /home/fabbione/Desktop/baz : 0 not a dir using parent /home/fabbione/Desktop Jumping to gam_dnotify_directory_handler_internal Removing /home/fabbione/Desktop from dnotify found decremented refcount: 1 [another missing add!] Remove: gam_dnotify_file_handler /home/fabbione/Desktop/baz : 0 not a dir using parent /home/fabbione/Desktop Jumping to gam_dnotify_directory_handler_internal Removing /home/fabbione/Desktop from dnotify deactivated DNotify for /home/fabbione/Desktop goodbye Desktop ... We are experiencing 2 bugs here: 1) both the dnotify and inotify backends lose some signals during normal operations. In my environment they miss some Add messages. This leads to bug number 2. 2) the dnotify and inotify backends remove direcotries from polling automatically when not requested to do so by the client. Given that we miss some signals (that could happen for several reasons but still wrong) the backend automatically removes a Directory from being polled when the refcount is 0. It is a client task to tell gam_server to stop polling a certain dir since it might want to monitor an empty dir for example. The server has no way to know that."
*** Bug 172750 has been marked as a duplicate of this bug. ***
seems to work fine with 0.1.0, I'm closing this bug
i still see this in 0.1.2 on debian unstable... (i often download stuff to ~/Desktop/ and as soon as i do that, gamin stops working).
i tried to reopen the bug, but I'm not allowed to. please reopen it, it's quite annoying ;)
I'm still seeing this on FC4 with gamin 0.1.1
Reopening because of additional comments.
Additional Info: My system is running 2.6.11 kernel (debian kernel-source-package) => I have dnotify not inotify (if that is relevant).
Yes this is very relevant. By any chance do you use beep media player?
I can easily reproduce this bug without inotify enabled. Daniel, there is something very serious going on the gtk+ file selector. It is causing watches to be disabled. I reproduced this with both beep-media-player and galeon. Steps: 1) Open file selector 2) Close app repeat a couple times echo > ~/Desktop/ZZ nautilus won't be notified. If you check the debug output, nautilus still thinks its watching ~/Desktop, but the dnotify backend doesn't.
This is fixed in 0.1.3.
Closing.