From owner-freebsd-net@FreeBSD.ORG Wed Jan 21 19:49:24 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7A211065720 for ; Wed, 21 Jan 2009 19:49:23 +0000 (UTC) (envelope-from msch@snafu.de) Received: from sour.ops.eusc.inter.net (sour.ops.eusc.inter.net [84.23.254.154]) by mx1.freebsd.org (Postfix) with ESMTP id 925BD8FC1A for ; Wed, 21 Jan 2009 19:49:23 +0000 (UTC) (envelope-from msch@snafu.de) X-Trace: 507c6d73636840736e6166752e64657c38372e3138372e3132352e32397c314c50 696d782d30303043716b2d35787c31323332353636323539 Received: from sour.ops.eusc.inter.net ([10.154.10.19] helo=localhost) by sour.ops.eusc.inter.net with esmtpa (Exim 4.69) id 1LPimx-000Cqk-5x for freebsd-net@freebsd.org; Wed, 21 Jan 2009 20:30:59 +0100 Message-Id: <5523A7AD-6A64-4A40-B46F-8208BEA87C0A@snafu.de> From: Matthias Schuendehuette To: freebsd-net@freebsd.org Content-Type: multipart/signed; boundary=Apple-Mail-2-855988622; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 21 Jan 2009 20:30:58 +0100 X-Mailer: Apple Mail (2.930.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: NFS-Locking problem with 6.4/7.1-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 19:49:27 -0000 --Apple-Mail-2-855988622 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, one of our FreeBSD-Servers is acting as NFS-Server for $HOME for approx. 50 HP-UX Workstations, since the WS itself and the disks in there become quite old in the meantime. That works quite good with FreeBSD 6.3-RELEASE-pxx but doesn't work with 6.4/7.1 any more. I looked with 'wireshark' on the problem and it seems to be a locking problen, probably related to PR 'kern/130628', but I'm not sure. Here what I know so far: Server-OS: FreeBSD 6.4-RELEASE/7.1-RELEASE (same problems) Workstation-OS: HP-UX 11iv1 (11.11) NFS-Version: V3/tcp or V3/udp (NFS-V2 works!) I found no records of the problem on the client side (HP-UX) whereas on FreeBSD 'rpc.lockd -d 3' produces the following entries in /var/log/messages: Jan 21 12:07:33 bsd1dw kernel: NLM: new host hp13 (sysid 5) Jan 21 12:07:33 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) Jan 21 12:07:53 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) Jan 21 12:08:13 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) Jan 21 12:08:32 bsd1dw kernel: nlm_do_lock(): caller_name = hp13 (sysid = 5) Jan 21 12:08:33 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) Jan 21 12:08:43 bsd1dw kernel: nlm_do_lock(): caller_name = hp13 (sysid = 5) Jan 21 12:08:53 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) Jan 21 12:09:03 bsd1dw kernel: nlm_do_lock(): caller_name = hp13 (sysid = 5) Jan 21 12:09:13 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) Jan 21 12:09:13 bsd1dw kernel: nlm_do_lock(): caller_name = hp13 (sysid = 5) Jan 21 12:09:23 bsd1dw kernel: nlm_do_lock(): caller_name = hp13 (sysid = 5) Jan 21 12:09:33 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) What happens is as follows: When logging in to an account with the home directory on the NFS- Server, the shell reads '.profile' and the tries to get a lock on '.sh_history'. From a FreeBSD 6.3 server the shell gets the lock whereas a 6.4/7.1 server replies with "V4 LOCK_RES Call NLM_FAILED". Of course the HP-UX shell assumes the file is already locked, waits some time and tries again. This game leads to a complete lock of the account... :-( This does not happen if commandline-history is disabled but nontheless it's an error anyway. I have recorded the network traffic for a NFSv2 session, a NFSv3/tcp session with a 6.3 server and a NFSv3/tcp session with a 7-STABLE server. If the wireshark dumps are of interest beyond of what I described here they are available on request. I hope my informations help those who are able to fix it... Matthew -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) --Apple-Mail-2-855988622--