* 3ES/3WS * up2date-4.0.1-1.x86_64 * rpm-4.2.1-4.2.x86_64 * rpm-python-4.2.1-4.2.x86_64 This might be rpm's fault (or maybe even the kernel's fault), but here goes... up2date is getting stuck in futex. .live.[root@colossus root]# strace -p 2839 Process 2839 attached - interrupt to quit futex(0x2a99719240, FUTEX_WAIT, 0, NULL <unfinished ...> Here is what I did: 1) standard kickstart install of 3ES for hammer (everything) 2) register with rhn via key (rhnreg_ks 3) run up2date -u -f -i --nox --nosrc Will attach details...
Created attachment 96349 [details] output of up2date
Created attachment 96350 [details] backtrace of stuck up2date process
after that, killed up2date, rebooted and tried to finish up2dating. Got the following: .live.[root@colossus root]# up2date -u -f --nox --nosrc Fetching package list for channel: rhel-x86_64-ws-3... ######################################## Fetching Obsoletes list for channel: rhel-x86_64-ws-3... Name Version Rel ---------------------------------------------------------- kernel 2.4.21 4.0.1.EL x86_64 kernel-smp 2.4.21 4.0.1.EL x86_64 kernel-source 2.4.21 4.0.1.EL x86_64 nptl-devel 2.3.2 95.6 x86_64 nscd 2.3.2 95.6 x86_64 Testing package set / solving RPM inter-dependencies... ######################################## RPM package conflict error. The message was: Test install failed because of package conflicts: package kernel-2.4.21-4.0.1.EL is already installed package kernel-smp-2.4.21-4.0.1.EL is already installed
The second problem (the kernel conflict) is an up2date bug that is addressed elsewhere. The primary problem (getting stuck in futex) seems to be a problem with rpm.
I've been trying to get a shorter path to reproduce this bug. Here goes... Start on an up2date 3AS x86_64 box for x in $(seq 100); do echo ITERATION $x rpm -e kernel-2.4.21-4.0.1.EL kernel-smp-2.4.21-4.0.1.EL up2date -u -f --nox --nosrc done &>/tmp/bug & after several iterations one or the other will segfault.
Add -vv to up2date please. I can often guess what the problem is if I can see the equiv of CLI -vv output. (hmmm, after perusing the stack trace) Hmmm, you also need to insure that no other root process is accessing the database. Check the RHN applet and the rpm -q cron script first. If you find another process, then the hang on futex is "expected" behavior, this is known as concurrent access, a current rpm "production" feature, not a bug. That's what I see in the stack trace, concurrent access locking.
Created attachment 96506 [details] strace of segfaulting up2date
Running the test with -vv now.
Hmmm, this looks like the dangling pointer problem. Try doing the following to verify rm /var/lib/rpm/Pubkeys rpm --rebuilddb -vv If that fixes (yes, reproduce is quite hard), then this is the dangling pointer problem in rpm.
The dangling pointer is #107835, fixed in rpm-4.2.2-0.6 and later. No idea how/when RHEL build, prolly soon.
Needinfo until someone tells me whether rpm is to be built for RHEL.
Maybe this isn't the right place to ask, but is there any chance of an update coming for Red Hat Linux 9 or for Fedora Core 1?
I have an x86_64 system that reliably shows similar behavior, no need to run rpm several times to see each error. # rpm -ih -v -v kernel-2.4.21-9.0.1.EL.x86_64.rpm D: ============== kernel-2.4.21-9.0.1.EL.x86_64.rpm D: Expected size: 7152109 = lead(96)+sigs(180)+pad(4)+data(7151829) D: Actual size: 7152109 D: kernel-2.4.21-9.0.1.EL.x86_64.rpm: MD5 digest: OK (cc8ba3c9e807aad192e22be7fa904d93) D: added binary package [0] D: found 0 source and 1 binary packages D: opening db environment /var/lib/rpm/Packages joinenv D: opening db index /var/lib/rpm/Packages rdonly mode=0x0 D: locked db index /var/lib/rpm/Packages D: ========== +++ kernel-2.4.21-9.0.1.EL x86_64-linux 0x0 D: opening db index /var/lib/rpm/Depends create mode=0x0 D: Requires: rpmlib(VersionedDependencies) <= 3.0.3-1 YES (rpmlib provides) D: opening db index /var/lib/rpm/Providename rdonly mode=0x0 D: opening db index /var/lib/rpm/Pubkeys rdonly mode=0x0 D: read h# 1035 Header sanity check: OK D: ========== DSA pubkey id 219180cddb42a60e D: read h# 71 Header V3 DSA signature: OK, key ID db42a60e D: Requires: fileutils YES (db provides) Segmentation fault
Created attachment 97749 [details] strace of `rpm -ihvv` seg fault on x86_64 Appears slightly different than earlier strace output. If this seems like a different bug, I'll be glad to open another report.
The 2nd bbrock strace indicates segfault while accessing added Provides: and files table, different than the other strace. Was this rpm-4.2.x or rpm-4.3.x? There is 1 line fix in rpm-4.3.x that may be pertinent. So the hypothesis is that bug is in rpm-4.2.x, but not rpm-4.3.2 (as in fc3).
Closing due to inactivity. If this issue still occurs with current releases, please reopen and set the release in which you've encountered the problem.