Bug 90996

rhnsd is running

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

check hostname used to contact rhn in /etc/sysconfig/rhn/up2date

Versions in 7.1 should be attempting to reach

www.rhns.redhat.com

The error seemed to indicate a DNS error. Verify that
you can ping www.rhns.redhat.com

/etc/sysconfig/rhn/up2date contains




serverURL=https://www.rhns.redhat.com/XMLRPC




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

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,


Thanks

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 217.169.25.210 to 217.169.25.210 
asking for the IP address of pro.spicedreams.com and gets the response back from 
217.169.25.210 that the answer is "CNAME spicedreams.com A 217.169.25.210".




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




Almost immediately, 127.0.0.1 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?

Guys, could you give me some idea how to progress this please?

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
ory)

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
ory)
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
 directory)
open("/usr/lib/python1.5/exceptions.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/python1.5/exceptionsmodule.so", O_RDONLY) = -1 ENOENT (No such fi
le or directory)

Does this help?

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).

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. 

Thanks.

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?