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

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:

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