Date: Tue, 5 Oct 2010 09:38:26 +0900 From: Daichi GOTO <daichi@ongs.co.jp> To: Garrett Cooper <gcooper@FreeBSD.org> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 Message-ID: <20101005093826.17432b1e.daichi@ongs.co.jp> In-Reply-To: <AANLkTimVcLVdULyAAJD-_TaC5OLj%2BaZVNa=%2BSaiN6PKv@mail.gmail.com> References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <AANLkTinZg3n3wDUzQFPv_Gq1o2hswGL3%2B4o0brmTi0-h@mail.gmail.com> <20101004144927.36822f07.daichi@ongs.co.jp> <AANLkTimVcLVdULyAAJD-_TaC5OLj%2BaZVNa=%2BSaiN6PKv@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 4 Oct 2010 07:19:45 -0700
Garrett Cooper <gcooper@FreeBSD.org> 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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101005093826.17432b1e.daichi>