fcntl always fails to delete lock file, and PID is always -6464
Daichi GOTO
daichi at ongs.co.jp
Thu Oct 7 14:27:10 UTC 2010
On Oct 5, 2010, at 4:52 PM, Garrett Cooper 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
The results are different on some users, even on the same user!
(022 and 0022 shows the same results.)
test user:
$ rm -f /tmp/lockfile
$ ./test_fcntl
My pid: 63133
^C
$ ll /tmp/lockfile
---sr----- 1 test wheel - 0 Oct 7 23:16 /tmp/lockfile*
$
daichi:
% rm -f /tmp/lockfile
% ./test_fcntl
My pid: 63140
^C
% ll /tmp/lockfile
---Sr-x--- 1 daichi wheel 0 10月 7 23:17 /tmp/lockfile
%
But above daichi's result was ---sr----- as the same as test user.
After some operation, it turns into returing ---Sr-x---. I didn't remember
what operation did that.
root:
# rm -f /tmp/lockfile
# ./test_fcntl
My pid: 63147
^C
# ls -l /tmp/lockfile
--wSr-S--- 1 root wheel 0 Oct 7 23:20 /tmp/lockfile
#
It is mystery.
> Where and how is /tmp mounted (is it a real partition, what
> filesystem, etc)?
UFS+SUJ+noatime real pertition. I checked atime version, and got the same
result.
> 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
Still now, I couldn't find the cause of this issue, but it's ok by code following,
and program should set permission at creating time I guess.
fd = open("/tmp/lockfile", O_CREAT|O_WRONLY,0600);
> _______________________________________________
> 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"
More information about the freebsd-current
mailing list