fcntl always fails to delete lock file, and PID is always -6464
Garrett Cooper
gcooper at FreeBSD.org
Mon Oct 4 05:08:32 UTC 2010
On Sun, Oct 3, 2010 at 10:05 PM, 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
> 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.
> Thanks,
> -Garrett
>
> PS Quickly looking over this code, it has portability issues assuming
> that all Unix based OSes (that aren't under some Mac OSX guard) are
> Linux, based on the number of /proc filesystem opens and reads I see
> in the code.
Sorry... missed some of the details in spite of the trees (FreeBSD
version in particular).
Thanks,
-Garrett
More information about the freebsd-current
mailing list