Bug 222194 - rpm gives "error: can't create transaction lock on /var/lock/rpm/transaction" when using --dbpath
Summary: rpm gives "error: can't create transaction lock on /var/lock/rpm/transaction"...
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rpm
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Paul Nasrat
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-01-10 20:25 UTC by John Caruso
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-08-10 07:39:11 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description John Caruso 2007-01-10 20:25:24 UTC
Description of problem:
Trying to initialize the RPM database or install an RPM using the --dbpath
option to specify a private RPM database produces the output "error: can't
create transaction lock on /var/lock/rpm/transaction", and the action is not

Version-Release number of selected component (if applicable):

How reproducible:
Attempt to initialize a private RPM database or install an RPM using a
user-specified --dbpath.

Steps to Reproduce:

$ mkdir /home/myuser/rpmdb

$ rpm --initdb --dbpath /home/myuser/rpmdb
error: can't create transaction lock on /var/lock/rpm/transaction

$ rpm -Uvh --dbpath /home/myuser/rpmdb somerpm.i386.rpm
error: can't create transaction lock on /var/lock/rpm/transaction

Actual results:

Expected results:
rpm shouldn't try to establish a lock on /var/lock/rpm/transaction when the user
is explicitly specifying that they're using their own RPM database.

Additional info:
This works as expected under the version of rpm on RHEL3 (rpm-4.2.3-30_nonptl),
and strace shows that this version of rpm does not try to access any files in
/var/lock/rpm (unlike the version on RHEL4).

Comment 1 John Caruso 2007-01-10 21:11:51 UTC
It appears that this can be addressed by setting _rpmlock_path in ~/.rpmmacros.
 While this is a workaround, I'd suggest that the bug here is that _rpmlock_path
should default based on --dbpath rather than needing to be explicitly set in

Comment 2 Paul Nasrat 2007-01-11 09:04:13 UTC
The erratum clearly mentions %_rpmlock_path for non-root cases and how to set
using %dbpath:


Transaction lock issues using RPM with --root and --dbpath have been fixed.
Note, to use --dbpath as non root, customers will need to define the
%_rpmlock_path macro to a location that can be written to; future versions
of RPM use '%{_dbpath}/__db.000'.

RHEL 5 will use a dbpath based lock but for RHEL updates we try to be
conservative so maintaining the existing lock location file for RHEL 4 was
decided upon, whilst providing necessary information in the advisory.  Thus we
will not change this for RHEL 4.

Please also note if you are a Red Hat Enterprise Linux customer and have an
active support entitlement, you should be raising issues via Red Hat Support.


This is so that appropriate prioritisation and assesment (eg for update
releases) can be performed and so that support agreements can be met.

Comment 3 John Caruso 2007-01-11 18:08:11 UTC
So this is in fact a recognized bug--thanks.  Based on what you've said the plan
of action is for it, I'd suggest that it should be closed as NEXTRELEASE, not

I can tell you that searching for "error: can't create transaction lock on
/var/lock/rpm/transaction" on Google gives you 0 hits, searching for it on
Bugzilla gives you one hit (this bug report), and searching for it on RHN gives
you nothing that's relevant (and if the search is restricted to Errata only it
gives you no hits at all).

So I'd also suggest that adding a message about _rpmlock_path to rpm itself
(perhaps just specifically when a non-root user is setting --dbpath and is about
to get stuffed with the "can't create transaction lock" message) would be a lot
more helpful than expecting people to track down the erratum you've cited and
find the workaround it mentions.  It's a simple (and conservative) thing to do,
and you could keep Redhat customers from wasting a lot of time this way.

Comment 4 John Caruso 2007-08-09 18:36:15 UTC
I just got pinged by Redhat support about this, and in reviewing Redhat's
response here it doesn't make sense to me.

The justification for not fixing this bug in RHEL4 was that it's the more
conservative approach.  But using --dbpath without an explicit setting for
_rpmlock_path worked just fine in all RHEL4 releases up until RHEL4u4--so how
can it be more conservative to leave it broken than to fix it?

Comment 5 John Caruso 2007-08-09 18:57:49 UTC
I take it back--maybe it *has* been broken all throughout RHEL4, since it was
RHEL3 where I last knew that it was working.

Comment 6 Paul Nasrat 2007-08-10 07:39:11 UTC
GA RHEL 4 shipped with:

#define RPMLOCK_FILE "/var/lock/rpm/transaction"

This is now configurable as documented in comment #2, but defaults to RHEL 4 GA
default. RHEL 5 is configured differently.

WONTFIX is used to indicated this bug is not being considered for the update
release, according to our process.

Note You need to log in before you can comment on or make changes to this bug.