Bug 173869 - new schemas don't seem to be picked up by running gconfd
new schemas don't seem to be picked up by running gconfd
Product: Fedora
Classification: Fedora
Component: GConf2 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
: Reopened
Depends On:
Blocks: FC5Blocker 214232
  Show dependency treegraph
Reported: 2005-11-21 19:21 EST by Jeremy Katz
Modified: 2008-08-02 19:40 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-08 14:07:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Have gconftool send a HUP to gconfd (573 bytes, patch)
2006-02-02 12:08 EST, Toshio Kuratomi
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 328697 None None None Never

  None (edit)
Description Jeremy Katz 2005-11-21 19:21:27 EST
Installing new schemas with --makefile-install-rule (eg, as part of a package
%post) don't seem to be picked up by running instances of gconfd-2.  First
noticed with gnome-power-manager but reproduced with a pretty trivial schema
file afterwards, so I don't think it has anything to do with the specific schema.
Comment 1 Ray Strode [halfline] 2006-01-11 12:08:06 EST
Hey Jeremy,

So at one point, g-p-m had this:

export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
gconftool-2 --makefile-uninstall-rule \
        %{_sysconfdir}/gconf/schemas/gnome-power-manager.schemas >/dev/null

which might manifest itself as the problem you're seeing here.  Do you think
that's what happened?

If you do:

$ gconftool-2 --recursive-unset /apps/gnome-power-manager
$ killall gconfd-2
$ gconftool-2 \
--direct --config-source=$(gconftool-2 --get-default-source) \
--makefile-uninstall-rule \

then install the latest version of gnome-power-manager are you still seeing the
Comment 2 Jeremy Katz 2006-01-11 13:00:40 EST
I was getting the same thing to happen, though, just with a foo.schema that set
Comment 3 Christopher Aillon 2006-01-24 03:44:06 EST
Note, that I added a hack around to the rhythmbox spec file.  When this bug is
fixed, that hack should be removed.
Comment 4 Mark McLoughlin 2006-01-26 02:40:11 EST
If run as root, gconftool-2 --makefile-install-rule could do killall -HUP
gconfd-2 perhaps ...

(The problem was always there, but it's worse now with the merged subtree)
Comment 5 Mark McLoughlin 2006-01-26 04:15:52 EST

Comment 6 Toshio Kuratomi 2006-01-26 15:25:34 EST
Fedoraproject Scriptlet Snippets page recommends running  "killall -HUP gconfd-2
|| :" after doing a --makefile-install-rule/--makefile-uninstall-rule::


If gconftool-2 adds this internally, I'll note that the need for it has been
removed for FC5+.  The alternative would be Core packages installing gconf
schemas follow the advice to send a HUP in the rpm scriptlets.
Comment 7 Christopher Aillon 2006-02-01 18:02:31 EST
Testing a patch now.  Taking.
Comment 8 Christopher Aillon 2006-02-01 22:05:50 EST
Fixed in tomorrow's rawhide using patch from
Comment 9 Toshio Kuratomi 2006-02-02 11:58:39 EST
Unless patch has changed on FC5, the patch needs to be updated.  The area that
it's updating has several sections that are very similar and the fuzz factor is
causing problems::

      gconf_engine_unref (conf);

      g_spawn_command_line_sync ("/usr/bin/killall -q -HUP " GCONF_SERVERDIR "/"

      g_spawn_command_line_sync ("/usr/bin/killall -q -HUP " GCONF_SERVERDIR "/"

      return retval;

This is screwy enough it might be considered a patch bug....

I'll submit an updated patch in a moment.
Comment 10 Toshio Kuratomi 2006-02-02 12:08:47 EST
Created attachment 124058 [details]
Have gconftool send a HUP to gconfd

Previous patch applies to the wrong section of code.  This patch applies one
section to the makefile-install code path and one to the makefile-uninstall
Comment 11 Christopher Aillon 2006-02-02 12:25:15 EST
Hah.  I did know that and created a new patch; I just uploaded the wrong one. 
Comment 12 Matthias Clasen 2006-02-15 10:24:22 EST
Still seems broken in post-test3 rawhide.

I changed gnome-applets to include mini commander again, but 
when I updated the package, the schema did not get picked up.
manually installing the schema again did not help either.
restarting  gconfd did.
Comment 13 Ray Strode [halfline] 2006-02-15 14:05:37 EST

Chris says that he built updated packages into rawhide that may fix this
problem.  Closing... (but let's reopen if it the problem happens again).
Comment 14 Owen Taylor 2006-11-06 11:56:18 EST
The handling in gconftool-2 was not working for me; on investigation
it turned out to be a bug/misfeature in killall, see bug 214214.

If bug 214214 isn't fixed, replacing 'killall /usr/libexec/gconfd-2'
with 'killall gconfd-2' would be advised.
Comment 15 David Eisenstein 2007-01-07 06:18:01 EST
So does rstrode's fix of 6-Nov-2006 (e.g.,
fix this problem?  Or is it still a bug?
Comment 16 Ray Strode [halfline] 2007-01-08 18:05:47 EST
It's fixed, yea, thanks.

Note You need to log in before you can comment on or make changes to this bug.