pkgng: sqlite: database is locked
bapt at FreeBSD.org
Wed Dec 12 15:30:10 UTC 2012
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)
> > ===> Registering installation for MuSE-0.9.2_14
> > Installing MuSE-0.9.2_14... done
> > pkg: sqlite: database is locked
> > which results in muse not being registered in the pkg database...
> 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.
> 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 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.
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 clean
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 use 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:
> > ... This persists between reboots, and for fresh pkg runs.
> 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 survive
> 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. :-)
> : 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 system.
Anyway the reported issue is really strange and need way more details to be able
to be investigated.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
More information about the freebsd-ports