From owner-freebsd-current@FreeBSD.ORG Fri Jun 27 06:27:44 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97AD137B401 for ; Fri, 27 Jun 2003 06:27:44 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE6ED43FF3 for ; Fri, 27 Jun 2003 06:27:43 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h5RDRGKJ072462; Fri, 27 Jun 2003 09:27:16 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h5RDRGJu072459; Fri, 27 Jun 2003 09:27:16 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 27 Jun 2003 09:27:15 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mark Hannon In-Reply-To: <20030627083109.GA31566@doorway.home.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: 5.1 NFS locking problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 13:27:44 -0000 On Fri, 27 Jun 2003, Mark Hannon wrote: > I have two 5.1-RELEASE boxes with an NFS locking problem. One box is > the NFS server and the other the client. When attempting to login via > gdm I get: > > messages:Jun 27 18:09:07 tbird gconfd (mark-2316): Failed to get lock > for daemon, exiting: Failed to lock '/home/mark/.gconfd/lock/ior': > probably another process has the lock, or your operating system has NFS > file locking misconfigured (Resource temporarily unavailable) > > rpc.statd and rpc.lockd are running on both the server and client. > > Any ideas how to trace? The first thing I'd probably do is ktrace gdm (make sure to use the descend flag) and see what the system call and arguments are that generate this error. Generally, locks are asserted using one of the following system calls: open() with a lock flag, flock(), or fcntl(). Grep the ktrace output looking for the return of EAGAIN. Off the top of my head, the most likely source of EAGAIN is open() with the O_NONBLOCK flag set, which indicates that the caller doesn't want to wait for the lock to become available if the lock is contended. In which ase it sounds like it's an application "feature" (hence the message reading "probably another process has the lock...", which sounds right). You can use: http://www.watson.org/~robert/freebsd/locktest.c to test lock contention and servicing; it's basically a wrapper around open() and flock() so you can easily specify various cases, sock as O_NONBLOCK, etc, to try to reproduce the exact arguments and flags you see in the ktrace. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories