Bug 20039

Summary:	ypbind-mt svc_run and timed out problems
Product:	[Retired] Red Hat Linux	Reporter:	Josko Plazonic <plazonic>
Component:	ypbind-mt	Assignee:	Florian La Roche <laroche>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	6.2	CC:	jakub
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-03-27 21:52:43 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 Josko Plazonic 2000-10-30 15:25:34 UTC

On an uptodate redhat 6.2 SMP machine new ypbind-mt, i.e. ypbind-1.7-
0.6.x.i386.rpm failed after only 3 hours of operation with message in logs 
about svc_run failure.

On other uniprocessor machines it runs but cron job rmmod -as produces 
constantly these errors that did not happen with ypbind-3.3:
yp_all: clnt_call: RPC: Timed out
this error will happen also on other occasions (since new ypbind failed on 
me once I made a cron job to test it on all other machines but it produces 
very often the previous error).  Again, none of these problems happened 
with ypbind-3.3.  

Thanks.

Comment 1 Josko Plazonic 2000-11-16 21:02:14 UTC

Upgrading ypserv to the latest 1.3.11 helped a great deal (though still not 
perfect).  Until upgrading ypserv would occasionally complain of "having" too 
many children, not any more.

Comment 2 Preston Brown 2001-02-01 17:34:53 UTC

jakub: do you think this is glibc related?

Comment 3 Josko Plazonic 2001-02-10 22:00:04 UTC

Hard to say, maybe in the way glibc reacts if it doesn't get a reply quickly 
(longer timeout would be better?) but then again why no timeouts with old 
ypbind?  I'd guess ypbind-mt is (overly?) aggressively querying ypserv and 
older version of ypserv simply couldn't keep up with 70 or so clients that were 
now also doing every 15min checks on which server is fastest.  Newer version of 
ypserv does this much better - not sure why - Changelog mentions explicitly 
only RPC protocol fixes and better handling of fork calls (last thing could 
explain why no more complaints from ypserv about too many children).  Still 
occasionally RPC timeout problems occur but at rate that it really doesn't 
matter (once every day?).

Comment 4 Josko Plazonic 2001-02-10 22:43:41 UTC

Forgot to add a comment about dying ypbind-mt which is pretty serious to us.  
It happened another time since the first time but we had a monitoring process 
restart it authomatically.  This is on our busiest machine so I cannot guess if 
this is so due to load or the fact that this machine is dual CPU (but ypbind-mt 
should be threaded already and safe, hm?) as it never happened on workstations 
with exactly the same package.  It could be a problem in glibc threads - is 
svc_run thread safe?

Comment 5 Alexander Larsson 2002-03-27 21:52:37 UTC

Do you still see this? Can you try our later packages?

Comment 6 Alexander Larsson 2002-04-09 16:29:33 UTC

I haven't seen this at all in recent versions. And reporter mentioned that it
was basically "fixed" for him, so i'm closing this bug.