Bug 83630 - up2date is hung while attempting to upgrade packages
up2date is hung while attempting to upgrade packages
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
8.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-06 10:35 EST by Michael Lee Yohe
Modified: 2007-04-18 12:50 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-20 16:01:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Michael Lee Yohe 2003-02-06 10:35:23 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030102

Description of problem:
I was attempting to run up2date to grab the latest updates to openldap and php.
 While doing this, up2date successfully downloaded the files, and began
installing them:

# up2date -u

Fetching package list for channel: redhat-linux-i386-8.0...
########################################

Fetching Obsoletes list for channel: redhat-linux-i386-8.0...
########################################

Fetching Obsoletes blacklist for channel: redhat-linux-i386-8.0...
########################################

Fetching rpm headers...
########################################

Testing package set / solving RPM inter-dependencies...
########################################
openldap-2.0.27-2.8.0.i386. ########################## Done.                   
openldap-devel-2.0.27-2.8.0 ########################## Done.                   
php-4.2.2-8.0.7.i386.rpm:   ########################## Done.                   
php-imap-4.2.2-8.0.7.i386.r ########################## Done.                   
php-ldap-4.2.2-8.0.7.i386.r ########################## Done.                   
php-mysql-4.2.2-8.0.7.i386. ########################## Done.                   
php-pgsql-4.2.2-8.0.7.i386. ########################## Done.                   
Preparing              ########################################### [100%]

Installing...
   1:openldap               ########################################### [100%]
   2:openldap-devel         ########################################### [100%]
   3:php                    ########################################### [100%]
   4:php-imap               ########################################### [100%]
   5:php-ldap               ########################################### [100%]
   6:php-mysql              ########################################### [100%]

[2]+  Stopped                 up2date -u
# bg
[2]+ up2date -u &
# ps ax | grep up2date
 5859 pts/4    S      0:00 up2date -u
 5860 pts/4    S      0:00 /usr/sbin/userhelper -w up2date -u
 5863 pts/4    S      0:14 /usr/bin/python -u /usr/sbin/up2date -u
 5891 pts/4    D      0:00 grep up2date
# strace -p 5863
pause(

The pause statement is the last thing that appears in strace peek on the up2date
PID - no other messages are generated.  "rpm" can still query the RPM database,
as I was able to retrieve the package release for up2date.


Version-Release number of selected component (if applicable):


How reproducible:
Didn't try

Steps to Reproduce:
1. see description
    

Additional info:

$ rpm -q up2date
up2date-3.1.9-1
Comment 1 Adrian Likins 2003-02-07 12:49:10 EST
trying to duplicate this at the moment...

Comment 2 Michael Lee Yohe 2003-02-07 13:25:27 EST
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.
Comment 3 Jim Richardson 2003-02-09 13:16:33 EST
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 
Comment 4 Dale R. Worley 2003-02-11 00:11:53 EST
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.
Comment 5 Eric K. Olson 2003-06-04 16:30:06 EDT
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.


Comment 6 Dale R. Worley 2003-06-12 14:35:32 EDT
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.
Comment 7 Mike Wright 2003-06-28 22:39:24 EDT
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.
Comment 8 Ramazan Jah-Far 2003-09-25 20:29:09 EDT
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...
Comment 9 Dale R. Worley 2003-09-26 23:44:02 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.