Bug 104200
| Summary: | rhnsd or up2date process floods network | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Ian Hoyle <ian.hoyle> |
| Component: | up2date | Assignee: | Adrian Likins <alikins> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fanny Augustin <fmoquete> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | gafton, mihai.ibanescu |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-08-24 19:35:25 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: | |||
Can you tell us what version of up2date you are running? ("rpm -q up2date")
The version of up2date I'm running is [root@elmo root]# rpm -q up2date up2date-3.1.23.2-1 [root@elmo root]# Also, can you do: rpm -q rhnlib Does the problem exist if you run just up2date, or rhn_check? Hows up2date configured? proxy settings, etc? Havent ever seen any reports of this kind of behaviour before, and just setting it up to talk to a proxy doesnt show this for me. So I'm looking for any info that might be useful in reproducing this. What kind of proxy server? Any weird DNS or routing issues to keep in mind? firewall rules? [root@elmo root]# rpm -q rhnlib rhnlib-1.0-4 The Internet connection uses a proxy on port 8080. The proxy is a Network Appliance NetCache that is doing NTLM based auth. I had no problems using up2date (it runs fine manually) for a couple of weeks and browsing using Mozilla works also. My user credentials look like: user: domain\user password: somepassword It could have been rhn_check that was the culprit (run by rhnsd???). I can see these errors in the up2date log file: [Wed Sep 10 19:14:24 2003] up2date updating login info [Wed Sep 10 19:14:24 2003] up2date logging into up2date server [Wed Sep 10 19:14:51 2003] up2date A socket error occurred: (-3, 'Temporary failure in name resolution'), attempt #1 [Wed Sep 10 19:15:44 2003] up2date A socket error occurred: (-3, 'Temporary failure in name resolution'), attempt #1 [Wed Sep 10 19:16:16 2003] up2date A socket error occurred: (-3, 'Temporary failure in name resolution'), attempt #2 [Wed Sep 10 19:16:36 2003] up2date A socket error occurred: (-3, 'Temporary failure in name resolution'), attempt #3 [Wed Sep 10 19:16:39 2003] up2date A socket error occurred: (-3, 'Temporary failure in name resolution'), attempt #2 [Wed Sep 10 19:16:42 2003] up2date A socket error occurred: (-3, 'Temporary failure in name resolution'), attempt #4 [Wed Sep 10 19:16:42 2003] up2date A socket error occurred: (-3, 'Temporary failure in name resolution'), attempt #3 [Wed Sep 10 19:16:47 2003] up2date A socket error occurred: (-3, 'Temporary failure in name resolution'), attempt #5 [Wed Sep 10 19:16:47 2003] up2date Error communicating with server. The message was: Temporary failure in name resolution [Wed Sep 10 19:16:47 2003] up2date A socket error occurred: (-3, 'Temporary failure in name resolution'), attempt #4 [Thu Sep 11 00:42:14 2003] up2date updating login info [Thu Sep 11 00:42:14 2003] up2date logging into up2date server [Thu Sep 11 00:42:15 2003] up2date successfully retrieved authentication token from up2date server Perhaps the process got into a weird state in the presence of interrupted DNS resolution? Hope that helps. Removing security severity; This is not a security issue. There were some issues with up2adte and rhnlib that could cause behaviour of this sorts that has since been fixed (basically, being too aggressive retrying...) |
Description of problem: My up2date process seemed to stop part way through contacting RHN for new packages today. A few hours later I was contacted by my network team saying that my box was sending 1000's of packets at our corporate web proxy, opening but not closing sessions, looking like a denial of service attack: ### Ian, I think the workstation 134.18.124.31 may be sending a Dos at the Netcache. Below is some of the output from a netdiag. Can Network services block this IP from reacing the Netcache ???? The Netcache memory is being overloaded egards Nicholas msproxy7.8080 elmo.bhpbilliton.58913 5840 0 8593 0 CLOSE_WAI T msproxy7.8080 elmo.bhpbilliton.58912 5840 0 8593 0 CLOSE_WAI T msproxy7.8080 elmo.bhpbilliton.58911 5840 0 8593 0 CLOSE_WAI T msproxy7.8080 elmo.bhpbilliton.58910 5840 0 8593 0 CLOSE_WAI T msproxy7.8080 elmo.bhpbilliton.58909 5840 0 8593 0 CLOSE_WAI T msproxy7.8080 elmo.bhpbilliton.58908 5840 0 8593 0 CLOSE_WAI T msproxy7.8080 elmo.bhpbilliton.58907 5840 0 8593 0 CLOSE_WAI T msproxy7.8080 elmo.bhpbilliton.58906 5840 0 8593 0 CLOSE_WAI T msproxy7.8080 elmo.bhpbilliton.58905 5840 0 8593 0 CLOSE_WAI T msproxy7.8080 elmo.bhpbilliton.58904 5840 0 8593 0 CLOSE_WAI T msproxy7.8080 elmo.bhpbilliton.58903 5840 0 8593 0 CLOSE_WAI T msproxy7.8080 elmo.bhpbilliton.58902 5840 0 8593 0 CLOSE_WAI T msproxy7.8080 134.18.124.31.58901 5840 0 8593 0 CLOSE_WAIT msproxy7> msproxy7> #### Even after subsequent reboots the problem was still present. As soon as daemon started (I'm guessing rhnsd), the netwrk flooding started up again causing me to pull the plug (literally!!) from my box to the network. I have done a "chkconfig rhnsd off" and rebooted and the problem disappeared. Are there any issues/bugs with rhnsd that have been reported similar to this?? Ian -------------- Version-Release number of selected component (if applicable): How reproducible: until I turned off rhnsd, every time I rebooted. --------------- Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: