From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 00:38:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45DED10656A6; Tue, 5 Oct 2010 00:38:29 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id CB97A8FC0C; Tue, 5 Oct 2010 00:38:28 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 82BE112543B; Tue, 5 Oct 2010 09:38:26 +0900 (JST) Date: Tue, 5 Oct 2010 09:38:26 +0900 From: Daichi GOTO To: Garrett Cooper Message-Id: <20101005093826.17432b1e.daichi@ongs.co.jp> In-Reply-To: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> Organization: ONGS Inc. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 05 Oct 2010 00:38:29 -0000 On Mon, 4 Oct 2010 07:19:45 -0700 Garrett Cooper wrote: > >> issues that might be occurring with the software, as per my copy of > >> SUSv4 (see the ERRORS section of fcntl). I would print out the > >> strerror for that case. > >>     Providing a backtrace of the application's execution and the > >> architecture and what version of FreeBSD you're using would be > >> helpful. > > I'm not even getting that far. Logs attached from both runs > (WITH_DEBUG_CODE and WITHOUT_DEBUG_CODE). Yeah, it looks like the same situation. 1) mozc_server was killed lock file remains (even though it should be removed) 2) mozc_server try to boot 1. check lock file there 2. there is lock file, so cannot get lock file via fcntl 3. lock file means there is another mozc_server running, so mozc_server will stop boot and finish The cause of problem is that kernel does not remove lock file after mozc_server killed. Mozc developer explained me that fcntl will remove lock file after that process killed. But it looks like fnctl() does not remove lock file itself. According to FreeBSD fcntl(2) manual: All locks associated with a file for a given process are removed when the process terminates. No explanation lock file removing. Does FreeBSD fnctl(2) not remove lock file after process killed? Apparently from Mozc developer, Linux kernel removes lock files after process killed. > $ uname -a > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: > Thu Aug 19 22:50:36 PDT 2010 > root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > I completely blasted past the part of your reply above where you > said your home directory is served up via NFS. It might be a problem > if you don't have lockd running (/etc/rc.d/lockd onestatus ? It isn't > enabled by default, and definitely isn't on on my machine) or the > mount isn't setup with lockd on the client side (nolockd will do this > on the initial mount, according to the manpage). There might be > `dragons' in the nfsd code that fail to do locking properly, but I > think that Rick (rmacklem@) or someone else on the list might be > better at answering whether or not things work from an NFS > perspective. server side: FreeBSD 7.3-PRERELEASE #0: Mon Mar 1 15:10:07 JST 2010 i386 rc.conf nfs_server_enable="YES" mountd_enable="YES" nfs_reserved_port_only="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" client side: FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010 amd64 rc.conf: nfs_client_enable="YES" nfs_reserved_port_only="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" > I'd definitely divulge which version of NFS you're using as well > as what your NFS server and client are running if enabling lockd both > client and server side doesn't solve your problems right away. > Cheers, > -Garrett I have tested with ZFS because I was doubting NFS working well, but result was the same. (I didn't test with UFS.) Thanks truss output!