Problems with NIS/YP and seemingly endless do_ypcall: clnt_call: RPC: Timed out

[Bevis R W King]

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.

[Joe Orton]

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

[Bevis R W King]

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.