Bug 123189 - up2date does not do a full restart after updating itself
up2date does not do a full restart after updating itself
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: up2date (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-13 14:02 EDT by Bill Peck
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-27 18:32:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Peck 2004-05-13 14:02:00 EDT
Description of problem:
up2date does not fully restart itself after up2dating itself.  This
caused the gdb package to fail dependancy resolution since the new
up2date was required. Quiting up2date and restarting allowed the gdb
update to install since now the new up2date code was running.

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

How reproducible:
Everytime

Steps to Reproduce:
1. Install rhel3-U1-ppc-as
2. depending on where the new gdb package is you may need to point to
rhn.webqa
3. Running up2date -u from the command line will not even try to
update up2date.
4. Running up2date via the GUI will prompt for 
  
Actual results:

When running from the GUI..

[root@pseries rhn]# ps auxw| grep up2date
root      2374 32.3  0.5 60200 43456 pts/0   S    13:52   0:07
/usr/bin/python -u /usr/sbin/up2date
root      2376  0.0  0.0  3880  732 ttyS0    S    13:52   0:00 grep
up2date

after up2date updated itself its still running with the same pid.

[root@pseries rhn]# ps auxw| grep up2date
root      2374 17.9  0.3 45724 28824 pts/0   S    13:52   0:22
/usr/bin/python -u /usr/sbin/up2date
root      2397  0.0  0.0  3880  732 ttyS0    S    13:54   0:00 grep
up2date


When running from the TUI..

[root@pseries rhn]# up2date -u --dry-run
 
Fetching package list for channel: rhel-ppc-as-3...
########################################
 
Fetching Obsoletes list for channel: rhel-ppc-as-3...
########################################
 
Fetching rpm headers...
########################################
 
Name                                    Version        Rel
----------------------------------------------------------
GConf2                                  2.2.1          4             
   ppc
GConf2-devel                            2.2.1          4             
   ppc
MAKEDEV                                 3.3.12         1             
   ppc
SysVinit                                2.85           4.2           
   ppc

<snip>

up2date                                 4.2.15         1             
   ppc
up2date-gnome                           4.2.15         1             
   ppc
vsftpd                                  1.2.1          3             
   ppc
xemacs                                  21.4.13        8.ent         
   ppc
xemacs-el                               21.4.13        8.ent         
   ppc
xemacs-info                             21.4.13        8.ent         
   ppc
ypserv                                  2.8            6             
   ppc
 
 
Testing package set / solving RPM inter-dependencies...
########################################
RPM package conflict error.  The message was:
Test install failed because of package conflicts:
The following packages were added to your selection to satisfy
dependencies:
Name                                    Version        Release
--------------------------------------------------------------
laus-libs                               0.1            56RHEL3
laus-libs                               0.1            56RHEL3
 
file /usr/share/info/annotate.info.gz from install of
gdb-6.0post-0.20040223.20 conflicts with file from package
gdb64-6.0post-0.20031117.6
file /usr/share/info/gdb.info-1.gz from install of
gdb-6.0post-0.20040223.20 conflicts with file from package
gdb64-6.0post-0.20031117.6
file /usr/share/info/gdb.info.gz from install of
gdb-6.0post-0.20040223.20 conflicts with file from package
gdb64-6.0post-0.20031117.6
file /usr/share/info/gdbint.info-1.gz from install of
gdb-6.0post-0.20040223.20 conflicts with file from package
gdb64-6.0post-0.20031117.6
file /usr/share/info/gdbint.info.gz from install of
gdb-6.0post-0.20040223.20 conflicts with file from package
gdb64-6.0post-0.20031117.6
file /usr/share/info/stabs.info-1.gz from install of
gdb-6.0post-0.20040223.20 conflicts with file from package
gdb64-6.0post-0.20031117.6
file /usr/share/info/stabs.info.gz from install of
gdb-6.0post-0.20040223.20 conflicts with file from package
gdb64-6.0post-0.20031117.6
 

Expected results:
up2date should upgrade itself first in both GUI and TUI mode.
and when it does restart it should actually be executing the updated code.

Additional info:

One thing I noticed is that when running up2date for the second time
it shows both the ppc and ppc64 versions of gdb in the upgrade list. 
Before the update of up2date it only showed the ppc version.
Comment 1 Adrian Likins 2004-05-13 14:10:27 EDT
>up2date should upgrade itself first in both GUI and TUI mode.
>and when it does restart it should actually be executing the updated
>code.

4.2.16 should do this now. I reverted back to the old fork/exec
based restart instead of the execvp based one that seemed to be
causing issue, though I'm not actually sure why that wouldn't
work (it should keep the same pid, but completely replace the image...)

>One thing I noticed is that when running up2date for the second time
>it shows both the ppc and ppc64 versions of gdb in the upgrade list. 
>Before the update of up2date it only showed the ppc version.

Yup, thats the bug fix from 4.2.15. To solve the obsolete, it is
neccesary to upgrade the installed gdb.ppc, as well as install
a new gdb.ppc64. Hence both showing up in the upgrade list. 
Comment 2 Adrian Likins 2004-05-27 18:32:12 EDT
closing as fixed, though the fix did break some rhn_check
stuff which didnt get tested in time..., but alas...

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