Bug 37463 - ypbind sometimes fails to find the domain server
Summary: ypbind sometimes fails to find the domain server
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ypbind   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact: Aaron Brown
: 44323 44860 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-04-24 18:48 UTC by Steve Falco
Modified: 2007-04-18 16:32 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-21 15:51: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)
A new patch (1.15 KB, patch)
2001-06-19 21:06 UTC, hjl
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2001:076 normal SHIPPED_LIVE new ypbind package available for Red Hat Linux 7.1 2001-06-04 04:00:00 UTC

Description Steve Falco 2001-04-24 18:48:10 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686)

The /etc/rc.d/init.d/ypbind script has a flaw in that RETVAL may be used
before it is set, in the case where "ypwhich" immediately succeeds. The
body of the loop is never executed, so RETVAL is uninitialized. Also, there
is no "sleep" in the loop, which means that the script doesn't allow enough
time on a slow network.

Reproducible: Always
Steps to Reproduce:
1. manually start and stop ypbind.  cd to /etc/rc.d/init.d
2. ./ypbind stop ; ./ypbind start

Actual Results:  sometimes ypbind finds the domain server, other times it

Here is a proposed patch to the startup script.  I used an arithmetic loop
with ypwhich and the setting of RETVAL inside the loop.  This fixes the
uninitialized variable.  I also added a sleep to allow a little time
between checks.  I also increased the number of tries to 9.  Lastly, when
running ypwhich, I only send stderr to /dev/null.  This way, one can see
the name of the domain server in the logs once the bind succeeds.  You are
welcome to use some or all of this patch as you see fit.

--- /etc/rc.d/init.d/ypbind.orig        Tue Apr 24 14:30:47 2001
+++ /etc/rc.d/init.d/ypbind     Tue Apr 24 14:20:06 2001
@@ -40,12 +40,15 @@
        pid=`pidofproc ypbind`
        if [ -n "$pid" ]; then
          echo -n $"Listening for an NIS domain server."
-         times=1
-         until ypwhich > /dev/null 2>&1 || [ "$times" = "3" ]
+         for (( times = 1; times < 9; times++ ))
+            ypwhich 2> /dev/null
+            if [ $RETVAL -eq 0 ]; then
+               break;
+            fi
+            sleep 2
              echo -n "."
-            times=$[$times+1]
        if [ $RETVAL -eq 0 ]; then

Comment 1 Stephen Tweedie 2001-05-09 15:04:45 UTC
Confirmed, I have a bunch of machines exhibiting unreliable startup due to this
after upgrading to 7.1.

Comment 2 John Strange 2001-05-29 01:57:02 UTC
I am also having trouble with NIS binding after a fresh 7.1 install, the script 
is what seems to be broke as starting ypbind -broadcast has no problem.

Comment 3 Preston Brown 2001-06-01 21:04:11 UTC
fixed in 1.7-7 and later, to be released as errata.

Comment 4 Stephen Tweedie 2001-06-02 10:04:41 UTC
Sorry, but 1.7-7 does not fix the coding errors completely.  It does add sleeps
in the ypwhich loop, but it still fails to track successful ypwhich attempts
correctly.  The new code does:

          until ypwhich > /dev/null 2>&1 || [ "$times" = "3" ]
             echo -n "."
             sleep 1

We're still not initialising RETVAL before the possible loop exit, and the
RETVAL assignment will always set it to false (the '||' will result of the [
$times -eq 10 ] test, and we'll only set RETVAL if that test fails).  If the
first ypwhich fails then we can never set RETVAL to true subsequently, so we'll
kill ypbind.

The code supplied at the top of this bugzilla report does not have these

Comment 5 Preston Brown 2001-06-04 16:12:06 UTC
There were two 1.7-7's, you got the wrong one; I've rebuilt mine as 1.7-8 and it is 
currently in QA for errata release.

Comment 6 hjl 2001-06-19 20:57:33 UTC
*** Bug 44323 has been marked as a duplicate of this bug. ***

Comment 7 hjl 2001-06-19 21:04:59 UTC
The change is incomplete.  There are 3 problems:

1. It doesn't check if ypbind starts ok or not.
2. 5 sec wait is not enough for me. I need 20 secs.
3. $pid may be empty in "kill $pid".

I will submit a new patch.

Comment 8 hjl 2001-06-19 21:06:05 UTC
Created attachment 21365 [details]
A new patch

Comment 9 Alexander Larsson 2002-03-21 15:51:38 UTC
*** Bug 44860 has been marked as a duplicate of this bug. ***

Comment 10 Alexander Larsson 2002-03-25 21:15:59 UTC
This should be fixed in ypbind 1.10-7, soon in a rawhide near you.

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