GConf error

Colin Walters walters at verbum.org
Sun May 9 15:56:27 UTC 2010

On Sat, May 8, 2010 at 2:22 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:

> I see that we're calling killall -TERM instead of killall -HUP in the patch.
> That seems non-optimal (since it means we'll keep shutting down the gconfd
> server instead of letting it use it's 30second timeout)

That's definitely suboptimal because we'll lose the caches etc. from
the running process.

> Anyone know why we haven't seen progress on the upstream bug?  No one's
> raised any philosophical blockers with doing this:
> http://bugzilla.gnome.org/show_bug.cgi?id=328697

I commented there.

> Colin, if no one's looking into fixing this bug there's two ways to
> workaround this bug:
> Change macros.gconf2 to run killall after the schemas are installed or
> uninstalled.  This requires an update of the GConf2 package.  We don't know
> which Fedora versions this affects yet (the guake update was for F13)

killall -TERM?

> Restore the packaging guideline suggestion to run killall -HUP gconfd-2
> Since we don't know which versions this affects, we'd need to recommend it
> on all Fedora releases.

I don't think that helps - the original problem report was failure on
initial install + run, which I believe must be a result of the 30
second delay in gconfd from SIGHUP.

What do you think about my comment here?


If we can't get the changes to RPM made to do it once
post-transaction, then I suggest we simply bite the bullet and remove
the 30 second timeout from gconfd until such time as the RPM change
can be made.  I'll take "slower without race conditions" over "faster
but racy".

More information about the devel mailing list