> Bingo! That sounds familiar.
> I do use to run "rpm -qa | grep" a lot, and i did install cpan2rpm on
> that system at a time close to when the bug hit (not sure if before or
> after).
Taking a good look through the code both in rpm-4.2 and in glibc-2.3.1 as
configured in the 8.0.94 packages...
The "futex" system call that rpm sticks on is in the back end of the POSIX
threads mutex locking code under glibc-2.3.1-20030214/nptl. Have a look
at the DESIGN documents. This is what originally confused me as to it
being a kernel bug: sticking on a futex call where there was only one
clear process/thread which should have this lock. What's actually
happening is that rpm (look around rpm-4.2/db/dbinc/region.h and mutex.h
for starters) is creating a mutex lock in a memory mapped file - a
persistent resource which doesn't go away when the process does.
I haven't really dug through the rpm code thoroughly to see where (or even
whether) it would make the most sense to add a stale lock handler. Red
Hat should implement one inside of rpm so that it can deal on the fly with
a previous rpm having died for any reason. That's also the most painful
coding path (I'm not even sure how or where) so its understandable to just
work around for now and fix the remaining signal handlers that would get
rpm into trouble under normal circumstances. It needs to happen though.
For my own usage, I've been doing the following as a workaround in my
scripts and on the command line before using the rpm command:
LD_ASSUME_KERNEL="2.2.5"
...that may end up in a wrapper script for /bin/rpm in my own install.
Cheers,
Rob
--
Phoebe-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/phoebe-list
