From owner-freebsd-ports@FreeBSD.ORG Sun Jul 27 14:57:48 2014 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2885591; Sun, 27 Jul 2014 14:57:48 +0000 (UTC) Received: from mailout03.t-online.de (mailout03.t-online.de [194.25.134.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63ABF2322; Sun, 27 Jul 2014 14:57:48 +0000 (UTC) Received: from fwd13.aul.t-online.de (fwd13.aul.t-online.de [172.20.27.62]) by mailout03.t-online.de (Postfix) with SMTP id 1F74F461429; Sun, 27 Jul 2014 16:51:14 +0200 (CEST) Received: from [192.168.119.33] (EB5SCQZTQhYH5dZVu0Ocsv6AdmuETDzwLUZtg7soyjjZcl-xH3weDVmh-n87qR4wVa@[84.154.101.219]) by fwd13.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XBPmy-3fxon20; Sun, 27 Jul 2014 16:51:04 +0200 Message-ID: <53D511D6.7040108@freebsd.org> Date: Sun, 27 Jul 2014 16:51:02 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ports FreeBSD Subject: pkg: Cannot get a read lock on a database, it is locked by another process X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: EB5SCQZTQhYH5dZVu0Ocsv6AdmuETDzwLUZtg7soyjjZcl-xH3weDVmh-n87qR4wVa X-TOI-MSGID: 5a3cdfb3-e6e8-4636-8dac-511e35680402 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: Sun, 27 Jul 2014 14:57:48 -0000 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