From owner-freebsd-ports@FreeBSD.ORG Mon Jul 28 15:35:02 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 114F49B4 for ; Mon, 28 Jul 2014 15:35:02 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD412292E for ; Mon, 28 Jul 2014 15:35:01 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 25DDB785FA for ; Mon, 28 Jul 2014 08:35:00 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 65403-04 for ; Mon, 28 Jul 2014 08:35:00 -0700 (PDT) Received: from [192.168.0.51] (75-130-56-30.static.kgpt.tn.charter.com [75.130.56.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 96A95785F4 for ; Mon, 28 Jul 2014 08:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1406561699; bh=SgT1e2Nty4884ujEbMAnFdQjfxr3WcaVo04+T42Kak8=; h=Date:From:To:Subject:References:In-Reply-To; b=PTm2dHr+LwYZ+dGuFYRalRDHw89v/XOfRu/+GWxGQrG3frkOGYDlfJDMkF+4woXyO 6yeOp3up1HKeNUdpc8TSSJvJIAUxym2L07cKluIyJsm5SII2M5/e/LbPyXV/amu6jr V1zeQKk0ctggBxD+TucmZYqkffFIEGRj4RZ9labQ= Message-ID: <53D66DA2.4020009@pcbsd.org> Date: Mon, 28 Jul 2014 11:34:58 -0400 From: Kris Moore User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: pkg: Cannot get a read lock on a database, it is locked by another process References: <53D511D6.7040108@freebsd.org> In-Reply-To: <53D511D6.7040108@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:35:02 -0000 On 07/27/2014 10:51, Stefan Esser wrote: > The locking of the pkg database leads to soft failures, but I'm afraid, > if these soft failures happen to coincide with certain administrative > tasks, they can lead to unexpected results. > > One example is that portmaster fails to detect PKGNG (and then assumes > to be working in a pre-PKGNG environment), if some pkg subcommand locks > the database. To repeat: > > # pkg version -Bs & > # pkg info > > As long as pkg version runs, pkg info fails to get the read lock (at > least in the large majority of my tests). You can also prevent any pkg > command from running, if you STOP (kill -STOP / ^Z) pkg version. Any > other pkg command will fail, until "pkg version" has been "unstopped" > and run to completion. This might even be a local DoS, if any command > that read-locks the package DB for extended time can be executed by > an unprivileged user. > > Similar error messages are reported by pkg_libcheck, which issues > lots of pkg commands in parallel. (I have observed some 5 lock > failures per 1000 installed packages on my system). > > > I did not try to test all combinations of simultanous pkg commands > and did not verify, whether e.g. "pkg upgrade" might be stopped > half way through because of an error accessing the pkg database, > but I have seen SQLITE error messages that indicated failed write > operations (INSERT/UPDATE). > > Either the timeouts are too low, or the duration during which the > database is locked by a single operation is too large (or there is > no fairness and some processes never get access to the database?). > > > I think this should be fixed, since pkg commands that lock the > database can be run from CRON or by other means in the background > and the operator who issues pkg commands in the foreground (or runs > portmaster) receives spurious error messages (which might still be > better than the batch jobs doing silly things, after they failed to > obtain information from the pkg database ...) > > Regards, STefan > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" +1 to this whole thing. I would prefer that pkg commands simply wait for the DB to become unlocked again, instead of just failing outright. We have many scripts which monitor the system, check for updates, display our GUI store-front, and its really annoying to have random bits of it fail simply because of bad timing with another pkg process. -- Kris Moore PC-BSD Software iXsystems