Bug 73480

Summary: rhn-applet stops working afer changing network
Product: Red Hat Enterprise Linux 4 Reporter: Gerald Teschl <gt>
Component: rhn-appletAssignee: Robin Norwood <robin.norwood>
Status: CLOSED WONTFIX QA Contact: desktop-bugs <desktop-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.4CC: aleksey, notting, wtogami
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 16:17:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Gerald Teschl 2002-09-05 07:53:48 UTC
I just turned up my laptop at home and changed the
network settings. However, rhn-applet stoped working
and keeps complaining that it cannot resolve host names
even after the network is up and working again.
(network error -5: temporary failure in name resolution)

I had to quit+start the applet to make it work again.

Comment 1 Gerald Teschl 2002-09-12 15:52:40 UTC
Same problem when I suspend/resume the laptop (without changing network
configs).

Comment 2 Aleksey Nogin 2002-09-12 17:58:36 UTC
Same here.

Comment 3 Aleksey Nogin 2003-01-17 01:29:05 UTC
With rhn-applet-2.0.7-1 in Phoebe, I still see that once it went into the "grey
question mark" state, it does not seem to be trying to contact RHN anymore (and
the "Check for Updates" item in the right-click menu is greyed out).

Comment 4 Gerald Teschl 2003-04-08 18:28:49 UTC
Still broken in rhn-applet-2.0.9-0.9.0.1

Comment 5 Daniel Veillard 2003-04-09 08:49:51 UTC
The DNS should be refreshed at the libc level. If the problem is really
related to DNS lookup as in your initial problem I don't see what I can do.
The python applet layers uses glibc DNS entry points. Provide a more complete
trace if you think it's related to the applet code.
I have tried once changing network and it worked for me, so I don't
understand. Are other network oriented applications refreshing their DNS
cache and able to perform correct lookup ? I know no libc nor Python API
to indicate at the application level that a DNS change occured and that
any existing DNS informations need to be flushed.

Daniel

Comment 6 Gerald Teschl 2003-04-09 21:12:15 UTC
Ok, I just tested this again:

1) started applet at work (everything ok)
2) suspended laptop
3) resumed laptop at home and changed network numbers
  (networing works 100%, host rhn.redhat.com showns that rhn
  resolves just fine)
4) rhn-applet is gray with red slash; upon clickin on it a
   window "Network error -2: Name or service not known" pops up.

Quitting and starting the applet seems the only way to make it work again.

This is 100% reprodicible for me.

Comment 7 Gerald Teschl 2003-04-09 21:16:16 UTC
Just did some furhter investigations with lsof:

It still tries to open a connection to the old nameserver
(which is in a private lan and cannot be accessed).

Looks like it reads the info from /etc/resolve.conf only once
and caches it.

Comment 8 Daniel Veillard 2003-09-28 19:19:03 UTC
I tried to check how to get the DNS info refreshed in Python, I could not
find any ways to force this. This is supposed to use the libc and glibc
does it correctly...

Daniel

Comment 9 Bill Nottingham 2006-08-05 05:11:53 UTC
Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.

Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.

If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been
provided.

If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.

Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.


Comment 10 Aleksey Nogin 2006-10-17 20:24:40 UTC
I am not 100% certain, but I believe I still expeienced this problem under Red
Hat Enterprize Linux 4.

Comment 11 Robin Norwood 2006-10-18 01:23:44 UTC
Ok, I'll take a look.

Comment 12 Red Hat Bugzilla 2007-04-12 00:06:20 UTC
User bnackash's account has been closed

Comment 13 Jiri Pallich 2012-06-20 16:17:06 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.