Re: fcntl always fails to delete lock file, and PID is always -6464
On Tuesday, October 05, 2010 2:39:26 am Daichi GOTO wrote: Next step discussion engaged from this research I guess. Should we do change FreeBSD's fcntl(2) to return correct l_pid when called with F_SETLK? Or keep current behavior?? I want to hear other developers ideas and suggetions. POSIX doesn't say that F_SETLK returns a valid l_pid, so I think FreeBSD's current behavior is fine. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
Sent from my iPad On Oct 11, 2010, at 5:50 PM, John Baldwin j...@freebsd.org wrote: On Tuesday, October 05, 2010 2:39:26 am Daichi GOTO wrote: Next step discussion engaged from this research I guess. Should we do change FreeBSD's fcntl(2) to return correct l_pid when called with F_SETLK? Or keep current behavior?? I want to hear other developers ideas and suggetions. POSIX doesn't say that F_SETLK returns a valid l_pid, so I think FreeBSD's current behavior is fine. Yes, I agree. POSIX says so. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
On Oct 5, 2010, at 4:52 PM, Garrett Cooper wrote: On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO dai...@ongs.co.jp wrote: On Tue, 5 Oct 2010 01:23:02 -0700 Garrett Cooper gcoo...@freebsd.org wrote: 2010/10/4 Daichi GOTO dai...@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 gcoo...@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 garrc...@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 r...@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
On Oct 5, 2010, at 7:09 PM, Garrett Cooper wrote: On Tue, Oct 5, 2010 at 8:58 AM, Garrett Cooper gcoo...@freebsd.org wrote: On Tue, Oct 5, 2010 at 7:52 AM, Garrett Cooper gcoo...@freebsd.org wrote: On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO dai...@ongs.co.jp wrote: On Tue, 5 Oct 2010 01:23:02 -0700 Garrett Cooper gcoo...@freebsd.org wrote: 2010/10/4 Daichi GOTO dai...@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 gcoo...@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 garrc...@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 r...@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
Thanks nice test tool :) And at last I got it excepting one mystery! On Mon, 4 Oct 2010 20:17:08 -0700 Garrett Cooper gcoo...@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 % -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
Next step discussion engaged from this research I guess. Should we do change FreeBSD's fcntl(2) to return correct l_pid when called with F_SETLK? Or keep current behavior?? I want to hear other developers ideas and suggetions. On Mon, 4 Oct 2010 20:17:08 -0700 Garrett Cooper gcoo...@freebsd.org wrote: test_fcntl: fcntl: Resource temporarily unavailable PID=1 has the lock Huh...? init has the file locked...? WTF?! So assuming Occam's Razor, I did a bit more reading and it turns out that l_pid is only populated when you call with F_GETLK: negative, l_start means end edge of the region. The l_pid and l_sysid fields are only used with F_GETLK to return the process ID of the process holding a blocking lock and the system ID of the system that owns that process. Locks created by the local system will have a system ID of zero. After a successful F_GETLK request, the value of l_whence is SEEK_SET. Thus, after fixing the test app I'm getting a sensical value: -- Daichi GOTO 81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
2010/10/4 Daichi GOTO dai...@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 gcoo...@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? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
On Tue, 5 Oct 2010 01:23:02 -0700 Garrett Cooper gcoo...@freebsd.org wrote: 2010/10/4 Daichi GOTO dai...@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 gcoo...@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 % ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO dai...@ongs.co.jp wrote: On Tue, 5 Oct 2010 01:23:02 -0700 Garrett Cooper gcoo...@freebsd.org wrote: 2010/10/4 Daichi GOTO dai...@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 gcoo...@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 garrc...@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 r...@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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
On Tue, Oct 5, 2010 at 7:52 AM, Garrett Cooper gcoo...@freebsd.org wrote: On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO dai...@ongs.co.jp wrote: On Tue, 5 Oct 2010 01:23:02 -0700 Garrett Cooper gcoo...@freebsd.org wrote: 2010/10/4 Daichi GOTO dai...@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 gcoo...@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 garrc...@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 r...@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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
On Tue, Oct 5, 2010 at 8:58 AM, Garrett Cooper gcoo...@freebsd.org wrote: On Tue, Oct 5, 2010 at 7:52 AM, Garrett Cooper gcoo...@freebsd.org wrote: On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO dai...@ongs.co.jp wrote: On Tue, 5 Oct 2010 01:23:02 -0700 Garrett Cooper gcoo...@freebsd.org wrote: 2010/10/4 Daichi GOTO dai...@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 gcoo...@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 garrc...@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 r...@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. 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
On Sun, 3 Oct 2010 22:05:12 -0700
Garrett Cooper gcoo...@freebsd.org wrote:
On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO dai...@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
r...@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
It was EAGAIN, when I checked. And -6464 is very strange
It should be -1 when it fails with EGAIN according to FreeBSD
fcntl(2) manual.
Repeat is easy:
# cd /usr/ports/japanese/mozc-server/
# rm files/patch-server_mozc_server.cc
# make WITH_DEBUG_CODE=yes install clean
% mozc_server
^C-- in this timing, lock files should be deleted, but not working.
% mozc_server -- so server will not run and finish soon
%
% cat ~/.mozc/mozc_server.log
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
--
Daichi GOTO
CEO | ONGS Inc.
81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp
LinkedIn: http://linkedin.com/in/daichigoto
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
On Sun, Oct 3, 2010 at 10:05 PM, Garrett Cooper gcoo...@freebsd.org wrote:
On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO dai...@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
r...@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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
On Sun, Oct 3, 2010 at 8:37 PM, Daichi GOTO dai...@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
r...@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.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
On Mon, 4 Oct 2010 07:19:45 -0700 Garrett Cooper gcoo...@freebsd.org wrote: 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. I'm not even getting that far. Logs attached from both runs (WITH_DEBUG_CODE and WITHOUT_DEBUG_CODE). Yeah, it looks like the same situation. 1) mozc_server was killed lock file remains (even though it should be removed) 2) mozc_server try to boot 1. check lock file there 2. there is lock file, so cannot get lock file via fcntl 3. lock file means there is another mozc_server running, so mozc_server will stop boot and finish The cause of problem is that kernel does not remove lock file after mozc_server killed. Mozc developer explained me that fcntl will remove lock file after that process killed. But it looks like fnctl() does not remove lock file itself. According to FreeBSD fcntl(2) manual: All locks associated with a file for a given process are removed when the process terminates. No explanation lock file removing. Does FreeBSD fnctl(2) not remove lock file after process killed? Apparently from Mozc developer, Linux kernel removes lock files after process killed. $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: Thu Aug 19 22:50:36 PDT 2010 r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 I completely blasted past the part of your reply above where you said your home directory is served up via NFS. It might be a problem if you don't have lockd running (/etc/rc.d/lockd onestatus ? It isn't enabled by default, and definitely isn't on on my machine) or the mount isn't setup with lockd on the client side (nolockd will do this on the initial mount, according to the manpage). There might be `dragons' in the nfsd code that fail to do locking properly, but I think that Rick (rmacklem@) or someone else on the list might be better at answering whether or not things work from an NFS perspective. server side: FreeBSD 7.3-PRERELEASE #0: Mon Mar 1 15:10:07 JST 2010 i386 rc.conf nfs_server_enable=YES mountd_enable=YES nfs_reserved_port_only=YES rpc_lockd_enable=YES rpc_statd_enable=YES client side: FreeBSD 9.0-CURRENT #6 r213257: Thu Sep 30 10:30:06 JST 2010 amd64 rc.conf: nfs_client_enable=YES nfs_reserved_port_only=YES rpc_lockd_enable=YES rpc_statd_enable=YES I'd definitely divulge which version of NFS you're using as well as what your NFS server and client are running if enabling lockd both client and server side doesn't solve your problems right away. Cheers, -Garrett I have tested with ZFS because I was doubting NFS working well, but result was the same. (I didn't test with UFS.) Thanks truss output! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fcntl always fails to delete lock file, and PID is always -6464
On Mon, Oct 4, 2010 at 5:38 PM, Daichi GOTO dai...@ongs.co.jp wrote: On Mon, 4 Oct 2010 07:19:45 -0700 Garrett Cooper gcoo...@freebsd.org wrote: 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. I'm not even getting that far. Logs attached from both runs (WITH_DEBUG_CODE and WITHOUT_DEBUG_CODE). Yeah, it looks like the same situation. 1) mozc_server was killed lock file remains (even though it should be removed) 2) mozc_server try to boot 1. check lock file there 2. there is lock file, so cannot get lock file via fcntl 3. lock file means there is another mozc_server running, so mozc_server will stop boot and finish Ok, weird. fstat on the file didn't yield anything nasty when I ran the app, and deleting the file in /tmp allowed the server to go a ways, then die, as opposed to die quickly, like what happened on the second try. The cause of problem is that kernel does not remove lock file after mozc_server killed. Mozc developer explained me that fcntl will remove lock file after that process killed. But it looks like fnctl() does not remove lock file itself. According to FreeBSD fcntl(2) manual: All locks associated with a file for a given process are removed when the process terminates. No explanation lock file removing. Does FreeBSD fnctl(2) not remove lock file after process killed? Apparently from Mozc developer, Linux kernel removes lock files after process killed. On Linux (RHEL 4.8): Window 1: $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory $ ./test_fcntl Window 2: $ ls -l /tmp/lockfile --wxr-s--T 1 garrcoop eng 0 Oct 4 19:49 /tmp/lockfile $ ./test_fcntl test_fcntl: fcntl: Resource temporarily unavailable Ok. This (EAGAIN) matches the Linux requirements specified in the manpage [1] I found, as well as the POSIX manpage [2]. The author is wrong about fcntl removing the file at exit though: $ ls -l /tmp/lockfile --wxr-s--T 1 garrcoop eng 0 Oct 4 19:49 /tmp/lockfile The file descriptor is closed though, so I can remove it at will: $ rm /tmp/lockfile $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory 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 Well, lookie here! It locked as expected :). $ ls -l /tmp/lockfile -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile $ rm /tmp/lockfile $ ls -l /tmp/lockfile ls: /tmp/lockfile: No such file or directory So something else is going on with the application that needs to be resolved in that area. With that aside though, after modifying the test app a bit, I'm confused at the value of l_pid... Window 1: $ ./test_fcntl My pid: 5372 Window 2: $ ./test_fcntl My pid: 5373 test_fcntl: fcntl: Resource temporarily unavailable PID=1 has the lock Huh...? init has the file locked...? WTF?! So assuming Occam's Razor, I did a bit more reading and it turns out that l_pid is only populated when you call with F_GETLK: negative, l_start means end edge of the region. The l_pid and l_sysid fields are only used with F_GETLK to return the process ID of the process holding a blocking lock and the system ID of the system that owns that process. Locks created by the local system will have a system ID of zero. After a successful F_GETLK request, the value of l_whence is SEEK_SET. Thus, after fixing the test app I'm getting a sensical value: Window 1: $ ./test_fcntl My pid: 5394 Window 2: $ ./test_fcntl My pid: 5395 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=5394 has the lock Linux operates in the same manner: Window 1: $ ./test_fcntl My pid: 17861 Window 2: $ ./test_fcntl My pid: 17963 test_fcntl: fcntl[1]: Resource temporarily unavailable PID=17861 has the lock Which I would expect because I'm not using anything exotic with fcntl(2) / open(2). I suspect mozc isn't properly initializing / calling fcntl(2), or the author used a non-POSIX extension that is implementation dependent and doesn't realize it (the Linux manpage has a pretty fat set of warnings about POSIX compatibility up at the top of the manpage). The developer might also want to use O_EXCL in the flags passed to open(2) as well, unless they want to lock specific sections in the file. Verified on UFS2 with SUJ. Test app attached. $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: Thu Aug 19 22:50:36 PDT 2010 r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 I
