Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 103001 - GConf1 needs to be updated to use local locks
Summary: GConf1 needs to be updated to use local locks
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: GConf
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: CambridgeBlocker
TreeView+ depends on / blocked
 
Reported: 2003-08-25 02:08 UTC by Rob Hughes
Modified: 2008-04-23 05:34 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-04-23 05:34:59 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Rob Hughes 2003-08-25 02:08:47 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
After an update to GConf2 and -devel from rawhide, I'm unable to start any GConf
dependent app. Running oaf-slay and bonobo-slay, then cleaning up the leftover
locks worked once, but since then, I'm unable to start, for example, evolution,
grcm, etc. I attempted to run some of these from a shell directly to get some
error output, but other than the app hanging, there isn't any. I've also tried
using the GCONF_LOCAL_LOCKS trick, as well as running various programs as a
local user. The result is the same each time. I'm running RH9 + various updates
from rawhide.

Version-Release number of selected component (if applicable):
GConf2-2.3.3-2

How reproducible:
Always

Steps to Reproduce:
1. Update to GConf2-2.3.3-2 from rawhide
2. Try to start evolution
3. Observe hangs and stale lock files after killing app.
    

Actual Results:  The app fails to start

Expected Results:  The app starts.

Additional info:

When I first started, I got an error indicating an error regarding a socket was
seen, but I've been unable to reproduce this and failed to record it. I do,
however, see a number of gconfd-2 processes left over after anything is run that
uses gcond2/CORBA.
Comment 1 Rob Hughes 2003-08-25 03:37:32 UTC 
I went digging through my logs, and found the error I referred to earlier:

gconfd (rob-5971): Failed to send buffer

Looks like it's having a problem with sockets or something.
Comment 2 Alexander Larsson 2003-08-27 10:08:39 UTC 
Did you also update ORBit2 and bonobo?
Comment 3 Rob Hughes 2003-08-27 11:31:05 UTC 
Here are my versions:
bonobo-1.0.22-7
bonobo-devel-1.0.22-7
libbonobo-devel-2.3.6-2
libbonoboui-2.3.6-2
libbonoboui-devel-2.3.6-2
bonobo-conf-0.16-5
bonobo-conf-devel-0.16-5
libbonobo-2.3.6-2
ORBit-0.5.17-10.3
ORBit-devel-0.5.17-10.3
ORBit2-2.7.5-5
ORBit2-devel-2.7.5-5

I believe these are all the current versions from rawhide.
Comment 4 Rob Hughes 2003-09-09 03:28:10 UTC 
I went back, ripped out evolution, gconf, and all the bonobo stuff, removed
every trace of anything that looked like a pipe and reinstalled. Other than not
being able to exit evolution (I have to do a killev) and links failing to launch
the associated app, everything seems to be working.
Comment 5 Alexander Larsson 2003-09-10 13:01:06 UTC 
Very strange. Its possible that GConf had problems with earlier versions of
ORBit, but I have no idea what caused persistant problems like this.
Comment 6 Havoc Pennington 2003-10-04 05:45:45 UTC 
doesn't allow gconf _1_ apps to start, no?

gconf1 needs to default to local locks now...
Comment 7 Rob Hughes 2003-10-04 12:12:41 UTC 
I had updated both gconf1 and gconf2. The list of apps included evolution and
grcm. Are those both gconf1 apps? I though evolution used gconf2.
Comment 8 Havoc Pennington 2003-10-04 16:41:27 UTC 
Depends on the version of evolution, 1.2 uses gconf1, 1.4 gconf2.

I know gconf 1 apps are broken, anyhow. If gconf 2 apps are broken it's some odd
orbit thing probably, gconf 1 is more complicated.
Comment 9 Mark McLoughlin 2004-07-28 06:37:26 UTC 
Okay, status seems to be:

  GConf2 has been changed to keep its locks in /tmp rather than
  in $HOME. GConf1 hasn't been updated to use local locks so
  now if you have gconfd-2 running and you do

    $> gconftool-1 -R /tmp

  then gconfd-1 gets activated rather. Broken.
Comment 10 Matthias Clasen 2008-03-26 16:10:52 UTC 
I don't think GConf 1 bugs are worth keeping open at this point.
Note You need to log in before you can comment on or make changes to this bug.