Red Hat Bugzilla – Bug 159285
rpm doesn't lock db in chroot
Last modified: 2007-11-30 17:11:07 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050322
Description of problem:
The following command tries to lock the rpmdb in /var/lib/rpm (i.e. %_dbpath) instead of /tmp/root/var/lib/rpm :
$ rpm --root /tmp/root --rebuilddb
error: can't create transaction lock on /var/lib/rpm/__db.000
I think that the root should be prepended to %_dbpath and to macros that depend on it (in this case %_rpmlock_path).
As a quick hack I'll join a patch that fixes this immediate problem.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Created attachment 115025 [details]
Patch against rpm 4.4.1
The transaction lock is/was intended to be per-system, not per-chroot, nor per-rpmdb.
So, what you suggest is to lock all bases of the system ? (Rationale -- If you
only lock the 'main' rpmdb when doing a --rebuilddb in a chroot, this is unsafe,
because the rpmdb in the chroot can still be accessed by a user running rpm in
this chrooted environment.)
The fcntl transaction lock serializes installs/upgrades, not the database. There will always
be "unsafe" operations wrto installs no matter what path is chosen for the fcntl lock path.
E.g. the fcntl lock is advisory, not mandatory, and there are legacy versions of rpm commonly installed
in chroot's that will not conform.
The concurrency locks are known to protect rpmdb data quite well with concurrent writes.
"Don't do --rebuilddb while installing." as a policy mandate seems a perfectly adequate and obvious
solution to me, i.e. no locks at all. In fact, --rebuilddb is hardly ever necessary any more.
The fcntl transaction lock is now defaulted off in macro configuration (rather than on) in rpm-4.4.4-0.2
The rationale for doing so is that there is no one, or even multiple, paths that can be locked to prevent
multiple upgrades, given older versions of rpm in chroot's etc etc. I see no reason to pretend that
an fcntl lock is adequate to serialize transaction installs.