Has anyone else seen a problem with NIS/YP on FC5test3 (x86_64 version, but probably generic) generating almost endless error messages of:
do_ypcall: clnt_call: RPC: Timed out
The weirdest part is that all the YP tools themselves respond almost instantly - as in ypwhich, ypcat, ypmatch - and can read all the maps I can think of. However, something simple like an ssh connect to a remote site comes back as:
% ssh -l user remote.domain.co.uk do_ypcall: clnt_call: RPC: Timed out do_ypcall: clnt_call: RPC: Timed out do_ypcall: clnt_call: RPC: Timed out do_ypcall: clnt_call: RPC: Timed out do_ypcall: clnt_call: RPC: Timed out
This system is out-of-the-box FC5t3 configured with an rpm of architecture independent config files that works perfectly on FC4. The only other addition is am-utils installed onto it in addition in order to access our fileserver maps. This was built from the source RPM that builds/works fine on FC4.
Running an strace on it shows this cycle repeating almost endlessly - I switched off selinux in case it was screwing things up (I've substituted our real NIS server address with 192.168.0.10 in the logs for obvious security reasons):
gettimeofday({1140790145, 273244}, NULL) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 6 bind(6, {sa_family=AF_INET, sin_port=htons(680), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EACCES (Permission denied) ioctl(6, FIONBIO, [1]) = 0 setsockopt(6, SOL_IP, IP_RECVERR, [1], 4) = 0 fcntl(6, F_SETFD, FD_CLOEXEC) = 0 close(5) = 0 sendto(6, "sB\223z\0\0\0\0\0\0\0\2\0\1\206\244\0\0\0\2\0\0\0\3\0\0"..., 96, 0, {sa_family=AF_INET, sin_port=htons(1023), sin_addr=inet_addr("192.168.0.10")}, 16) = 96 poll([{fd=6, events=POLLIN}], 1, 5000) = 0 socket(PF_NETLINK, SOCK_RAW, 0) = 5 bind(5, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(5, {sa_family=AF_NETLINK, pid=17040, groups=00000000}, [17127303594660331532]) = 0 time(NULL) = 1140790150 sendto(5, "\24\0\0\0\22\0\1\3\206\23\377C\0\0\0\0\0\20\36\355", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\350\0\0\0\20\0\2\0\206\23\377C\220B\0\0\0\0\4\3\1\0 \0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 700 recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\206\23\377C\220B\0\0\0\0\0\0\1\0\0 \0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 sendto(5, "\24\0\0\0\26\0\1\3\207\23\377C\0\0\0\0\0\20\36\355", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"<\0\0\0\24\0\2\0\207\23\377C\220B\0\0\2\10\200\376\1 \0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 128 recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0\207\23\377C\220B\0\0\n\200\200\376\1 \0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 128 recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\207\23\377C\220B\0\0\0\0\0\0\1\0\0 \0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 brk(0x5555556e3000) = 0x5555556e3000 close(5) = 0 brk(0x5555556e2000) = 0x5555556e2000 sendto(6, "sB\223z\0\0\0\0\0\0\0\2\0\1\206\244\0\0\0\2\0\0\0\3\0\0"..., 96, 0, {sa_family=AF_INET, sin_port=htons(1023), sin_addr=inet_addr("192.168.0.10")}, 16) = 96 poll( <unfinished ...>
Any thoughts on this?
Regards, Bevis.
On Mon, Feb 27, 2006 at 10:59:25AM +0000, Bevis R W King wrote:
Has anyone else seen a problem with NIS/YP on FC5test3 (x86_64 version, but probably generic) generating almost endless error messages of:
do_ypcall: clnt_call: RPC: Timed out
I had a similarly weird NIS problem with a Raw Hide install of a few weeks ago. In my case (see the mail archive) ypbind would never receive anything from the server at all, so failed to bind, logging that same RPC timeout message. I take it that much does work reliably for you?
I've since re-installed the box from a newer Raw Hide and it "Just Works" again. FWIW, package versions are now:
ypbind-1.19-0.i386 glibc-2.3.90-38.i686 kernel-2.6.15-1.1915_FC5.i686
joe
Joe
On Mon, 2006-02-27 at 15:34 +0000, Joe Orton wrote:
I had a similarly weird NIS problem with a Raw Hide install of a few weeks ago. In my case (see the mail archive) ypbind would never receive anything from the server at all, so failed to bind, logging that same RPC timeout message. I take it that much does work reliably for you?
I don't think that's the problem because then the other yp tools would not work perfectly. But they do - ypwhich, ypcat, ypmatch all seem to work just fine and at normal speed. I've tried it with and without nscd running.
ypbind-1.19-0.i386
This is the version I'm running.
glibc-2.3.90-38.i686 kernel-2.6.15-1.1915_FC5.i686
I'm looking at the nsswitch.conf again - I'm wondering if the nis lookup of hosts is broken in some way - that would explain the eventual success, ie once the NIS has timed out. I'll try putting the entries as:
files dns nis instead of: files nis dns
This is not ideal for us because there are things in our nis hosts tables which we don't necessarily make externally visible through the DNS - mostly service based aliases.
Regards, Bevis.
-
Bevis R W King -
Joe Orton