Date: Sun, 27 Jul 2014 16:51:02 +0200 From: Stefan Esser <se@freebsd.org> To: Ports FreeBSD <freebsd-ports@FreeBSD.org> Subject: pkg: Cannot get a read lock on a database, it is locked by another process Message-ID: <53D511D6.7040108@freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53D511D6.7040108>