Bug 183188 - NIS/YP repeated do_ypcall: clnt_call: RPC: Timed out errors
NIS/YP repeated do_ypcall: clnt_call: RPC: Timed out errors
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: ypbind (Show other bugs)
5
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Chris Feist
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-27 06:23 EST by Bevis King
Modified: 2010-09-15 16:43 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-10 20:45:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bevis King 2006-02-27 06:23:24 EST
Description of problem:
Any network tool (evolution, firefox, ssh) seems to cause a large number of
do_ypcall: clnt_call: RPC: Timed out errors when attempting any kind of remote
system access.  All nis test tools seem to work just fine - ie ypwhich, ypcat,
ypmatch all function normally.  The FC5t3 system has been configured with an
architecture independant RPM of config files which works fine on FC4 (and RHEL4
and FC3).  am-utils, built from an SRPM identical to that used on FC4 has also
been installed.  See strace below for additional information.

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

How reproducible:
All the time, for most internet accessing tools.

Steps to Reproduce:
1.  Access the network in a form that needs NIS and DNS lookups.
    ie: evolution &   or ssh -l user remote.host.co.uk
  
Actual results:
System generates a number of do_ypcall: clnt_call: RPC: Timed out errors before
finally completing the access, usually successfully, after an approximate 1-2
minutes delay.

Expected results:
Rapid name resolution and proceed.

Additional info:
This is a sample strace from ssh while this is happening:
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 ...>

This is the /etc/nsswitch.conf:
#  /etc/nsswitch.conf
passwd:     files compat
group:      nis files

hosts:      files nis dns

services:   files nis
networks:   nis [NOTFOUND=return] files
protocols:  files nis
rpc:        files nis
ethers:     nis [NOTFOUND=return] files
netmasks:   nis [NOTFOUND=return] files
bootparams: nis [NOTFOUND=return] files

netgroup:   nis
publickey:  nis

aliases:    files nis
Comment 1 Bevis King 2006-03-01 10:48:24 EST
Changing the hosts evaluation order in /etc/nsswitch.conf to:

         hosts:     files dns nis

significantly aleviates this problem.  Obviously though that doesn't help if you
want to use nis host lookups to override their world-view defaults.  It would
appear to point to this problem being purely in the host-lookup routines of NIS/yp.

Regards, Bevis.
Comment 2 Chris Feist 2006-06-15 11:50:37 EDT
Can you post your /etc/yp.conf file.  And let me know if you get any errors when
you run 'ypcat passwd'.

Can you also provide the output of 'ypmatch localhost hosts'.
Comment 3 Bevis King 2006-06-16 05:45:30 EDT
/etc/yp.conf contains:

# generated by /sbin/dhclient-script
domain eim server 131.227.2.10
domain eim server 131.227.2.15
domain eim server 131.227.2.11
domain eim server 131.227.4.22
domain eim server 131.227.74.3

% ypmatch localhost hosts
127.0.0.1 localhost loghost localhost.localdomain

NB: The machine is now running FC5 production.
Comment 4 Chris Feist 2006-06-16 11:41:07 EDT
With FC5 are you seeing any errors?  Also are the ypservers running FC5?
Comment 5 Bevis King 2006-06-28 10:49:05 EDT
The YP servers are variously Solaris 9 or RHEL4.
Comment 6 Timmy Gregers Madsen 2006-07-17 04:48:55 EDT
I have a setup with NIS servers based on FreeBSD with fp and fc5 NIS clients.

I updated some clients and found that kernel.x86_64 2.6.16-1.2133_FC5 and 
kernel.x86_64 2.6.17-1.2157_FC5 differs regarding ypbind.

The pf allows incomming to port 111 which works find with ypbind and 
kernel.x86_64 2.6.16-1.2133_FC5.

With kernel.x86_64 2.6.17-1.2157_FC5 port assignment in the range 900-1023 has 
to be allowed as the client timeout on yp with port 111 only.

I assume thats the reason for the timeouts, some thing got br0ken in the 
rpcbind on port 111 from the client.
Comment 7 Matthew Miller 2007-04-06 13:28:53 EDT
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer
test releases. We're cleaning up the bug database and making sure important bug
reports filed against these test releases don't get lost. It would be helpful if
you could test this issue with a released version of Fedora or with the latest
development / test release. Thanks for your help and for your patience.

[This is a bulk message for all open FC5/FC6 test release bugs. I'm adding
myself to the CC list for each bug, so I'll see any comments you make after this
and do my best to make sure every issue gets proper attention.]
Comment 8 petrosyan 2008-03-10 20:45:43 EDT
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested, 
please feel free to reopen the bug report.

Thank you in advance.
Comment 9 max 2010-09-15 16:43:29 EDT
problem resolved for me by eliminating the following firewall rule in /etc/sysconfig/iptables and restarting iptables:

# -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

my older linux box did not have any rules set on the firewall chain.  This also cleared up slow responses to login and a timeout against one of my nfs servers.

Since this server is behind my firewall I'm not too concerned about disabling a rule.  I should probably just turn off iptables altogether.  Your situation maybe different.

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