From owner-freebsd-bugs@FreeBSD.ORG Sun Apr 1 18:50:05 2007 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05FF516A404 for ; Sun, 1 Apr 2007 18:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id DB21E13C4C4 for ; Sun, 1 Apr 2007 18:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l31Io4jp062807 for ; Sun, 1 Apr 2007 18:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l31Io47X062806; Sun, 1 Apr 2007 18:50:04 GMT (envelope-from gnats) Resent-Date: Sun, 1 Apr 2007 18:50:04 GMT Resent-Message-Id: <200704011850.l31Io47X062806@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Arne Woerner Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D73A516A403 for ; Sun, 1 Apr 2007 18:46:44 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [69.147.83.33]) by mx1.freebsd.org (Postfix) with ESMTP id C8CC013C44C for ; Sun, 1 Apr 2007 18:46:44 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l31IkihZ069509 for ; Sun, 1 Apr 2007 18:46:44 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id l31IfhZ4068924; Sun, 1 Apr 2007 18:41:43 GMT (envelope-from nobody) Message-Id: <200704011841.l31IfhZ4068924@www.freebsd.org> Date: Sun, 1 Apr 2007 18:41:43 GMT From: Arne Woerner To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.0 Cc: Subject: bin/111101: /usr/bin/lockf: when lockf blocks due to another lockf and no -k is specified and the other lockf ends, the file is away X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 18:50:05 -0000 >Number: 111101 >Category: bin >Synopsis: /usr/bin/lockf: when lockf blocks due to another lockf and no -k is specified and the other lockf ends, the file is away >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Apr 01 18:50:04 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Arne Woerner >Release: R6.2 >Organization: >Environment: FreeBSD neo.riddick.homeunix.org 6.2-RELEASE FreeBSD 6.2-RELEASE #8: Fri Mar 30 10:00:56 UTC 2007 aw@neo.riddick.homeunix.org:/usr/src/sys/i386/compile/NEO i386 >Description: I use lockf in order to coordinate the access to my TV frame grabbers (/dev/cxm?). When another recording starts (process B) it can happen that a previous recording (process A) still needs some seconds, I end up with an unlink-ed lock file. I would expect the following order: 1. process A: holds file LCK 2. process B: blocks on file LCK 3. process A: unlinks file LCK 4. process A: releases lock on file LCK 5. process B: locks the already opened but unlinked file LCK 6. process B: checks, if file LCK still exists 7. process B: creates file LCK 8. process B: locks file LCK As a workaround I use lockf with option "-k", which should solve that problem... Furthermore I would like to recommend, to make the "-k" behaviour the default behaviour, so that we will not remove data files, that were co-used as lock files... -Arne >How-To-Repeat: Let LCK be a file, that does not exist in the work directory % lockf LCK sleep 10 & sleep 1 ; lockf LCK ls -l LCK [1] 38788 ls: LCK: No such file or directory [1] + Done lockf LCK sleep 10 I was able to repeat that on a i586 (Pentium) and a i686 (Athlon XP), which both used R6.2 with multimedia/pvr250 related kernel patches. >Fix: 1. Use "-k" as a work around. 2. Check if file exists after holding the lock. And if it doesnt exist anymore, re-create it and close the old (in the meantime unlinked) lock file and start again... <-- Maybe that contains another error, that I dont see yet... >Release-Note: >Audit-Trail: >Unformatted: