Bug 64757 - Odd GConf "informative message" b/c of NFS locking issue
Odd GConf "informative message" b/c of NFS locking issue
Status: CLOSED DUPLICATE of bug 59245
Product: Red Hat Linux
Classification: Retired
Component: GConf (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-10 12:05 EDT by JLapham
Modified: 2007-04-18 12:42 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-05-10 17:54:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description JLapham 2002-05-10 12:05:09 EDT
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.
Comment 1 Havoc Pennington 2002-05-10 15:12:16 EDT
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.

Comment 2 JLapham 2002-05-10 15:33:45 EDT
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.
Comment 3 Havoc Pennington 2002-05-10 17:54:04 EDT
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.
Comment 4 Havoc Pennington 2002-07-06 19:00:46 EDT

*** This bug has been marked as a duplicate of 59245 ***
Comment 5 Stephen Tweedie 2002-11-11 17:22:02 EST
Should be fixed; test rpms for nfs-utils now in bugzilla #76065

Note You need to log in before you can comment on or make changes to this bug.