pkgng: sqlite: database is locked
jdc at koitsu.org
Wed Dec 12 14:53:59 UTC 2012
(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.
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.
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 also makes me wonder if there's a SIGINT handler for a person
hitting Ctrl-C in the middle of that operation and if proper clean-up is
| Jeremy Chadwick jdc at koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
More information about the freebsd-ports