I am working on a test system with a customer database of about 100 controllers in their network. OC 50 installed fine and has been working but trying to goto the latest release has been trouble some. Searching in the Support site had yielded little help using the red string below.
Most often it means that another instance of RPM is already running (notice, it could also be something like background upgrade checker, not necessary rpm command only). This is usually transient condition and goes away automatically.
If you verified that no other invocation of RPM-related programs is active, it could mean unclean shutdown of previous RPM run (like kill -9). This leaves RPM database inside of open transaction. Files __db.000 and others are effectively Berkely DB transaction logs. Those files are normally simply removed on reboot, so brute force is to just manually do the same (rm /var/lib/rpm/__db.*). More prudent approach is to try to recover database; if you have Berkely db-utils installed, try "db_recover -h /var/lib/rpm/"; this should replay logs and remove them. This could be db45_recover or similar, because multiple versions of db-utils can coexist.
Finally the worst case is when installation script tries to invoke RPM from within another RPM invocation. But I would expect this will be seen on every system then, so hopefully it is not the case.
Re: HELP - trouble upgrading OC 50 to 502 - waiting for transaction lock on /var/lib/rpm/__db.000
Hello ... sorry i was not able to report right away, i got swept away by higher priority items.
The short answer is rebooted the host; it had been up for 500+ days and it could have been a resource issue, a memory buffer, etc. Impossible to say at the moment; I did kill off the db.000 files and rebuild the RPM database.
After rebooting it worked like a charm and was upgraded in 20 minutes.
This was a test machine so rebooting was easy to do ( no change request or impact to dependent services ) but rebooting on a real system may not be as easy next time. There will be more upgrades in the future and we will see how they go.