Bug 149886 - nis time out ypcall
nis time out ypcall
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: yp-tools (Show other bugs)
3.0
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Feist
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-28 11:43 EST by Tobias Vogt
Modified: 2015-01-07 19:09 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-08 17:03:36 EST
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 Tobias Vogt 2005-02-28 11:43:48 EST
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 15:36:11 EST
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 16:52:34 EST
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 01:48:37 EDT
I'm getting the same problem in Fedora Core 3.  Has this issue been resolved?
Comment 4 Tobias Vogt 2005-05-09 14:08:41 EDT
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. 

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