Bug 83359 - Socket to xmlrpc.rhn leaked for each package downloaded
Socket to xmlrpc.rhn leaked for each package downloaded
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: rhnlib (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mihai Ibanescu
Fanny Augustin
:
Depends On:
Blocks: 79579
  Show dependency treegraph
 
Reported: 2003-02-03 04:57 EST by Jon Burgess
Modified: 2007-04-18 12:50 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-07-08 15:18:04 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 Jon Burgess 2003-02-03 04:57:37 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030120

Description of problem:
I installed Phoebe-8.0.93 and then ran up2date and downloaded the 20+ updates
which are available. During the long time that it tooks to install the packages
I noticed that the up2date process had one socket open for each of the packages
that it had downloaded (even though he download had long since finished).

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

How reproducible:
Always

Steps to Reproduce:
1. Run up2date 
2. Download one of more packages to be updated (may need to specifically
downgrade some packages so that some updates become available).
3. Up2date downloads the packages & gets to the "Ready to install" page
4. Run netstat or look at /proc/<PIDOF(up2date)>/fd
    

Actual Results:  Lots of sockets are still open to xlmrpc.rhn:
# netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp       30      0 161.xx.xx.22:33419      xmlrpc.rhn.redhat:https CLOSE_WAIT
tcp       30      0 161.xx.xx.22:33418      xmlrpc.rhn.redhat:https CLOSE_WAIT
tcp       30      0 161.xx.xx.22:33417      xmlrpc.rhn.redhat:https CLOSE_WAIT
tcp       30      0 161.xx.xx.22:33416      xmlrpc.rhn.redhat:https CLOSE_WAIT
....
/proc/<PID/fd
total 0
lrwx------    1 root     root           64 Jan 31 09:48 0 -> /dev/pts/1
lrwx------    1 root     root           64 Jan 31 09:48 1 -> /dev/pts/1
lrwx------    1 root     root           64 Jan 31 09:48 10 -> /var/lib/rpm/Pubkeys
lrwx------    1 root     root           64 Jan 31 09:48 100 -> socket:[136247]
lrwx------    1 root     root           64 Jan 31 09:48 101 -> socket:[136252]
lrwx------    1 root     root           64 Jan 31 09:48 102 -> socket:[136257]
lrwx------    1 root     root           64 Jan 31 09:48 103 -> socket:[136261]
lrwx------    1 root     root           64 Jan 31 09:48 104 -> socket:[136265]
...



Expected Results:  The socket connection with xmlrpc.rhn should be closed after
the package is downloaded. It looks like there are 30 bytes probably containing
some trailer or acknowkedgement from the server which up2date does not read.
Comment 1 Mihai Ibanescu 2003-02-03 18:56:55 EST
Will have to check.
Comment 2 Mihai Ibanescu 2003-02-18 18:18:26 EST
I was not able to duplicate this, will try some more.
Comment 3 Cristian Gafton 2003-02-18 19:23:08 EST
The CLOSE_WAIT state means that the sockets have been actually closed.
I am not able to replicate this either...
Comment 4 Mihai Ibanescu 2003-04-16 11:59:57 EDT
ping? Do you still see this issue?
Comment 5 Mihai Ibanescu 2003-07-08 15:18:04 EDT
Too old to be meaningful anymore. Please reopen if it still happens.

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