From owner-freebsd-stable@FreeBSD.ORG Thu Mar 9 03:28:04 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2737716A420 for ; Thu, 9 Mar 2006 03:28:04 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3ABF43D46 for ; Thu, 9 Mar 2006 03:28:03 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id B24BD1A4D88; Wed, 8 Mar 2006 19:28:03 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8856952058; Wed, 8 Mar 2006 22:28:02 -0500 (EST) Date: Wed, 8 Mar 2006 22:28:02 -0500 From: Kris Kennaway To: Miguel Lopes Santos Ramos Message-ID: <20060309032802.GA57404@xor.obsecurity.org> References: <20060309022236.GA56614@xor.obsecurity.org> <200603090312.k293COR5004071@compaq.anjos.strangled.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <200603090312.k293COR5004071@compaq.anjos.strangled.net> User-Agent: Mutt/1.4.2.1i Cc: kuriyama@imgsrc.co.jp, freebsd-stable@freebsd.org, kris@obsecurity.org Subject: Re: rpc.lockd brokenness (2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2006 03:28:04 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 09, 2006 at 03:12:24AM +0000, Miguel Lopes Santos Ramos wrote: > > From: Kris Kennaway > > Subject: Re: rpc.lockd brokenness (2) > > > > Yeah, the file is still locked on the server, and will never be > > unlocked unless you stop and restart the rpc.lockd on the server > > (which releases all the locks it holds). >=20 > I did that. Lots of times. And I removed /var/db/statd.status too when > the daemons where not running. > Is there any other file involved? No: the locks are all held by the rpc.lockd process on the server, so when that process is killed they are released (you can verify this by running lockf on a locked file on the server before and after the rpc.lockd is killed). It does seem to take a few minutes for rpc.lockd on the client to notice when rpc.lockd is restarted on the server, but lockf -t 0 on the client will eventually succeed in my tests. I didn't need to stop/restart rpc.statd for it to recover state. > No. > There is a problem with rpc.lockd besides the other one. > This machine hangs even when I lock files with lockf -t 0 that never exis= ted, > with fresh statd/lockd on client AND server (if /var/db/statd.status is > the only file involved). lockf -t 0 is working for me when rpc.lockd is running. It hangs when the server is unreachable (e.g. rpc.lockd not running on the server) or for a few minutes after it is (re)started (I filed a PR about that too). Can you try to narrow down this problem some more? e.g. look up the port used by rpc.lockd with rpcinfo on client and server and tcpdump to see what locking requests are being passed back and forth (you should see the request from client -> server and the reply granting the lock; or not if something is going wrong). The ethereal port is useful for parsing the tcpdump -w -s 0 traces, btw; it decodes the RPC packets into human-readable form. Running rpc.lockd -d100 on the server is also useful for tracking down what it's doing (look in /var/log/debug.log) > If I keep using a common home directory for all machines, and keep using > lockd for that mount on that machine, then my only workaround is still to > go back to 6.0-RELEASE. I'm not certain 6.0-RELEASE is any different, since I don't see any changes to rpc.lockd or nfs locking that were made since then. > BTW, thank you for your support. And they talk about technical support on > fatly payed operating systems... You're welcome. Kris --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (FreeBSD) iD8DBQFED6DCWry0BWjoQKURAomVAJ0fYX15pY3G7jhPzoQ9LD95FU614wCdFRQl u8z5DHDuHMNCAkSlNWBf31o= =G03x -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd--