All of a sudden yum hangs on a Centos 4.5 (updated to the latest patch before 4.6) when I try to use it. "clean metadata" didn't help. The output of -d5 shows it gets to the point of "Reading Local RPMDB" and then sits there. The process doesn't die, but doesn't seem to do anything from that point on. strace shows this: futex(0xb76dcae8, FUTEX_WAIT, 2, NULL I remember that futex hangs have been mentioned in the past when doing "big" updates from 4.x to 4.y, but this wasn't the case here. python-2.3.4-14.4 python-sqlite-1.1.7-1.2.1 sqlite-3.3.6-2 yum-2.4.3-3.el4.centos Kernel in use is not the latest 4.5 kernel, but one from 4.3. This shouldn't matter in this case, shouldn't it? How can I resolve this? I see that one suggestion is rm /var/lib/rpm/__db*. How do I rebuild it then? I found that cleaning the metadata doesn't remove the sqlite databases, so I removed these from /var/yum/cache as well. The rebuilt databases were different, but it didn't solve the problem. Kai -- Kai Sch?tzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Kai Schaetzl <maillists at conactive.com> wrote:> All of a sudden yum hangs on a Centos 4.5 (updated to the latest patch > before 4.6) when I try to use it. "clean metadata" didn't help. > The output of -d5 shows it gets to the point of "Reading Local RPMDB" and > then sits there. The process doesn't die, but doesn't seem to do anything > from that point on. strace shows this: futex(0xb76dcae8, FUTEX_WAIT, 2, > NULL > > I remember that futex hangs have been mentioned in the past when doing > "big" updates from 4.x to 4.y, but this wasn't the case here. > python-2.3.4-14.4 > python-sqlite-1.1.7-1.2.1 > sqlite-3.3.6-2 > yum-2.4.3-3.el4.centos > Kernel in use is not the latest 4.5 kernel, but one from 4.3. This > shouldn't matter in this case, shouldn't it? > > How can I resolve this? > I see that one suggestion is rm /var/lib/rpm/__db*. How do I rebuild it > then? > I found that cleaning the metadata doesn't remove the sqlite databases, so > I removed these from /var/yum/cache as well. The rebuilt databases were > different, but it didn't solve the problem. > > > KaiFrom the rpm man page: REBUILD DATABASE OPTIONS The general form of an rpm rebuild database command is rpm {--initdb|--rebuilddb} [-v] [--dbpath DIRECTORY] [--root DIRECTORY] Use --initdb to create a new database, use --rebuilddb to rebuild the database indices from the installed package headers. Remove the __db* files and then "rpm --rebuilddb" is usually sufficient unless you have non-standard locations for the database. Cheers, Dave -- Politics, n. Strife of interests masquerading as a contest of principles. -- Ambrose Bierce
Kai Schaetzl <maillists at conactive.com> wrote:> Before I do this without need I have a question: if the rpm db is > corrupt shouldn't rpm -q or -qa stop working? KaiNot necessarily. A regular user can run rpm -q since it doesn't lock the database (your original posting showed rpm hanging on a FUTEX). I don't know rpm internals but I'd guess that simple queries for a specific package or even a listing of all packages don't go very deep into the rpm database. Also, since the database isn't being updated, there isn't any need to lock the database during the query. Cheers, Dave -- Politics, n. Strife of interests masquerading as a contest of principles. -- Ambrose Bierce
Hi, I used to have exactly the same problem when the machine rebooted in the middle of an RPM installation or if the rpm process was killed -9. On Jan 9, 2008 7:41 PM, Kai Schaetzl <maillists at conactive.com> wrote:> The process doesn't die, but doesn't seem to do anything > from that point on. strace shows this: futex(0xb76dcae8, FUTEX_WAIT, 2, > NULL > ... > How can I resolve this? > I see that one suggestion is rm /var/lib/rpm/__db*. How do I rebuild it > then?You can just remove the __db* files (if you're sure they're there because of an rpm interrupted process, check first if there are no rpm processes running). __db* are Berkeley DB's lockfiles and are used for transactions inside Berkeley DB. You don't need to rebuild anything, the RPM database is on the other files on that directory. Once you remove the locks you'll be able to access it normally.> I found that cleaning the metadata doesn't remove the sqlite databases, so > I removed these from /var/yum/cache as well. The rebuilt databases were > different, but it didn't solve the problem. >You don't have to clean /var/yum/cache since that's yum's cache and the problem you have is with rpm. Cleaning it, however, won't hurt you, you'll only have to download the RPM again. Hope it helps, Filipe -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20080111/053f8552/attachment-0003.html>
Filipe Brandenburger wrote on Fri, 11 Jan 2008 10:35:16 -0500:> You can just remove the __db* files (if you're sure they're there because of anrpm interrupted process, check first if there are no rpm processes running). __db* are Berkeley DB's lockfiles and are used for transactions inside Berkeley DB. You don't need to rebuild anything, the RPM database is on the other files on that directory. Once you remove the locks you'll be able to access it normally. Hm, the files are __db.001, __db.002 and __db.003 and range up to a size of over one MB, so they cannot be lockfiles. Yeah, maybe they are interim transaction files. After removing and doing an rpm query they are back there, in exactly the same size. I'd rather think they are indexes, there is no transaction necessary for a read query. Anyway, after removing and rebuilding them yum works! Thanks. Kai -- Kai Sch?tzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com