GConf error

[Toshio Kuratomi]

On Sun, May 09, 2010 at 11:56:27AM -0400, Colin Walters wrote:
> 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?
> 
killall -HUP

> > 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.
> 

I'm a bit unclear on the original problem report, actually.  In addition to
what you've said, the report also says that the user had to logout and log
back in before it worked.  That seems like a different symptom.  30 seconds
is not that long so I would expect that just starting application from the
menu, reading failure message, trying to start the application from menu
a second time would be enough time...

Also, I'm unclear if simply adding killall -HUP to the guake scriptlets
fixed the problem (or if something else about the install transactions were
different).  If that's all it took, then that also points at something other
than the 30 second timeout being the issue.

Are we able to reproduce the original reporter's issue?

> What do you think about my comment here?
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=328697#c9
> 
> 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".

Note: %posttransaction would allow us to group all of the SIGHUPs in
a closer timespan (we'd run all of the sighups [and other posttransactions]
at the end of the rpm transaction).  So perhaps having::

  gconftool-2 --makefile-(un)install-rule --delay-sighup=$SECONDS

in the general case would work.  We could specify delay-sighup as 5 seconds
or so in the gconf macros.  I also realized that in the unlikely case
that something is run in a %post transaction needs to use something that was
installed, we'd need to sighup gconf in %post with no delay... that'll be
tricky since the sighup should really go in the package providing the tool
but we will get the problem reports in the package depending on the tool.

On the speed front:
1) Using %posttransaction even without the delay could be faster due to fs
caching -- we won't have clobbered that by doing a few package installs
between gconf sighups.

2) The new gconf macros are more intelligent than the old scripts -- they
don't run if the schemas are unchanged.  That might take some of the sting
out of gconf reloading schemas more frequently again.

3) mclasen performed some optimization of gconf itself recently... I don't
know precisely how that affects the original rationale for the delay.

You'll need to flag down panu or ffesti to see if 'do-this-action-once' is
something they're planning for an upcoming rpm release (and we'll still have
to document in guidelines what to do until then).

-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/20100509/2c500cf2/attachment.bin