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

[Daichi GOTO]

On Oct 5, 2010, at 7:09 PM, Garrett Cooper wrote:
> On Tue, Oct 5, 2010 at 8:58 AM, Garrett Cooper <gcooper at freebsd.org> wrote:
>> On Tue, Oct 5, 2010 at 7:52 AM, Garrett Cooper <gcooper at freebsd.org> wrote:
>>> On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO <daichi at ongs.co.jp> wrote:
>>>> On Tue, 5 Oct 2010 01:23:02 -0700
>>>> Garrett Cooper <gcooper at FreeBSD.org> wrote:
>>>>> 2010/10/4 Daichi GOTO <daichi at ongs.co.jp>:
>>>>>> Thanks nice test tool :)  And at last I got it excepting one mystery!
>>>>>> 
>>>>>> On Mon, 4 Oct 2010 20:17:08 -0700
>>>>>> Garrett Cooper <gcooper at FreeBSD.org> wrote:
>>>>>>> Following through the same process on FreeBSD...
>>>>>>> 
>>>>>>> Window 1:
>>>>>>> $ ls -l /tmp/lockfile
>>>>>>> ls: /tmp/lockfile: No such file or directory
>>>>>>> $ ./test_fcntl
>>>>>>> 
>>>>>>> Window 2:
>>>>>>> 
>>>>>>> $ ls -l /tmp/lockfile
>>>>>>> -rwsr-x---  1 garrcoop  wheel  0 Oct  4 20:14 /tmp/lockfile
>>>>>>> $ ./test_fcntl
>>>>>>> test_fcntl: fcntl: Resource temporarily unavailable
>>>>>> 
>>>>>> Just my mystery is as follow:
>>>>>> 
>>>>>> Windows 1:
>>>>>> % ./test_fcntl
>>>>>> My pid: 43490
>>>>>> 
>>>>>> Windows 2:
>>>>>> % ls -l /tmp/lockfile
>>>>>> -r-sr-x---  1 daichi  wheel  0 10月  5 15:02 /tmp/lockfile    <--- is it weird, isn't it?
>>>>>> % ./test_fcntl
>>>>>> test_fcntl: open: Permission denied
>>>>>> %
>>>>>> 
>>>>>> Oops... What's wrong... /tmp is as follow:
>>>>>> 
>>>>>> % mount | grep tmp
>>>>>> /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates)
>>>>>> % dumpfs /tmp | grep journal
>>>>>> flags   soft-updates+journal
>>>>>> %
>>>>>> 
>>>>>> And working scene:
>>>>>> 
>>>>>> Windows 2:
>>>>>> % chmod u+w /tmp/lockfile
>>>>>> % ls -l /tmp/lockfile
>>>>>> -rwsr-x---  1 daichi  wheel  0 10月  5 15:22 /tmp/lockfile
>>>>>> % ./test_fcntl
>>>>>> My pid: 43646
>>>>>> test_fcntl: fcntl[1]: Resource temporarily unavailable
>>>>>> PID=43490 has the lock
>>>>>> %
>>>>> 
>>>>> What's your umask and what are the permissions on /tmp?
>>>> 
>>>> % ll / | grep tmp
>>>> drwxrwxrwt  14 root  wheel      1024 10月  5 17:19 tmp
>>>> % umask
>>>> 022
>>>> % rm -f test
>>>> % touch test
>>>> % ll | grep test
>>>> -rw-r--r--   1 daichi  wheel     0 10月  5 17:52 test
>>>> %
>>> 
>>>    The permissions look ok from my perspective, but the umask is
>>> different, so you might want to try my umask to make sure that your
>>> results match mine (and we need to check the requirements to determine
>>> whether or not the behavior for FreeBSD's umask syscall is correct):
>>> 
>>> $ ls -la /tmp/ | head -n 2
>>> total 462686
>>> drwxrwxrwt  51 root     wheel         11776 Oct  5 03:11 .
>>> $ umask
>>> 0022
>>> 
>>>    Where and how is /tmp mounted (is it a real partition, what
>>> filesystem, etc)?
>>>    BTW, when I change my umask to match your's I don't get the same
>>> results you do on my home machine:
>>> 
>>> Window 1:
>>> 
>>> $ umask 022
>>> $ ./test_fcntl
>>> My pid: 17353
>>> 
>>> Window 2:
>>> 
>>> $ ./test_fcntl
>>> My pid: 17356
>>> test_fcntl: fcntl[1]: Resource temporarily unavailable
>>> PID=17353 has the lock
>>> $ ls -l /tmp/lockfile
>>> -rwSr-----  1 gcooper  wheel  0 Oct  5 07:49 /tmp/lockfile
>>> 
>>>    Just to note, the tests before were run on the RHEL 4.8 box with
>>> the following info, and the FreeBSD box with the following info:
>>> 
>>> Red Hat Enterprise Linux AS release 4 (Nahant Update 8)
>>> Linux sjc-lds-102 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT
>>> 2009 x86_64 x86_64 x86_64 GNU/Linux
>>> 
>>> FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1
>>> r211767M: Sat Aug 28 00:28:45 PDT 2010
>>> garrcoop at bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK  amd64
>>> 
>>>    The tests above were run on a FreeBSD box with the following info:
>>> 
>>> 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
>>> 
>>>    On bayonetta /tmp is SUJ backed (probably should change that
>>> though), and on bioshock it's not SUJ backed.
>> 
>> And while this might be a good mental exercise, I think we're missing
>> the original point of your bug:
>> 
>> You were getting ECONNREFUSED because a socket was in `use', even
>> though all instances of mozc_server were dead (at least that's the
>> case with me). So the question I guess that's worth asking is:
> 
> Statement incorrect: socket wasn't in use. The logic needs to be
> rewritten to account for this case and setup the socket again if this
> occurs. It would be a good idea to do this if the file wasn't locked.

Maybe behavior difference of fcntl when called with F_SETLN or F_GETLN 
you found is the answer of this issue. I'll try to check it out. Thanks!

And I'll try to treat correct l_pid when called with F_SETLN.  I guess this change
will be benefits for other applications that use fcntl(2) like mozc_server does.

>> 1. What process/application does it need to establish a Unix style socket with?
>> 2. Why isn't that socket being cleaned up by the OS at exit?
> 
> Thanks!
> -Garrett
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"