pkg: Cannot get a read lock on a database, it is locked by another process

[Kris Moore]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at 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