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
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.
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'.
/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.
With FC5 are you seeing any errors? Also are the ypservers running FC5?
The YP servers are variously Solaris 9 or RHEL4.
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.
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.]
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.
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.