GNOME Bugzilla – Bug 148028
Panel stops receiving GConf notifications
Last modified: 2004-12-22 21:47:04 UTC
stickynotes used to work very nice for months (GNOME 2.6), but now I'm using GNOME 2.7 and for a week or so, sometimes clicking on the applet simply does nothing. Killing the panel (next time I'll try to slay the applet only) solves the issue (when it happens the number of tries doesn't matter, it doesn't nothing for the whole running time). I've not really figured how to reproduce the problem, but it happens several times in a day. BTW I'm not sure on how to debug this problem. Let me know what information could be useful.
Are you still seeing this ?
It works right now, but I think I've had it yesterday with GNOME modules uptodate. I'll let you know it happens again. BTW I've noticed that the click event seems to work (the state of the check box in the menu change) when it happens.
Yes, still here, I've the problem right now. In fact the check box doesn't change on click, but if I right click and choose to change the notes in the menu it doesn't work better
I'm wondering if it's not a gnome-panel bug. I've tried to change the panel wide in the same time, didn't work, I've added an another applet, didn't work ... all was fixed after a "killall gnome-panel"
Ok, I think it's a panel bug, I'm reassigning. Not the first time I notice this but: - when I try to change a panel width there is no graphical result. The gconf key is updated as expected but that's all. - if I add an applet it's not displayed - the menus is not updated - this stickynotes bug ... clicking on the applet doesn't act as expected => "killall gnome-panel" and I've all these stuff working again (panel got the size specified before, new applets are displayed, stickynote works, menu is updated ...) All the GNOME modules are uptodates (not CVS but last tarballs released). I've the problem with stickynotes for some weeks now, and remember getting the "size not dynamically changed" about 2 weeks ago when I was trying to reproduce a bug. Let me know if you need details. I'm setting the severity to major, I think this is appropriate since in fact the panel is pretty broken.
It smells like an applet is behaving badly and messing the panel. Do you think it could be the stickynotes applet, or do you have other exotic applets on your panel ?
I'm not on this box right now, but I don't have "exotic app" afaik. IIRC my applets are: - GNOME menu - sound mixer - windows list - notify area - netspeed - system-monitor - weather - mail - clock
Hmm, it actually kind of sounds like GConf may be screwed up. When this happens what do you get if you do gconftool-2 -R /apps/panel/profiles/default and gconftool-2 -R /apps/stickynotes_applet/settings ? Also, what do you mean when you say "- the menus is not updated" ?
I'll have to check next time it happens. I've removed stickynote yesterday to see if it's the problem and at the end of the evening the panel was screwed in the same way. I was browsing the gconf prefs with gconf-editor, the panel width is updated directly for example but not visual change. "the menu is not updated" <- if I install a new desktop file it's not displayed until I kill the panel. fam is running and the menu updates work fine when the panel is not screwed
Please re-open when you've more details from reproducing it
I wish I could, but which details do you need ? It's broken again right now .... I can't give a way to reproduce it in 10 secondes but it happens very often here and not only on my box, so putting it in a "NEEDINFO land" and ignore it is not really a good idea I think. Please let this bug open and help me to debug instead of that
Calm down, I'm not ignoring the bug, I just need more information before I can hope to diagnose it. And doing it here means we still have the information if we end up leaving the bug for a while. Now, the information I wanted: "When this happens what do you get if you do gconftool-2 -R /apps/panel/profiles/default and gconftool-2 -R /apps/stickynotes_applet/settings ?"
Created attachment 30648 [details] gconftool-2 -R /apps/panel/profiles/default I'm calm, my experience is just that NEEDINFO bugs are ignored ... BTW I'm not running stickynotes atm, do you still want the output ?
I basically want to see if GConf is returning sane values at the time this happens - one of the reasons sticky notes might be doing nothing when you click on it is if it is getting weird values for /apps/stickynotes_applet/settings/click_behavior from GConf. So, yes - I only want the output from *both* those commands at the time you actually see this happening. Although, since you say the menus aren't updating, maybe its nothing to do with GConf at all.
$ gconftool-2 -R /apps/stickynotes_applet/settings date_format = %x visible = true autosave_time = 5 click_behavior = 1 sticky = true use_system_color = true force_default = false use_system_font = true confirm_deletion = true locked = false
So, you have it configured to hide/show the sticky notes on click ? Any messages relating to GConf in /var/log/messages at that time?
yes, it's an hide/show mode. I'm not sure it's clear, I've stopped to use stickynote today, turned the computer this night and it happens today again, so I think that's not related to stickynotes ... so I'm not it's useful to look on this applet. Apparently no message related to the problem in messages, just this sometime: aoû 17 14:54:25 localhost gconfd (seb-21102): démarrage (version 2.7.90), pid 21102 utilisateur « seb » aoû 17 14:54:25 localhost gconfd (seb-21102): Adresse « xml:readonly:/etc/gconf/gconf.xml.mandatory » résolue vers une source de configuration en lecture seule à la position 0 aoû 17 14:54:25 localhost gconfd (seb-21102): Adresse « xml:readwrite:/home/seb/.gconf » résolue vers une source de configuration enregistrable à la position 1 aoû 17 14:54:25 localhost gconfd (seb-21102): Adresse « xml:readonly:/etc/gconf/gconf.xml.defaults » résolue vers une source de configuration en lecture seule à la position 2
You're not using stickynotes anymore and you can still reproduce this bug? No, that wasn't clear? You're going to need to re-explain exactly what you're seeing here, and what triggers it, because I'm very confused now.
Ok, sorry if it was not clear. * I've first noticed a problem with stickynotes not working * some times after I've noticed than resizing the panel or adding/removing applets doesn't work in the same time. * then I've removed stickynote to test if the applet was faulty * now my panel is broken in the same way (changing width or addind/removing an applet, or adding a desktop file ... all these changes need a kill of the panel to be displayed). I don't nothing particular, I just use my computer and several in a time it get broken. I kill it and it works again for some time (hours ?) ... hard to notice when/how the break happen. My applets are: * menu * some launchers * notify area * wireless applet * battery * mixer * calendar * window list * show desktop * desktop switcher
Okay, so the issue you are seeing is: After I use the desktop for a while, the panel stops responding to configuration changes I make - changing the panel width, adding or remove objects etc. stops working. If I kill the panel, it restarts and I see the changes I made. When your desktop is like this, if you do gconftool-2 --shutdown, do you see a ~/.gconfd/saved_state file? If so, could you attach it here? What version of GConf is this, how are you building it, what distribution are you running etc.?
I've just killed the panel after the update 2.7.90 -> 91, I'll try on the next problem and give the result here. My system is basically a debian one + GNOME 2.7.90 packages, I'm updating to 2.7.91 now.
Might want to check out what Debian specific patches are in the GConf package
no patch in the gconf package
Created attachment 30669 [details] saved_state ok, broken again. I've a 16k saved_state
Nice. Notice the way none of the panel keys are being monitored. Not sure what could cause that, I'll look at it more tommorrow
I've seen this too with G2.7, when adding new applets or launcher to the panel.
Ross: can you confirm /apps/panel isn't in ~/.gconfd/saved_state for you?
Sebastien: I've looked over the code and its going to be quite difficult to debug why this is happening, but its something I'd love to see fixed. So, as a starting point it would be useful for you to reproduce this with GCONF_DEBUG_OUTPUT=1 set - i.e. set that env variable for the entire session and once you've reproduced the bug attach the output from /var/log/messages - also, it'd be good if the output wasn't in french :-)
Created attachment 31017 [details] detailed log Ok, the log of today is attached. The panel is broken again now, I've noticed that around 14h
according to the log gconf gets the changes but no graphical result (ie: if I change the width of the panel) ...
*** Bug 151300 has been marked as a duplicate of this bug. ***
This happens with me as well, however, I believe it is the Debian package. They have a custom patch to handle SIGHUP, which causes it to reload the database. This is used when upgrading gnome packages on a debian system. After the SIGHUP occurs, and it has reloaded the database, it no longer notifiers listeners about the changes. I have raised this as http://bugs.debian.org/268721 (This is possibly also bug 147472) (I could also be completely wrong .....)
No, they don't have a custom patch, this change is in the upstream code. BTW I've not tested if the problem is due to the sighup stuff but I'll try now, thanks for pointing this.
ok, that's it, I've just checked. Thanks a lot for noticing this; This code is bugged somewhere, and the Debian packages use SIGHUP after each schemas installation, that's why my system is broken so often.
They do have a patch, gconfd_sighup_reload.diff, look in gconf2-2.6.4/debian/patches after doing an "apt-get source gconf2"
The 2.6 debian package has this patch which is a part of the 2.7 upstream code. I'm using a 2.7 package without any patch. The Changelog entry related: 2004-07-05 Mark McLoughlin <mark@skynet.ie> Patch from Josselin Mouette <joss@debian.org> to handle SIGHUP by reloading all databases. Intended to be used in package's postinst scripts to get all running gconfds to reload schemas. * gconf/gconfd.c: (signal_handler): handle SIGHUP by setting flag. (periodic_cleanup_timeout): reload all databases when the reload flag is set.
Created attachment 31057 [details] [review] proposed patch Sorry, my patch for SIGHUP is at fault. I forgot to reinitialize the listeners after reinitializing the databases. This patch should do the trick.
Thanks Josselin: 2004-08-30 Mark McLoughlin <mark@skynet.ie> Patch from Josselin Mouette <joss@debian.org> in bug #148028 * gconf/gconfd.c: (periodic_cleanup_timeout): save and reload ~/.gconfd/saved_state so we don't drop listeners when reloading the database.
*** Bug 147472 has been marked as a duplicate of this bug. ***
*** Bug 145554 has been marked as a duplicate of this bug. ***