TIP: yum hangs on futex()

[Ben Scott]

On 1/15/07, Bill McGonigle <bill at bfccomputing.com> wrote:
> Doing an strace revealed the hang was after opening the files in /var/
> lib/rpm and yum was waiting on a futex() call.

  Gah!

  On one of my boxen, I had built a custom kernel to solve some
unrelated, odd problem.  When I built the kernel, I didn't use the
threading model that Red Hat used for their kernels on that release.
That meant various things in the userland runtime got horribly borked
unless I told them LD_ASSUME_KERNEL.  (My fault, really, for changing
a system fundamental like that.)  One of the things that got so borked
was rpm (or berkdb or something else it uses).  The symptoms were
more-or-less identical to those you give (fix was totally different,
obviously).

  rpm started crapping out on this box about a month ago, and I've
been intermittantly beating my head against the wall trying to figure
out how the frell that bug came back when I'd long since switched back
to the stock kernel.

  Now I see that I've been hitting *this* bug, too.

> The tell-tale sign, in general, is a trail of: __db.nnn files.  e.g.,
> in /var/lib/rpm:

  FYI, these are not always a sign of trouble.  Although I suspect,
given the right environment, they usually are...

>   cd /var/lib/rpm
>   db_recover

useful++;

> db_verify rarely reports anything useful but will reliably segfault on a broken
> database.

  I didn't get that, but got quite a few of:

	db_verify: fatal region error detected; run recovery

  So I ran "db_recover"... it sat there for about ten seconds, and then spit out

	db_recover: unable to join the environment

and exited.  Not really sure what the hell that means.  But db_verify
appears to be happy now, and more importantly, rpm works again.  Yay!

> Good news: it looks like versions of RPM in CVS (please be in Fedora
> 7...) will use SQLite for a back-end if available.

  I heard that about the version of RPM that was going into FC6.

  Much thanks for the good info, Bill!

-- Ben