Re: fcntl always fails to delete lock file, and PID is always -6464

On Sun, Oct 3, 2010 at 10:49 PM, Daichi GOTO <daichi_at_ongs.co.jp> wrote:
> On Sun, 3 Oct 2010 22:05:12 -0700
> Garrett Cooper <gcooper_at_FreeBSD.org> wrote:
>> On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO <daichi_at_ongs.co.jp> wrote:
>> > It looks very strange. fcntl() always fails to delete lock file
>> > and command.l_pid is always -6464. This issue is disclosed in
>> > porting Google's Japanese input system called "mozc".
>> >
>> >  details follow:
>> >    http://code.google.com/p/mozc/issues/detail?id=40
>> >
>> > % uname -a
>> > FreeBSD parancell.ongs.co.jp 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010     root_at_parancell.ongs.co.jp:/usr/obj/usr/src/sys/PARANCELL  amd64
>> > %
>> >
>> > My home directory on NFS server.  Does anyone have any ideas?
>>
>>
>>     I see some bad assumptions in the code:
>>
>>     const int result = ::fcntl(*fd, F_SETLK, &command);
>>     if (-1 == result) {  // failed
>>       ::close(*fd);
>>       LOG(WARNING) << "already locked";
>>       return false;   // another server is already running
>>     }
>>
>>     If the developer actually coded to POSIX expectations, he/she
>> would be checking for EACCES/EAGAIN; there are a myriad of other
>
> It was EAGAIN, when I checked.  And -6464 is very strange....
> It should be -1 when it fails with EGAIN according to FreeBSD
> fcntl(2) manual.
>
> Repeat is easy:
>  # cd /usr/ports/japanese/mozc-server/
>  # rm files/patch-server_mozc_server.cc
>  # make WITH_DEBUG_CODE=yes install clean
>
>  % mozc_server
>  ^C    --> in this timing, lock files should be deleted, but not working.
>  % mozc_server  --> so server will not run and finish soon
>  %
>
>  % cat ~/.mozc/mozc_server.log
>
>> 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).

$ uname -a
FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M:
Thu Aug 19 22:50:36 PDT 2010
root_at_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_at_) or someone else on the list might be
better at answering whether or not things work from an NFS
perspective.
    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