cancel
Showing results for 
Search instead for 
Did you mean: 

RPM DB Troubleshooting

 
Ross Minkov
Esteemed Contributor

RPM DB Troubleshooting

Linux Gurus,

Here is how I've been dealing with RPM DB problems. Sometimes when a process is killed it may leave some small corruption behind in the RPM database. Usually the simple "rm -f /var/lib/rpm/__db*" removes the files which hold lock state information. When this does not clear up the problem then I try "rpm -vv --rebuilddb" (after I make a backup of /var/lib/rpm) and if the problem is still there I try "rpm -vv --initdb". Today I had a problem where none of the above methods fixed it. So I tried deleting /var/lib/rpm/ directory first and then running "rpm -vv --rebuilddb". That worked. After I did that I asked myself -- since I deleted the RPM DB directory, should I had used "rpm -vv --initdb" instead of "rpm -vv --rebuilddb"? Does it matter which one you use? What do you think?

Thanks,
Ross
8 REPLIES 8
Stuart Browne
Honored Contributor

Re: RPM DB Troubleshooting

Well, the man page say that 'initdb' will just create a new database, not populate it. I think you should *follow* it with a 'rebuilddb'.

What version of RPM (on what platform) are you using? You seem to be having a fair bit of RPM troubles. I know that RH8 had a fair bit which was eventually cleared up with eratta, but.. ?
One long-haired git at your service...
Ross Minkov
Esteemed Contributor

Re: RPM DB Troubleshooting

Sorry, I forgot to mention that -- I'm using RHEL3 with rpm-4.2.3-13.

I think I remember the rpm problems around RHL8 -- this was when they split rpmbuild from rpm iirc.

Actually I think that what I did before (deleting the rpm dir and running rpm --rebuilddb) did not not help. I also tried rpm --initdb and had no luck. I ended up restoring the rpm db back, so now I still have the original problem. Any rpm action I try creates the 3 lock files in /var/lib/rpm -- __db.00x (x=1,2,3).

Stuart Browne
Honored Contributor

Re: RPM DB Troubleshooting

Most actions create those lock files (even a simple query). They don't normally get removed either (as they aren't so much lock files as temporary data files which get locked), so it's not unusual for them to exist.

It's a corruption that occurs in those temporary files which causes RPM actions to lock up.

I have a number of machines with that version of RPM and haven't yet seen such an issue. What sort of actions are you doing that's causing these lockups?
One long-haired git at your service...
Ross Minkov
Esteemed Contributor

Re: RPM DB Troubleshooting

> Most actions create those lock files
> (even a simple query).
> They don't normally get removed either
> (as they aren't so much lock files as
> temporary data files which get locked),
> so it's not unusual for them to exist.

OK, I thought that they should be there only during an rpm operation/action and get removed after that. Now that you sais that I checked some other RHEL3 servers I manage and you are absulutely right; I saw the lock files on all of them.

> It's a corruption that occurs in those
> temporary files which causes RPM actions
> to lock up.

How do you tell if you have corruption in them?

> What sort of actions are you doing that's
> causing these lockups?

The problem that I see is when I try to run apt-get install or apt-get upgrade (yes, I'm using apt4rpm). apt complains about "The following packages have unmet dependencies" and then lists almost half of the installed packages.
Gopi Sekar
Honored Contributor

Re: RPM DB Troubleshooting



may be it is a problem with apt4rpm which corrupts the rpm database. Try to use rpm/yum to install the packages.

Also check up with apt4rpm website for any known issues on particular rpm version you are using.

Hope this helps,
Gopi
Never Never Never Giveup
Steven E. Protter
Exalted Contributor

Re: RPM DB Troubleshooting

Hi Ross,

Sounds like the database is corrupted or rpm thinks there is a pending transaction. Maybe the database file is on hold with a dead install process.

I'm assuming this condition continues after a boot or you can not boot the machine.

I've been told apt is the best installer for working with rpm.

I've had some success with yum. If a product needs to be reinstalled and calculating the dependencies gives me a headache, I do a yum -y install rpm-name and it calculates dependencies and gets them all.

It is not foolproof(take it from a fool). I corrupted an rpm database so badly yesterday I had to redo the system.

Fell asleep before finishing this post last night, hope its still relevent.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Stuart Browne
Honored Contributor

Re: RPM DB Troubleshooting

'I am but a fool, and have never claimed otherwise'.. ;) from something I wrote about 6-7 years ago ;)
One long-haired git at your service...
Ross Minkov
Esteemed Contributor

Re: RPM DB Troubleshooting