Date: Wed, 12 Dec 2012 16:30:05 +0100 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Jeremy Chadwick <jdc@koitsu.org> Cc: Mathias.Picker@virtual-earth.de, freebsd-ports@freebsd.org Subject: Re: pkgng: sqlite: database is locked Message-ID: <20121212153005.GG68036@ithaqua.etoilebsd.net> In-Reply-To: <20121212145357.GA49439@icarus.home.lan> References: <20121212145357.GA49439@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--3xoW37o/FfUZJwQG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 12, 2012 at 06:53:57AM -0800, Jeremy Chadwick wrote: > (Please keep me CC'd as I'm not subscribed to the list) >=20 >=20 > > =3D=3D=3D> Registering installation for MuSE-0.9.2_14 > > Installing MuSE-0.9.2_14... done > > pkg: sqlite: database is locked > >=20 > > which results in muse not being registered in the pkg database... >=20 > This worries me. It appears to indicate that the installation of the > package (i.e. sticking files into /usr/local) happens first, followed by > an attempted exclusive lock of the pkg sqlite DB, which then failed -- > thus leaving files laying around in /usr/local. >=20 > If that is the case (and boy do I hope it isn't) then that logic is 100% > backwards. The DB exlock should happen first, and if the DB exlock > fails[1] then things should abort. Otherwise you'll end up with files > installed on your filesystem which aren't registered in the pkg DB, and > that is unacceptable. >=20 pkg install and pkg add doesn't do that at all. Just pkg2ng and installing from ports uses pkg register which does that, exactly the same way pkg_install does, pkg register knows how to do the cle= an way, just the ports tree doesn't know yet how to do it, I have patched for = that unfortunatly it breaks compatibility with pkg_install (the solution is to u= se a stage directory inside the ports tree) If you are worried by this, do not ever have a look at how the pkg_install = works :) > This also worries me: >=20 > > ... This persists between reboots, and for fresh pkg runs.=20 >=20 > What kind of locking mechanism is being used here? flock(2) LOCK_EX > would not survive a reboot, but a filesystem-based dotlock would. It is the sqlite native lock system which is a flock so it should not survi= ve the reboot >=20 > This really needs investigation and not be swept under the rug. And > please don't tell me "you have the source, go look at it" -- I would > much rather the authors who are familiar with the code look at it. :-) >=20 > [1]: I don't advocate that the locking mechanism should block > indefinitely, but there should be some kind of retry attempt at a > specific interval (i.e. try 5 times, with 1 second delays) before giving > up -- and something on-screen should be printed/shown every time an > attempt to lock is made. Maybe that already happens, I don't know, I > don't use pkg. This is already in, and we have a lot of work for a finer grain locking sys= tem. Anyway the reported issue is really strange and need way more details to be= able to be investigated. regards, Bapt --3xoW37o/FfUZJwQG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDIov0ACgkQ8kTtMUmk6EzU5ACfbRcT4ZRkXF4Zv23BIDdbKv2A lA4An1aewaOldDm6m1O4VpIFZXnBo7wD =Fu3w -----END PGP SIGNATURE----- --3xoW37o/FfUZJwQG--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121212153005.GG68036>