From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 Description of problem: When loggin into a RH73 machine, using NFS mounted home directories, some users are seeing the following message: GConf error: Configuration server couldn't be contacted: Adding client to server's list failed, CORBA error: IDL: CORBA/COMM_FAILURE: 1.0 All further errors shown only on terminal. Checking /var/log/messages shows: May 10 10:14:04 exdev gconfd (cris-2759): starting (version 1.0.9), pid 2759 user 'cris' May 10 10:14:04 exdev gconfd (cris-2759): Failed to get lock for daemon, exiting: Failed to lock '/home/cris/.gconfd/lock/ior': probably another process has the lock, or your operating system has NFS file locking misconfigured, or a hard NFS client crash caused a stale lock (Resource temporarily unavailable) - run gconf-sanity-check-1 for possible diagnosis, see http://www.gnome.org/projects/gconf/ for more information Running "gconf-sanity-check-1" gives: cris@exdev > gconf-sanity-check-1 Please contact your system administrator to resolve the following problem: Failed to get a file lock: Failed to lock '/home/cris/.gconfd/lock/ior': probably another process has the lock, or your operating system has NFS file locking misconfigured, or a hard NFS client crash caused a stale lock (Resource temporarily unavailable) - run gconf-sanity-check-1 for possible diagnosis, see http://www.gnome.org/projects/gconf/ for more information The NFS server is a RH72 machine. The client machines (where this error is coming from) are mounting the user directories thusly: [root@exdev etc]# cat auto.home # $Id: auto.misc,v 1.2 1997/10/06 21:52:04 hpa Exp $ # This is an automounter map and it has the following format # key [ -mount-options-separated-by-comma ] location # Details may be found in the autofs(5) manpage * -fstype=nfs,rw,hard,intr,rsize=8192,wsize=8192 office:/home/& Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: I do not know how to make this occur reproducibly. It always happens for some users, and never does for others.
This isn't a GConf crash btw, it's an informative GConf error message. ;-) Anyway, the problem is probably that a lock got stuck because a machine crashed (bug #59245), or that users are trying to log in twice and you need to enable TCP/IP between the machines. I realize TCP/IP connections are suboptimal, but that's an architectural change it will take time to fix. See http://www.gnome.org/projects/gconf for more details.
Okay, thanks for the comments. If I read the GConf web page correctly, simply upgrading my NFS server from RH7.2 to RH7.3 should fix this problem? (it is currently a RH7.2 box). Was GConf not used (or somehow setup differently) in RH7.2? I ask because we never saw this before upgrading our workstations to RH7.3.
No, 7.2 NFS server should work fine. Bug #59245 is unfortunately still in 7.3, but it's a client issue probably. In 7.2 GConf had locking that did not work reliably, resulting in lost settings and things. Now it uses kernel locking, which causes this issue due to the nfs-utils bug #59245, and occasionally because someone isn't running rpc.statd/rpc.lockd services.
*** This bug has been marked as a duplicate of 59245 ***
Should be fixed; test rpms for nfs-utils now in bugzilla #76065