GConf error

Toshio Kuratomi a.badger at gmail.com
Fri May 7 17:17:55 UTC 2010


On Fri, May 07, 2010 at 12:15:20PM -0400, Colin Walters wrote:
> On Fri, May 7, 2010 at 12:05 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> > On Fri, May 07, 2010 at 09:38:45AM -0400, Colin Walters wrote:
> >> On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves <pingou at pingoured.fr> wrote:
> >> >
> >> > Would it be allowed to try to restart gconfd ?
> >>
> >> It would make sense to SIGHUP gconfd after new schemas are installed,
> >> yes.  Note though we should really only be doing this once at the end
> >> of a transaction when installation is complete.
> >>
> > My understanding was that with current Fedoras, gconf doesn't need this but
> > I could be misremembering, missing a corner case, or just wrong :-)
> 
> [walters at pocket gconf (master)]$ git grep inotify
> [walters at pocket gconf (master)]$ git grep g_file_monitor
> [walters at pocket gconf (master)]$
> 
> So...
> 
It's in gconftool.c:

Running makefile-install-schema and makefile-uninstall-schema eventually
calls do_sync() which was supposed to reread the schemas.  That's currently
calling gconf_engine_suggest_sync() in gconf.c and I'm not sure whether
there's some logic in there that could cause it not to suggest syncing in
our current setup.

Here's our bug where it was implemented but the code has changed since then:
  https://bugzilla.redhat.com/show_bug.cgi?id=173869

Possibly a regression?

> > We can't do this only once at the end of a transaction but if I'm
> > remembering a different discussion, doing it multiple times at the end
> > of the rpm transaction should be almost as good (since gconf will wait for
> > a few moments from getting the first SIGHUP to see if it will get any other
> > ones.)  Is that correct?
> 
> It has a 30 second timer currently for "periodic cleanup", and SIGHUP
> just sets a flag that that function reads.

<nod>

So changing policy back to doing a killall -HUP in %posttrans should work.
It would be nice to know what Fedora versions are affected by this and
whether it will someday be fixed before updating the Guidelines, though.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100507/8fd379b6/attachment-0001.bin 


More information about the devel mailing list