For some time I’ve been having issues with GConf (part of the GNOME suite) and locking. Although I don’t use a GNOME desktop, a number of applications have support for GNOME and need to interact with GConf, which is used to store application preferences.

In my environment I have a home directory that is exported via NFS from a server, running Debian GNU/Linux, to various clients, running a mixture of operating systems. GConf, being an application that needs to accept configuration updates from a number of applications running concurrently, needs to lock its data files, which are stored in a user’s home directory. Of course, having an NFS mounted home directory tends to complicate things, particularly because NetBSD doesn’t support NFS locking. The nasty thing is that when GConf cannot lock a file, it just blocks indefinitely, waiting to obtain the lock. As you can imagine, any application using GConf hangs while GConf waits for the lock to succeed. Great design…

It’s taken me quite a lot of fiddling, but I seem to have found a workable solution to this annoyance. The key is to get GConf to lock to a local filesystem, rather than to one mounted via NFS. To do this, set GCONF_LOCAL_LOCKS=1 in the appropriate shell rc file. When using local locking, GConf creates lock files in /var/tmp/gconfd-$USER instead of ~/.gconfd.

Sheesh, why can’t it do this automagically?