Bugzilla – Bug 118384
gconftool should be restarted after package installation
Last modified: 2010-05-05 11:34:52 UTC
How to reproduce: 1. Run GNOME as user 2. Install any package using gconf database. 3. Start it - keys in gconf database are missing or outdated. Ther reason is, that gconf damenon caches keys and this cache is not updated. I don't know, how to cleanly provide a fix. Simplest, but not really clean solution seems to be gconftool-2 --shutdown for all UIDs, for which it is running. Clean solution can be some way of change notification or at least flushing cache.
I believe just installing via gconftool would work, that should be the point of the tool.
But gconftool-2 --makefile-install-rule does not force reloading database in running instances of GConf daemons caching the configuration source.
This is also in Gnome bugzilla as: http://bugzilla.gnome.org/show_bug.cgi?id=156057
A thought - have gconfd-2 monitor its sources for changes (inotify?) and reload (or restart) as necessary?
Definitely possible, but why not just fix gconftool to update the cache? I guess I am not following why this does not "just work" to begin with. It sounds like a big problem!
Gconfd-2 now expects, that readonly sources are never changed. But gconftool-2 --makefile-install-rule (and root's gconf-editor) writes to read-only resources. Another gconftool-2 --makefile-install-rule problem is the bug 48114 (http://bugzilla.gnome.org/show_bug.cgi?id=306924).
This is also an upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=328697 It recommends to add as a last command in %post: killall -HUP gconfd-2 Is it OK for everybody?
Or use Mandriva's solution, which HUPs gconfd-2 for every schemas file installed. http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/GConf2/GConf-2.8.1-reload.patch
We would have to HUP it in every package that installs a schema? Bleh. I am astonished that gconftool does not handle this already. What, then, is its point?
Oh, this is a problem only with merged subtrees? That makes more sense. This just came up on d-d-l. See http://bugzilla.gnome.org/show_bug.cgi?id=328697
No, this problem occurs from the first day of GNOME. Mandriva uses HUP for every installed schema, other distros for every installed package. I plan to add this killall to %post of every package using gconftool-2. It was and is easy to reproduce - install new package in a running session and run it. You will probably have nonsenses in default, and what is worse, these nonsenses can be written to local ~/.gconf. To reporduce worst case: - Compile gnome-applets2 without libgtop and install. - Start session. - Install standard gnome-applets2. - Add system load monitor applet. Actual result: Applet is all in black. In particular, in past I have seen ever worse results - not being able to run an application any more without purging local gconf database.
So, the SIGHUP code for some reason only marks need_db_reload as true and that is checked every 30 seconds. Why its not immediate, I don't know. I'm still in favor of an inotify solution because the reload hooks are already in place, we just need to trigger them differently.
For 10.1 / SLES10, this is a simplest solution. GNOME 2.14 can have this issue fixed better. I have another idea, maybe simpler to implement use SuSEconfig and send this signal every time. The database reload is probably faster than checking, that the reload is needed.
Added a simple SuSEconfig.gconf2. Better fix should appear in future from upstream.
Thorsten did not really like adding another SuSEconfig script (remember that we want to _reduce_ the number of these). How much effort is the notify solution ?
Adding of exactly the same command to about 73 spec files. It is not a big problem, but in case of installation of many packages, it forces realoading of database for each package. SuSEconfig will do it only once (but for all packages).
that's not at all what I was referring to with "notify solution". I was talking about gconfd monitoring it's directories via dnotify/inotify without needing external help from SIGHUPs or other hacks.
This solution will be probably ready with GNOME 2.14, which has a significantly rewritten backend. For now, I guess, that HUP in SuSEconfig is a good work-around (used by most other vendors). Federico, what do you see as a best solution for GNOME 2.12? HUP or backporting dnotify/inotify support?
HUP is what creates the least amount of work for us right now, either in specfiles or in SuSEconfig. I think we should use this method for GNOME 2.12. It would be really nice to have inotify support in the near-term future, however. There's a thread about this here: http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00438.html The main points in the thread are that yes, everyone wants inotify/fam/gamin/whatever, but these methods have different kinds of support for notification on NFS home directories and other network stuff. Everyone hates FAM, but it has the best support for networks. Gamin is unmaintained. Inotify is Linux-only. Can we just make FAM use inotify directly for the local case? I still don't understand why Gamin got written :)
Fam only works with NFS and its is turned off by default because its a security whole. is /etc really going to be mounted on a remote partition anyhow?
We can probably use the Redhat one liner patch to gconftool-2 as Dan points out.
FAM works with local files, too. But daemon has to be running. gamin works with local files only. Please note that we have a FAM/GAMIN wrapper for gnome-vfs2 and libgda. So it you will use libfam, you should add this wrapper, too.
(reassign to my ximian address to work around bugzilla.novell.com stupidity)
Committed the patch from the Red Hat bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173869#c10 because of how killall works, this only kills gconfd-2 if the running binary is the same as the binary on disk. This means that after installing the new gconf2 package, you still won't get the bugfix until gconfd is restarted (eg, log out and back in), and it also means that future gconf2 package updates will temporarily break schema updates. This isn't perfect, but it seems safer than running a less-specific killall command (as root). And assuming we aren't putting out new gconf2 packages left and right, it will solve the original problem. Committed, but too late for Beta4, so it should be in Beta5.
bnc#534928 is caused by the similar reason.