Date: Mon, 28 Jul 2014 14:36:15 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: Kris Moore <kris@pcbsd.org> Cc: FreeBSD Ports ML <freebsd-ports@freebsd.org> Subject: Re: pkg: Cannot get a read lock on a database, it is locked by another process Message-ID: <CAN6yY1vQVybvD6AwQWy4gxTOo7ZSPCG9kJ4QK3z5AeYh%2BMoYDg@mail.gmail.com> In-Reply-To: <53D66DA2.4020009@pcbsd.org> References: <53D511D6.7040108@freebsd.org> <53D66DA2.4020009@pcbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 28, 2014 at 8:34 AM, Kris Moore <kris@pcbsd.org> wrote: > 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@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@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 This is a real pain, but I only see it on one of my systems. That system is my only i386 system and also my only system running 9.2. Whether that has anything to do with it, I can't say, but it makes me very nervous. I just would like to know why only the one system has the problem. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1vQVybvD6AwQWy4gxTOo7ZSPCG9kJ4QK3z5AeYh%2BMoYDg>