From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.2.1) Gecko/20030121 Description of problem: Got a very similar problem on a fresh RedHat 9 system (rpm-4.2-0.69) while updating glibc RPMs: hung, would not respond to signals, etc. This time, the strace showed: # strace -p 8804 futex(0x405940cc, FUTEX_WAIT, 0, NULL <unfinished ...> This looks like the same bug in 77562, 89554, and 92270. The usual remedy (sigKILL the RPM process, rm the __db lockfiles, rebuild the database) got me a working RPM installation again, but trying the same installation again got the same hang with the same trace. Those tickets keep being closed with some talk about signals, but no action appears to be taken on the root problem-- the fact that RPM is hanging in the first place! Manually deleting lockfiles and rebuilding is fine on your home workstation, but far from practical in a large enterprise environment where you might be deploying an RPM on a hundred machines at once.... This is a very serious problem and is potentially impacting our migration plans. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1.In the redhat updates/i386 directory: rpm -Uvh glibc-utils-2.3.2-27.9.i386.rpm glibc-common-2.3.2-27.9.i386.rpm glibc-profile-2.3.2-27.9.i386.rpm glibc-debug-2.3.2-27.9.i386.rpm glibc-devel-2.3.2-27.9.i386.rpm ../i686/glibc-2.3.2-27.9.i686.rpm ../i686/nptl-devel-2.3.2-27.9.i686.rpm 2. Voila! It hangs. Usually. 3. Actual Results: RPM hangs, will not respond to signals. Expected Results: RPM installed-- or at least a clean failure with an error message. Additional info: I am marking this "high" because it makes RedHat 9 (and 8.0, for that matter) an unmaintainable distribution in my environment. It seems to be more likely to hang if many RPMs are specified on the argument list.
*** This bug has been marked as a duplicate of 92396 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.