From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051201 Fedora/1.5-1.1.fc4.nr Firefox/1.5 Description of problem: When I upgrade via YUM or via RPM some package sometimes happen that the RPM process lock in a futex() call. The only solution is to kill -9 <PID>. But after it the RPM database will be corrupt. The affected packages will exist in 2 versions in the DB. This problem can only solves by hand. So I must to disable automatic updates for all my machines because this issue. If I run rpm -U -vv <package> I see that the RPM started one of the package install scripts and then [ 1 = 0 ] is the last line. The actual script begins if [ $1 = 0]; line. This problem is nearly unreproduceable in fresh installation. But it turns up often when the installation gets old. I think it has a chance for deadlock and every problem cause DB damage or else and increase this chance. I tried Fedora's kernels and vanilla kernels but none of them helps. I think this is a big problem. I need to check the updates by hand all of my machines. It's lots of work and very frustrating! PS: Sorry for my bad English! Version-Release number of selected component (if applicable): rpm-4.4.1-22 and other versions How reproducible: Sometimes Steps to Reproduce: yum upgrade OR rpm -U -vv <package> maybe reproduce this problem Additional info:
This may be related to bug #161038 (up2date causing packages to be installed twice, or at least that's what the RPM database says) and bug #170753 (same thing with yum).
Additional info: It looks like that the RPM process spawned a child process for the shell script execution and waiting for it. But it's completed before the main process started to wait. IMHO, because when the deadlock come up the child shell process doesn't exists.
Additional info: It happened again. The RPM process freezed in to remove one of the duplicated CPP rpms. It was late night so I turned off the machine. Next day I tried to reproduce this but I cant. It worked. So it's random when turns this bug up.
Created attachment 123421 [details] A failed RPM runs output
First I ran an rpm --rebuilddb to correct any problem which is exists in the DB. Then I tried to remove a duplicates. I always try remove the new package and I upgrade from Yum's cache with hand. Often with --nopreun or something similar to disable the scripts. If I remove the old package some files are missing from the system example the docs file. [root@sol rpm]# rpm -q mysql-server mysql-server-4.1.15-1.FC4.1 mysql-server-4.1.16-1.FC4.1 [root@sol rpm]# rpm -e -vv mysql-server-4.1.16-1.FC4.1 >/tmp/rpm.log 2>&1 It's failed and freezed in the middle. I attached the rpm.log file. (I hope :-) ) I wanted to do a strace from it. So I try with: [root@sol rpm]# strace -o /tmp/rpm.strace -fFF rpm -e -vv mysql-server-4.1.16-1.FC4.1 It's succeeded. It can remove the package but it's freezed at the end. I needed to kill it with SIGKILL. I attached also the rpm.strace file. I copied the RPM output from console and I paste it into an rpm.log_with_strace file. Attached also. (The last word: LeállÃtva is stopped in Hungarian, it means I killed the process with SIGKILL.) It's strange but it looks like when I strace the process it's more "stable". This is not the first time when the rpm runs with strace and freeze without it.
Created attachment 123422 [details] A "successed" rpm runs strace log
Created attachment 123423 [details] The rpms output on the straced run
A scriptlet deadlock issue has been addressed in rawhide bug #146549 can you reproduce with fc5t2 and rpm 4.4.2-15?
I can't install fc5t2. But I downloaded the SRPM for rpm-4.4.2-15.2. I recompiled and installed it. On one machine looks like that the problem is goes away. I upgraded about 10-15 packages successfuly. Before this version I can't do this. It's freezes everytime with this packages. I was happy. But then I tried with my own home machine with more packages and the problem comes up again and "destroy" my machine. Now I have approx. 200 duplicated packages :-( I need to reinstall it, it's faster than correct this mess.... So I think to problem is still exists or there was more problem/bug what causes this symptoms.
This problem appeasr solved. Other problems should be in other, perhaps new, bug reports.