Composer failure ...



Hi guys,

	I'm still having repeated problems with Gconf / evolution, and it's
interaction with Gconf 2.0. Essentially - after a time of quiescence I
try to compose a message - and it fails to activate the composer. On
further investigation - this turns out to be that gconfd-2 can't be
contacted - and when re-started can't get the lock.

	The reason for this is that gconfd-2 is still running away merrily -
thinking it has /tmp/orbit-michael/linc-foo open and listening for
connections ( holding the XML tree lock ) But when you examine
/tmp/orbit-michael/linc-foo you discover that the (originally existing)
file has been unlinked somehow.

	When we ask for a new connection to gconf in a new app ( NB. existing
ones are prolly unaffected since they have live connections anyway ) we
have problems. Of course - this new app is typically the composer -
which will SEGV/ assert fail if it can't get gconf to work.

	So - the libgconf tries to contact the existing gconfd-2, can't find
the socket - fails, tries to start a new gconfd-2 which can't get the
lock. Thus we're totally foobaa'd.

	So ... we (I) badly need to find who is irresponsibly unlinking
/tmp/orbit-michael/linc-foo. Which is not altogether easy to do. I've
read the code in both ORBit1 and ORBit2 - and it looks ok:

	http://cvs.gnome.org/lxr/source/ORBit/src/IIOP/connection.c#763
vs.	http://cvs.gnome.org/lxr/source/linc/src/linc-server.c#78

	to no avail. Does anyone have any idea (short of strace 'world', wait
for hours) that I could work out who / how that file gets unlinked ?

	Thanks,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]