Bug 149886

Summary:	nis time out ypcall
Product:	Red Hat Enterprise Linux 3	Reporter:	Tobias Vogt <t.vogt>
Component:	yp-tools	Assignee:	Chris Feist <cfeist>
Status:	CLOSED WORKSFORME	QA Contact:	Jay Turner <jturner>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.0	CC:	pza, srevivo, steved
Target Milestone:	---
Target Release:	---
Hardware:	ia64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-03-08 22:03:36 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tobias Vogt 2005-02-28 16:43:48 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
When I run

'while true; do rsh <node> date; sleep 1; done'

it first runs without any problems and shows every second
the right time, but after a short while it hangs for some
time and following message is presented:

'o_ypcall: clnt_call: RPC: Timed out'

then the script runs on for some seconds or even minutes
and hangs again. I've tried this from / to different
Dell PowerEdges 3250 Server, problems regarding the yp
configuration havent been found, as of the normal usage
of yp works fine.

Version-Release number of selected component (if applicable):
yp-tools-2.8-6

How reproducible:
Always

Steps to Reproduce:
1. Run 'while true; do rsh <node> date; sleep 1; done' in a yp environment

  

Actual Results:  On irregular bases the message 'o_ypcall: clnt_call: RPC: Timed out' is presented.

Expected Results:  No errors, time from remote host should be shown every second.

Additional info:

Comment 1 Chris Feist 2005-03-08 20:36:11 UTC

Is your node in yp?

Ie. if you 'ypcat hosts | grep <node>' does anything show up?

What is in the hosts line in your nsswitch.conf file?

About how often does this happen?  Every 100 tries? Every 1000 tries?

Comment 2 Tobias Vogt 2005-03-08 21:52:34 UTC

Sorry for the dups, but the RHEL Issue 67292 covers the same problem.
I guess this bug could be closed.

Comment 3 Phil Anderson 2005-05-08 05:48:37 UTC

I'm getting the same problem in Fedora Core 3.  Has this issue been resolved?

Comment 4 Tobias Vogt 2005-05-09 18:08:41 UTC

The Problem I had, was that IPMI was enabled on my server, which listens on port
623 and 624 on the 1st onbord ethernet device. I'm using following work around
on both client and server side. I just inserted in /etc/xinetd.conf:

------------8<--- cut here --->8--------------
#
# bmc ipmi services
#
service unlisted
{
	type		    = UNLISTED
	socket_type	    = dgram
	protocol	    = udp
	wait		    = yes
	server		    = /bin/true
	port		    = 623
	user		    = root
}

service unlisted
{
	type		    = UNLISTED
	socket_type	    = stream
	protocol	    = tcp
	wait		    = no
	server		    = /bin/true
	port		    = 623
	user		    = root
}

service unlisted
{
	type		    = UNLISTED
	socket_type	    = dgram
	protocol	    = udp
	wait		    = yes
	server		    = /bin/true
	port		    = 624
	 user		     = root
}

service unlisted
{
	type		    = UNLISTED
	socket_type	    = stream
	protocol	    = tcp
	wait		    = yes
	server		    = /bin/true
	port		    = 624
	user		    = root
}
------------8<--- cut here --->8--------------

The above info only blocks the normal tcp/udp traffic, but all IPMI calls still
go through. Maybe this fixes your problem also.