GNOME Bugzilla – Bug 323064
the panel applications menu is displayed empty with gamin 0.1.7/inotify
Last modified: 2006-09-08 12:15:18 UTC
This bug has been opened here: https://launchpad.net/distros/ubuntu/+source/gamin/+bug/5176 "When I click on application menu, the menu is displayed. But as soon as it's drawn, it disappears and only the small left-up coin of the menu remains..." Debian bug about this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338438 This happens with gamin 0.1.7/inotify but not gamin 0.1.6/inotify or gamin 0.1.7/dnotify.
ubuntu bugzilla bug about that: https://bugzilla.ubuntu.com/show_bug.cgi?id=20216
Created attachment 55551 [details] log of gam_server 0.1.7/inotify when clicking on the apps menu
Created attachment 55552 [details] menu verbose log of the panel
I'm seeing this too, let me know if I can help
On Ubuntu/Dapper (gnome 2.13.3, gamin 0.1.7, kernel 2.6.15-rc5), I've observed that the panel menu works fine so long as the files that gnome-panel wants to watch are NOT watched with inotify. Adding the following to /etc/gamin/gaminrc fixes gnome-panel's problems without too heavy an impact on the rest of the system. poll /etc/xdg/menus/* /home/*/.config/menus/* /usr/share/desktop-directories/* /usr/share/applications/* /usr/share/applications /usr/share/control-center-2.0/capplets /usr/share/control-center-2.0/capplets/* /usr/share/gnome/apps /usr/share/gnome/apps/* Cheesy workaround, I know. :)
Hmm, on my Dapper system, it seems like the file '/etc/xdg/menus/debian-menu.menu' points to the non-existent '/var/lib/menu-xdg/menus/debian-menu.menu'. From my observations, it seems that Gamin seems to be reporting a bizarre "file created" event for 'debian-menu.menu' when the watch is first created. This then causes libmenu to "recanonicalize" (gmenu-tree.c:handle_nonexistent_menu_file_change), which makes everything disappear. There are three problems here: 1. It's silly to generate a created event on monitor startup for a symlink which points nowhere. This would be either gamin's, inotify's, or the fam specification's fault. If gamin/inotify _is_ really working according to specification, I guess we'll just have to workaround it in libmenu. 2. The whole libmenu system should probably not go bananas just because it got an erroneous notification. 3. Debian/Ubuntu probably shouldn't be shipping a symlink which points to nowhere in the menu-xdg package.
Created attachment 56463 [details] gamin testcase which reproduces the created notification for pre-existing symlink Attaching a testcase which demonstrates gamin producing a created notification when confronted with a pre-existing symlink which points to nowhere. The specific output is: mkdir /tmp/test_gamin link /tmp/test_gamin/foo to /tmp/test_gamin_SHOULD_NOT_EXIST/bar connected to test monfile /tmp/test_gamin/foo 0 1: /tmp/test_gamin/foo Created: NULL rmfile /tmp/test_gamin/foo disconnected rmdir /tmp/test_gamin
(In reply to comment #6) > Hmm, on my Dapper system, it seems like the file > '/etc/xdg/menus/debian-menu.menu' points to the non-existent > '/var/lib/menu-xdg/menus/debian-menu.menu'. > 3. Debian/Ubuntu probably shouldn't be shipping a symlink which points to > nowhere in the menu-xdg package. This file is created by "update-menus" which should be runned every time a package install a menu entry and by menu/menu-xdg at the installation. Does running "sudo update-menus" fixes this issue for you?
Cc-ing the inotify maintainer, maybe he has some comments on the testcase and the description of the issue
There were no significant changes to gamin/inotify between 0.1.6 and 0.1.7. In fact there were only a handful of changes made in total. Has anyone bothered to find the exact change the breaks the system?
People watching this bug should probably be aware of bug #314854 if that is fixed, this problem would become much less important.
Created attachment 56480 [details] [review] Patch to make gamin not try to watch symbolic links using inotify Here's a patch which modifies gam_inotify_add_subscription to automatically add symbolic links to the "links list", instead of first trying to add them to the normal watch list and seeing what happens. fam is only interested in whether the symbolic link exists or not (see: http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&fname=/SGI_Developer/books/IIDsktp_IG/sgi_html/ch08.html), we don't want inotify telling us about the state of the actual file. the patch also includes an updated testcase + result file.
In response to Sebastian: I had to manually install the 'menu' package (from universe?) in order to get update-menus. After running it, the invalid symlink is still there.
in fact the bug happens with 0.1.6 too but not with 0.1.5
The patch looks good. If gamin still passes it's test suite with it applied it should go in.
Gah, running 'make check', I see the test suite fails in different ways than it did before (yes, it fails by default on my machine). I'll look into making it least work as well as it did before committing.
Since people have asked me about it, the latest chapter of this bug can be found on the gamin mailing list: http://mail.gnome.org/archives/gamin-list/2006-January/msg00000.html
The test suite in gamin is seriously busted. It's always been racey and not very reliable (Changes in the kernel can change the test suite results -- but not in a way you'd expect). Anyways, Considering the state of the inotify backend in gamin and the fact that in gnome 2.14 gnomevfs will use inotify directly, I wouldn't resist a patch that just disabled inotify support in gamin. It has subtle bugs (unrelated to this one) and unless someone is willing to step up and incorporate the backend I developed for gnomevfs (or fix the current one), gamin is better of not using inotify. OR, as an alternative, revert the inotify code back to 0.1.5. The code released in 0.1.5 passed the test suite and lacked this bug.
for information I've used the gnome-menus/gnome-vfs patch for Ubuntu dapper and it works fine/fix this bug
The code path which causes this is: Menu created: "panel-menu-needs-loading"=1 show(menu)->submenu_to_display()->...->gmenu_tree_add_menu_file_monitor(); "panel-menu-needs-loading" = 0 ...->fam/gam_server->... handle_gmenu_tree_changed() destorys the menu schedules "panel-menu-needs-loading"=1 again If 'gam_server' is killed, the cycle is broken. If show() is called, the cycle is restarted. Couple of bugs here: 1. Menu is destoryed, then update is scheduled. Menu should only be destoryed when there is new data to fill it with. 2. A rebuild can only happen from show(), but a destory can happen anytime a menu file is changed. 3. FAM sends a notification in the case of a dangling symlink. Changing to gnome-vfs doesn't actually fix any of these. 1. Might be fixed by http://www.paul.sladen.org/ubuntu/bugs/gnome-panel_2.13.4-0ubuntu3.applications-menu-disappearing.deb.diff 2. Rebuilds should happen anytime, not just when a show() occurs. 3. I think that is fixed elsewhere but awaiting acceptance, but /shouldn't/ actually help in this case. Critical backtraces are:
+ Trace 65127
for destorying the menu and asking for the update. This will *always* occur at least once when 'gam_server' is running and a monitor request is made for a non-existant file.
*** Bug 323755 has been marked as a duplicate of this bug. ***
Paul: Note that your analysis is very similar to mine above (albeit more detailed on the exact nature of the problem with gnome-menu). Regardless, there is a real issue here wrt Gamin's inotify backend, and (IMO) this bug should stay open until that fix is applied. Although I'm not an expert wrt GNOME's policy, it makes sense to me to open up a seperate issue to track the problem with gnome-menu (where you can get feedback from the actual maintainer on the correctness of your fix, etc.).
Point two is updated by the following testing patch (Thanks to vuntz): http://www.paul.sladen.org/ubuntu/bugs/gnome-panel-menu.bug2.diff This makes the menu now manically flash like a strobe light as it is constantly emptied and repopulated (it's not usable as you can't actually use any of the sub-menus.
It also uses makes 'gnome-panel' use 100% CPU in the back ground while /not/ being displayed! It might be a fix, but I'm not sure it's an improvement ;-)
In my current Debian the situation has "improved": I know have a blinking applications menu that switches from 1x1 px to what it should be. It's of course still impossible to select anything. As somebody mentinoned, killall -KILL gam_server is a workaround. I can't believe I have not been seeing my menu for half a year now.
*** Bug 345808 has been marked as a duplicate of this bug. ***
I am experiencing this same issue (as comments 24, and 25) on debian. My menu flickers and the menu uses as much cpu as the kernel lets it when ever the menu applet is loaded. It appears that we know what the problem is here, why has a fix not been written/applied yet?
Because gamin hasn't been actively maintained for almost a year now. GNOME >= 2.14 doesn't use gamin/FAM anymore. If you can't upgrade and you insist on running gamin instead of FAM I suggest you rip out the inotify bits as they are rotten.
So this then is a bug with gnome-menus, which needs to switch to using gnome-vfs or inotify (which I thought I saw it was doing). Also it looks like the debian package has a patch which makes it use gnome-vfs instead of fam which would lead me to believe the problem I am seeing is a problem with inotify/gnome-vfs/gnome-menus. Thanks for your quick reply.
w.r.t. comment #28 I'm kind of surprized. John you're the author of that inotify part, you don't care ? Gamin has never been part of GNOME actually, that was a concious decision and I resisted the request. That's not a change in itself. Daniel
#29: Many distributions include a patch that makes gnome-menus use gnome-vfs instead of FAM directly. But gnome-vfs <= 2.12 uses FAM so the problem still exists there. #30: Yeah I'd like to fix the warts in the gamin inotify code but I don't have the time currently. Gamin's inotify code isn't that bad, but there are some potentially serious bugs in it. When I get some time I plan on taking gnome-vfs's inotify code and dropping it into gamin as the new backend.
Just a bit of data point for fixing gamin: since whatever the API one need to register timeout for watched but non-existent resources, using a centralized watchdog like gam_server allows to not run one timer per program watching. Dave Jones pointed out the excessive amount of watches during OLS (gam_server was pointed out too due to excess of syscalls even when iddle, but at least it's centralized). Daniel
The next gamin release will have a new inotify backend (the same as gnome-vfs's) so this should be fixed now.
Do the unit tests still pass as well a they did before? That was the reason my earlier patch wasn't put in IIRC.