Bug 90996 - up2date doesn't attempt to connect to host
up2date doesn't attempt to connect to host
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
Depends On:
  Show dependency treegraph
Reported: 2003-05-16 04:46 EDT by Graham Harris
Modified: 2007-04-18 12:53 EDT (History)
3 users (show)

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

Attachments (Terms of Use)

  None (edit)
Description Graham Harris 2003-05-16 04:46:20 EDT
Description of problem:
up2date (command line) fails with 
"Error communicating with server.  The message was:
host not found".

up2date-gnome fails silently- no GUI appears.

In neither case is any traffic sent to the default IP route (as seen by 
Ethereal monitoring eth0
'route' shows this default route 

default    zlan         UG    0      0        0 eth0

and there are no other routes which could lead to redhat.com

up2date-gnome has been working successfully for a long while, stopped 10 
days or so ago. Touch anything? Moi?

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

How reproducible:
Every time.

Steps to Reproduce:
1. Start Ethereal, start capturing on eth0
2. run up2date or up2date-gnome
3. wait for finish (dwell a decent pause for up2date-gnome) and stop capture
Actual results:
no traffic seen.

Expected results:
some https traffic in both directions

Additional info:
I can telnet from the affected host to the RHN server specified using 
up2date --configure

telnet www.rhns.redhat.com 443
Connected to www.rhns.redhat.com.
Escape character is '^]'.

My ISP reputedly does no filtering in or out
Comment 1 Graham Harris 2003-05-16 04:51:06 EDT
rhnsd is running

RHN says that "System not checking in with RHN" since 2003-05-06 20:31:37 (EST)

Comment 2 Mark J. Cox (Product Security) 2003-05-16 06:21:45 EDT
check hostname used to contact rhn in /etc/sysconfig/rhn/up2date
Comment 3 Adrian Likins 2003-05-16 14:44:39 EDT
Versions in 7.1 should be attempting to reach


The error seemed to indicate a DNS error. Verify that
you can ping www.rhns.redhat.com
Comment 4 Graham Harris 2003-05-18 05:47:40 EDT
/etc/sysconfig/rhn/up2date contains


As above, I can 'telnet www.rhns.redhat.com 443'. I cannot 'ping www.rhns.
redhat.com' which I put down to that host refusing to respond to a ping, since 
telnet works. Anyway it can't be a DNS problem if telnet works. 

up2date still fails the same way

Thanks for your interest

Comment 5 Graham Harris 2003-05-30 14:11:39 EDT
I can also open the serverURL https://www.rhns.redhat.com/XMLRPC in my web 
browser. I get a "Method not allowed" page. Ethereal logs the transaction in 17 
packets (well, frames, to be pedantic).

Just to reiterate then: I can contact the server by many means from the same 
machine. up2date on the other hand does not contact the server- Ethereal cannot 
find any evidence that up2date is making any attempt to contact the server.

Hope you can help,

Comment 6 Graham Harris 2003-06-12 16:32:00 EDT
I made ethereal look for traffic on any interface, not just the one that ought 
to forward traffic to the internet. "up2date" at the command line seems to 
generate a DNS query for "pro.spicedreams.com" which is the name of my system. 
It's a real global DNS name, for which my system is itself authoritative. So it 
looks like up2date sends a DNS query from to 
asking for the IP address of pro.spicedreams.com and gets the response back from that the answer is "CNAME spicedreams.com A".

This is repeated verbatim about 28 seconds later (first time I tried- next time 
this step was omitted). 

Almost immediately, tries to open a connection to port 512 on 127.0.0.
1 and gets "destination unreachable" in response. Might be unconnected with the 
foregoing- is this something you would expect from up2date, if so do I need to 
look at firewall rules again?

"update agent" in gnome doesn't appear even to generate this much traffic. 

Any suggestions as to what I can try next? 

I'm anxious the system doesn't get too far behind the pack. Is there a way I can 
diagnose the problem further, or update without up2date?

Comment 7 Graham Harris 2003-07-27 15:12:10 EDT
Guys, could you give me some idea how to progress this please?

Comment 8 Graham Harris 2003-10-06 15:31:50 EDT
OK, using strace the problem seems to be that a bunch of python source files are 
not found: 

readlink("/usr/bin/python", 0xbfffe030, 1024) = -1 EINVAL (Invalid argument)

exists, is the default python executable

stat64("/usr/bin/Modules/Setup", 0xbfffde80) = -1 ENOENT (No such file or direct

There is a /usr/lib/python1.5/config/Setup but no /usr/bin/Modules/Setup

stat64("/usr/bin/lib/python1.5/string.py", 0xbfffde60) = -1 ENOENT (No such file
 or directory)
stat64("/usr/bin/lib/python1.5/string.pyc", 0xbfffde60) = -1 ENOENT (No such fil
e or directory)

These two are actually in /usr/lib/python1.5 not /usr/bin/lib/python1.5

stat64("/usr/lib/python1.5/string.py", {st_mode=S_IFREG|0644, st_size=15430, ...
}) = 0
stat64("/usr/bin/Modules/Setup", 0xbfffde90) = -1 ENOENT (No such file or direct
stat64("/usr/bin/lib/python1.5/lib-dynload", 0xbfffde90) = -1 ENOENT (No such fi
le or directory)
stat64("/usr/lib/python1.5/lib-dynload", {st_mode=S_IFDIR|0755, st_size=4096, ..
.}) = 0
brk(0x80b5000)                          = 0x80b5000
stat64("/usr/lib/python1.5/exceptions", 0xbfffd9d0) = -1 ENOENT (No such file or
open("/usr/lib/python1.5/exceptions.so", O_RDONLY) = -1 ENOENT (No such file or
open("/usr/lib/python1.5/exceptionsmodule.so", O_RDONLY) = -1 ENOENT (No such fi
le or directory)

Does this help?
Comment 9 Graham Harris 2003-10-09 07:42:21 EDT
Problem understood now.

It seems up2date REQUIRES nscd, which wasn't installed. Nothing else seems to 
require nscd, so everything apart from up2date continued working when nscd got 
removed from the system (it was not obvious that it was useful since gnoRPM says 
just that it "improves performance"). 

And when nscd is missing, up2date fails silently (gnome) or with an unhelpful 
error (cli).
Comment 10 Adrian Likins 2003-10-21 21:35:26 EDT
up2date nor anything else should require "nscd". I dont run
it on any of the systems I use.

Generally if something works with nscd, but fails without it,
it indicates DNS/name resolution confiration issues of some
sort. nscd just caches DNS and name services queries locally,
so I have no idea what the correlation would be. 
Comment 11 Graham Harris 2003-10-26 15:48:24 EST

nscd seems to be the determinant. If nscd really is only caching then up2date 
has a real dependance upon it. If up2date has no dependance on nscd as you 
suggest, then nscd is masking an underlying dns config problem, ie nscd is not 
transparently caching.

How do we progress this? Redhat seems to blame the nscd maintainers- a tough 
call, given that you claim nscd is not necessary yet if nscd is absent, up2date 
fails. Do you want to raise it with the nscd folks?

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