From owner-freebsd-fs@FreeBSD.ORG Thu Oct 7 14:36:57 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0229F1065670; Thu, 7 Oct 2010 14:36:57 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE268FC1B; Thu, 7 Oct 2010 14:36:56 +0000 (UTC) Received: from scc-wkit-clx-208-149.scc.kit.edu (scc-wkit-clx-208-149.scc.kit.edu [141.3.208.149]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 95B8212543B; Thu, 7 Oct 2010 23:36:53 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Daichi GOTO In-Reply-To: Date: Thu, 7 Oct 2010 16:36:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101004144927.36822f07.daichi@ongs.co.jp> <20101005093826.17432b1e.daichi@ongs.co.jp> <20101005153410.598e4484.daichi@ongs.co.jp> <20101005175536.a67998ae.daichi@ongs.co.jp> To: Garrett Cooper X-Mailer: Apple Mail (2.1081) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 14:36:57 -0000 On Oct 5, 2010, at 7:09 PM, Garrett Cooper wrote: > On Tue, Oct 5, 2010 at 8:58 AM, Garrett Cooper = wrote: >> On Tue, Oct 5, 2010 at 7:52 AM, Garrett Cooper = wrote: >>> On Tue, Oct 5, 2010 at 1:55 AM, Daichi GOTO = wrote: >>>> On Tue, 5 Oct 2010 01:23:02 -0700 >>>> Garrett Cooper wrote: >>>>> 2010/10/4 Daichi GOTO : >>>>>> Thanks nice test tool :) And at last I got it excepting one = mystery! >>>>>>=20 >>>>>> On Mon, 4 Oct 2010 20:17:08 -0700 >>>>>> Garrett Cooper wrote: >>>>>>> Following through the same process on FreeBSD... >>>>>>>=20 >>>>>>> Window 1: >>>>>>> $ ls -l /tmp/lockfile >>>>>>> ls: /tmp/lockfile: No such file or directory >>>>>>> $ ./test_fcntl >>>>>>>=20 >>>>>>> Window 2: >>>>>>>=20 >>>>>>> $ ls -l /tmp/lockfile >>>>>>> -rwsr-x--- 1 garrcoop wheel 0 Oct 4 20:14 /tmp/lockfile >>>>>>> $ ./test_fcntl >>>>>>> test_fcntl: fcntl: Resource temporarily unavailable >>>>>>=20 >>>>>> Just my mystery is as follow: >>>>>>=20 >>>>>> Windows 1: >>>>>> % ./test_fcntl >>>>>> My pid: 43490 >>>>>>=20 >>>>>> Windows 2: >>>>>> % ls -l /tmp/lockfile >>>>>> -r-sr-x--- 1 daichi wheel 0 10=E6=9C=88 5 15:02 /tmp/lockfile = <--- is it weird, isn't it? >>>>>> % ./test_fcntl >>>>>> test_fcntl: open: Permission denied >>>>>> % >>>>>>=20 >>>>>> Oops... What's wrong... /tmp is as follow: >>>>>>=20 >>>>>> % mount | grep tmp >>>>>> /dev/ada0s1f on /tmp (ufs, local, noatime, soft-updates) >>>>>> % dumpfs /tmp | grep journal >>>>>> flags soft-updates+journal >>>>>> % >>>>>>=20 >>>>>> And working scene: >>>>>>=20 >>>>>> Windows 2: >>>>>> % chmod u+w /tmp/lockfile >>>>>> % ls -l /tmp/lockfile >>>>>> -rwsr-x--- 1 daichi wheel 0 10=E6=9C=88 5 15:22 /tmp/lockfile >>>>>> % ./test_fcntl >>>>>> My pid: 43646 >>>>>> test_fcntl: fcntl[1]: Resource temporarily unavailable >>>>>> PID=3D43490 has the lock >>>>>> % >>>>>=20 >>>>> What's your umask and what are the permissions on /tmp? >>>>=20 >>>> % ll / | grep tmp >>>> drwxrwxrwt 14 root wheel 1024 10=E6=9C=88 5 17:19 tmp >>>> % umask >>>> 022 >>>> % rm -f test >>>> % touch test >>>> % ll | grep test >>>> -rw-r--r-- 1 daichi wheel 0 10=E6=9C=88 5 17:52 test >>>> % >>>=20 >>> 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): >>>=20 >>> $ ls -la /tmp/ | head -n 2 >>> total 462686 >>> drwxrwxrwt 51 root wheel 11776 Oct 5 03:11 . >>> $ umask >>> 0022 >>>=20 >>> 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: >>>=20 >>> Window 1: >>>=20 >>> $ umask 022 >>> $ ./test_fcntl >>> My pid: 17353 >>>=20 >>> Window 2: >>>=20 >>> $ ./test_fcntl >>> My pid: 17356 >>> test_fcntl: fcntl[1]: Resource temporarily unavailable >>> PID=3D17353 has the lock >>> $ ls -l /tmp/lockfile >>> -rwSr----- 1 gcooper wheel 0 Oct 5 07:49 /tmp/lockfile >>>=20 >>> 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: >>>=20 >>> 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 >>>=20 >>> FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1 >>> r211767M: Sat Aug 28 00:28:45 PDT 2010 >>> garrcoop@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK amd64 >>>=20 >>> The tests above were run on a FreeBSD box with the following = info: >>>=20 >>> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: >>> Thu Aug 19 22:50:36 PDT 2010 >>> root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 >>>=20 >>> On bayonetta /tmp is SUJ backed (probably should change that >>> though), and on bioshock it's not SUJ backed. >>=20 >> And while this might be a good mental exercise, I think we're missing >> the original point of your bug: >>=20 >> 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: >=20 > 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=20= 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? >=20 > Thanks! > -Garrett > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"