After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 172365 - nautilus/gamin fail to monitor directories after some time
nautilus/gamin fail to monitor directories after some time
Status: RESOLVED FIXED
Product: gamin
Classification: Other
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Gamin Maintainer(s)
Gamin Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2005-04-01 15:07 UTC by Martin Pitt
Modified: 2005-08-24 22:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Martin Pitt 2005-04-01 15:07:26 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.
Comment 1 Sebastien Bacher 2005-04-01 16:15:22 UTC
I get the issue too. That's not specific to ~/Desktop.
Comment 2 Sebastien Bacher 2005-04-02 11:05:42 UTC
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."
Comment 3 Martin Pitt 2005-04-04 06:48:38 UTC
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.
Comment 4 John McCutchan 2005-04-04 19:39:43 UTC
Hmm, I wonder if this could be causing
http://bugzilla.gnome.org/show_bug.cgi?id=171201
Comment 5 Martin Pitt 2005-04-04 19:44:34 UTC
> 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.
Comment 6 Sebastien Bacher 2005-04-05 14:14:21 UTC
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."
Comment 7 Christian Kellner 2005-04-11 17:53:56 UTC
*** Bug 172750 has been marked as a duplicate of this bug. ***
Comment 8 Sebastien Bacher 2005-06-07 08:14:42 UTC
seems to work fine with 0.1.0, I'm closing this bug
Comment 9 Jörgen Scheibengruber 2005-07-19 14:53:00 UTC
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). 
Comment 10 Jörgen Scheibengruber 2005-07-19 14:54:49 UTC
i tried to reopen the bug, but I'm not allowed to.
please reopen it, it's quite annoying ;)
Comment 11 Nicholas Miell 2005-07-20 03:43:49 UTC
I'm still seeing this on FC4 with gamin 0.1.1
Comment 12 Teppo Turtiainen 2005-07-20 06:12:53 UTC
Reopening because of additional comments.
Comment 13 Jörgen Scheibengruber 2005-07-22 11:26:41 UTC
Additional Info: My system is running 2.6.11 kernel (debian
kernel-source-package) => I have dnotify not inotify (if that is relevant).
Comment 14 John McCutchan 2005-07-22 13:09:37 UTC
Yes this is very relevant. By any chance do you use beep media player? 
Comment 15 John McCutchan 2005-07-22 16:17:24 UTC
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.
Comment 16 John McCutchan 2005-08-03 03:22:06 UTC
This is fixed in 0.1.3.
Comment 17 Christian Neumair 2005-08-24 22:34:19 UTC
Closing.