do_ypcall: clnt_call: RPC: Timed out

Question

faulters:

Despite much troubleshooting in my NIS/YP setup, rebooting systems, restarting & debugging ypbind, putting nscd to run, a group of newly purchased systems regularly spam my email with:

do_ypcall: clnt_call: RPC: Timed out
do_ypcall: clnt_call: RPC: Timed out
do_ypcall: clnt_call: RPC: Timed out

However, the users are (apparently) not affected by this - they can access network resources. Otherwise I would have a line of users in front of my door complaining... :). This has been mostly an annoyance by now, but how can I get rid of it ?

Machines of other hardware specs (older, quad cores, duo cores) having exactly the same managed configuration just do well - almost never showing this kind of behavior.

I am on Fedora 17/64 on (pretty recent) Dell Optiplex 9010 machines with good RAM, disk etc. The NIS/YP server is on CentOS, and other critical network resources that rely on it do just fine.

Any hints ? Thanks.

Solution 1

In my case system was doing hostlookup. In my /etc/nsswitch.conf file, hosts line was:

hosts: files nis dns

I have changed this hosts line to:

hosts: files dns [NOTFOUND=return]

I am always using DNS for host records, not NIS hosts.byname etc.

Solution 2

Without knowing what you've checked, here is a stab in the dark:

• Check the status of the rpcbind service.
• What does /etc/nsswitch.conf look like on the client?
• Check all your maps (which are in use per nsswitch) with yptest -m.
• ypmatch localhost hosts

Solution 3

I ran into this same issue running FreeBSD 9 and 10. The issue happens on both Dell Optiplex 990s and 9010s. We have older Optiplex 960s and newer Optiplex 9020s that dont have the problem. I was only able to solve the problem by disabling the internal Intel NIC and using a different PCI NIC card. Updating the Dell BIOS on both the 990s and 9010s did not help. This issue happens with running FreeBSD native as well as under VMware vmplayer and VirtualBox on a windows 7 host OS. I believe it is a NIC firmware/driver issue dealing with udp packets.

Dan

Comments

[Aaron Copley]

I usually see this when rpcbind is not started. But, like you said, there should be a line out the door... We need to know what you've checked already. Please provide more info.