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

Re: gconf / orbit rc

Why was this such a problem? Couldn't gconf override the lock if the
associated process can no longer be reached?

On Thu, 2004-03-18 at 01:44, Ross Burton wrote:
> On Wed, 2004-03-17 at 23:59, Jerry Haltom wrote:
> > orbit allows one to use TCP to locate remote services, as opposed to
> > just a local socket. This is wonderful for NFS mounted home directories
> > with gconf. Gconf used to use this feature by saving the remote address
> > of the gconf instance in ~/.gconfd. That way all shared computers would
> > have the information to contact, remotely, the currently running gconf
> > instance. However, gconf has apparently moved this file into
> > /tmp/gconfd-$user. This has caused it to no longer function, since /tmp
> > is not shared. So, basically, Gconf has broken the TCP functionality of
> > Orbit. :)
> I knew not updating the GConf README like I promised would bite me in
> the arse at some point.
> Executive Summary:
> GConf 2.0 and 2.2 used locks in $HOME by default. This allowed NFS
> people to turn on ORBit's IP support and get remote GConf.  However, it
> also broke in many interesting ways for people whose desktop had just
> crashed.
> GConf 2.4 onwards reverses this.  By default lock files are stored in
> /tmp, and if you have NFS $HOME and wish to use remote GConf servers,
> you must disable this.  Configure ORBit to allow IP connections, and
> export GCONF_GLOBAL_LOCKS before starting GNOME.
> Honest, I will update the FAQ and commit it upstream.
> Ross

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: