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

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.
Thanks!
-Garrett