Bug 83630

trying to duplicate this at the moment...

I don't know if it will be easy to duplicate - since I have not had problems
with up2date before, I never run it through strace to capture the system
messages generated during execution.  Next time there are packages released via
RHN, I'll capture the data just in case.

Although I wasn't as knowledgeable about gathering info, I have attempted the
recent updates on two different 8.0 machines with very similar profiles. Each
one hung. Each one hung following the last package that needed to be updated. In
one that was php-mysql and the other was php-ldap. The second machine didn't
have my-sql installed.

I have a third machine nearly identical to the second. Both are on nearly
identical hardward. You are welcome to use it to gather info if you think it can
be done without destroying the sytem. :)

If updated today it would require:
Fetching rpm headers...
###################################
Name                                    Version        Rel     
----------------------------------------------------------
kernel                                  2.4.18         24.8.0              
krb5-devel                              1.2.5          8                   
krb5-libs                               1.2.5          8                   
openldap                                2.0.27         2.8.0               
openldap-devel                          2.0.27         2.8.0               
php                                     4.2.2          8.0.7               
php-imap                                4.2.2          8.0.7               
php-ldap                                4.2.2          8.0.7 

The up2date automatic update program that is shipped with Red Hat Linux 8.0
appears to have some problems that lead to it hanging when attempting to update
the system. This is a summary of the symptoms I have observed.  The attachments
are linked to from the Web version of this comment,
http://world.std.com/~worley/notes/up2date.html.

My system is Red Hat Linux 8.0, with few modifications from a "standard"
installation out of the box. I had just registered for the up2date service. The
first time I attempted to execute up2date, it downloaded all the required RPMs.
Then it started installing "Canna". At that point, up2date appeared to hang.

After some searching, I found bug report 83630 on bugzilla.redhat.com for a
similar problem.

After killing the up2date process and rebooting, I ran up2date a second time,
this time using strace to get a trace of its activities. The download process
appeared to fetch the same RPMs, with the notable absence of an update to
"Canna", the first RPM fetched in the previous execution of up2date. (This
suggests that the installation of Canna was successful.) up2date reported that
it installed "Canna-devel" and "Canna-libs" and then appeared to hang.

Here is the shell log (as captured in an Emacs shell window). I have marked the
location where up2date was seen to hang.

ps reported that up2date was sleeping, with a defunct shell subprocess. I then
tried to kill it, first with SIGTERM (twice), and then with SIGKILL.

strace produced three traces. Two of them were for subprocesses, PIDs 4580 and
4581. The third was for the main process itself. That trace was very large,
almost 2 GB. The gzip'ed version is here. I've extracted the last 1000 lines,
and marked the location where up2date was seen to hang.

I had a nearly identical behavior on a system running RedHat 8.0.

It turned out that the rpm database (according to rpm -qa) had both
php-ldap-4.2.2-8.0.5 AND php-ldap-4.2.2-8.0.7 listed as installed.  I'm
pretty sure I didn't install them both-- I suspect some misconfiguration
caused this to happen.  This RPM contains only a single file and a script.

I removed php-ldap-4.2.2-8.0.7 and then allowed up2date to update the
remaining php-ldap-4.2.2-8.0.5 to php-ldap-4.2.2-8.0.7 and it worked,
and up2date stopped hanging.

After reading "Additional Comment #5 From Eric K. Olson", I checked my rpm -qa
and found the following packages that appear to be installed in multiple versions:

Canna-3.5b2-70
Canna-3.5b2-70.8.0.1
Canna-devel-3.5b2-70.8.0.1
Canna-libs-3.5b2-70
Canna-libs-3.5b2-70.8.0.1

cvs-1.11.2-5
cvs-1.11.2-8

ggv-1.99.9-4
ggv-1.99.9-5

tetex-1.0.7-57
tetex-1.0.7-57.1
tetex-afm-1.0.7-57
tetex-doc-1.0.7-57
tetex-dvips-1.0.7-57
tetex-dvips-1.0.7-57.1
tetex-fonts-1.0.7-57
tetex-latex-1.0.7-57
tetex-xdvi-1.0.7-57

wget-1.8.2-3
wget-1.8.2-5

xinetd-2.3.7-2
xinetd-2.3.7-5

Whether these cause the up2date hang, or are caused by it, I don't know.  I will
attempt to remove the latest versions and get up2date to update them, as Eric did.

I just tried to run up2date to fetch and install all the recent XFree stuff. It
hung up and now I find I've got XFree86-4.2.0-72 and -4.2.1-20, plus I've got a
mix of fonts. There are still various associated XF86 rpm's left to install but
now the dependencies are out of whack.

I think this is not up2date's bug. I saw this during massive
upgrade of RH8.0 with `rpm -Fvh i386/*.rpm noarch/*.rpm`

I did this after installing RH 8.0 from CD. I ran rpm in local
FS mirror of RedHat's updates ftp.

After that I got packages with multiple versions installed.
I was forced to manually ran rpm -Uvh --force in correct order
and use --nodeps 2 or 3 times to fix the disaster.

Second time I saw this problem during upgrading of XFree86.

It looks like rpm hangs while waiting for a preinstall(?)
scriptlet to complete.

P.S. Last upgrade of perl packages passed smoothly...

After reading Comment #8 From Ramazan Jah-Far, let me recount my attempt to fix
the broken up2date:

First, I removed (rpm --erase) the older copies of packages which were present
in more than one version.

/var/spool/up2date contained many packages to install.  I installed them
individually, or in small groups as needed to satisfy the dependencies.  As I
installed packages, I deleted the RPMs from /var/spool/up2date.

I believe that I also ran 'rpm --rebuilddb' at least once, and at some time had
to reboot the system (perhaps to clear a lock?).

After taking care of the updates in /var/spool/up2date, I re-ran up2date, which
worked OK.

These suggest that the problem lies in RPM executing a massive set up upgrades.
 Users encountering this problem again should snapshot the RPMs in their
database (rpm --query --all) and the names of the RPMs in /var/spool/up2date. 
That might allow the problem to be reconstructed.