Bug 20039 - ypbind-mt svc_run and timed out problems
Summary: ypbind-mt svc_run and timed out problems
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ypbind-mt (Show other bugs)
(Show other bugs)
Version: 6.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Florian La Roche
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-10-30 15:25 UTC by Josko Plazonic
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-27 21:52:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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.  


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.

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