Re: gconf + NFS =Problem ?!

[Havoc Pennington <hp redhat com>]

Thorsten Twellmann <ttwellma TechFak Uni-Bielefeld de> writes: 
> WHAT'S WRONG ?
> 

I'll append a bunch of stuff to try from the Galeon FAQ.

I bet file locking doesn't work in your home directory though. 
This could be a bug in either your NFS client or server machine.

Havoc

<li><a name="gconf">
<b>When I run Galeon I get a message about GConf not being configured
properly. How can I configure GConf?</b></a>

<p>First and foremost, be sure you have a new GConf (1.0.7 is the latest at
this writing) rather than an old one. In particular, 1.0.4 is too old and
causes problems.</p>

<p>If you do <tt>ps jaxwww | grep gconf</tt> and see two <tt>gconfd-1</tt>
processes, that's what's wrong; just kill them both and restart Galeon.
This problem has not been reported with GConf 1.0.7, only older
versions.</p>

<p>If you have trouble with 1.0.7, most likely it's because your home
directory is NFS-mounted and either your operating system doesn't support
locks in NFS directories or you have stuck locks due to a hard system
crash. Try <tt>rm -r ~/.gconf*/*lock</tt> if you are <b>sure</b> you have
no gconfd processes (for your login name) running on any machine using your
NFS home directory. If you nuke the lock when gconfd is running and bad
stuff happens, it's your own fault. ;-)</p>

<p>If you want to use GConf while logged in from two different machines,
sharing the same home directory, you must enable TCP/IP for ORBit by adding
the line <tt>ORBIIOPIPv4=1</tt> to <tt>/etc/orbitrc</tt> and restart
gconfd. You will need to do this on <b>both</b> machines; one machine will
contact the gconfd running on the other.  This setup is poorly tested but
should work.</p>

<p>It's possible schema installation failed when you installed Galeon, so
you can try reinstalling them as follows:</p>

<pre>
GCONF_CONFIG_SOURCE=`gconftool-1 --get-default-source`  \
gconftool-1 --makefile-install-rule /etc/gconf/schemas/galeon.schemas
</pre>

<p>Be sure your GConf config file is set up correctly by editing the
<tt>path</tt> file in the directory <tt>$sysconfdir/gconf/1</tt>.  A basic
configuration for the default backend would look like:</p>

<pre>
xml:readonly:/etc/gconf/gconf.xml.mandatory
include "$(HOME)/.gconf.path"
xml:readwrite:$(HOME)/.gconf
xml:readonly:/etc/gconf/gconf.xml.defaults
</pre>

<p>You can also take a look at <tt>$sysconfdir/gconf/1/path.example</tt>
and in most cases you can simply move it to
<tt>$sysconfdir/gconf/1/path</tt>.  Be sure that the path file can be read
by all users.</p>

<p>Ensure you have a <tt>$sysconfdir/gconf/gconf.xml.defaults</tt> dir set
up with the right permissions. In most cases you can run <tt>chmod -R 755
$sysconfdir/gconf/gconf.xml.defaults</tt>.</p>

<p><b>WARNING:</b> The GConf deamon makes heavy use of a cache so when
changing your setup you will probably need to restart it.</p>

<p>Be sure you have no applications depending on gconf running and then
run:</p>

<pre>
gconftool --shutdown
</pre>

<p>GConf will then restart when it is required.</p>

<p>If none of the above works, enable user syslogging and see if gconf is
logging any error messages. On Linux, to do this try adding this line to
<tt>/etc/syslog.conf</tt>:</p>

<pre>
user.*   /var/log/user
</pre>

<p>then run <tt>service syslog restart</tt>, reproduce your gconf problem, and
look in <tt>/var/log/user</tt> for messages. If gconf is failing to get a
lock then the issue is probably the NFS thing mentioned earlier.  Otherwise
maybe there are other informative error messages.</p>

<p>If you still can't figure it out, try mailing <a
href="mailto:gconf-list gnome org">gconf-list gnome org</a>, describing
what happened when you tried all of the above and what version of gconf you
have, what exact error messages you get, etc.</p>
</li>