Bug 37463 - ypbind sometimes fails to find the domain server
ypbind sometimes fails to find the domain server
Product: Red Hat Linux
Classification: Retired
Component: ypbind (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
Aaron Brown
: 44323 44860 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2001-04-24 14:48 EDT by Steve Falco
Modified: 2007-04-18 12:32 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-21 10:51:43 EST
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 17:06 EDT, hjl
no flags Details | Diff

  None (edit)
Description Steve Falco 2001-04-24 14:48:10 EDT
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 11:04:45 EDT
Confirmed, I have a bunch of machines exhibiting unreliable startup due to this
after upgrading to 7.1.
Comment 2 John Strange 2001-05-28 21:57:02 EDT
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 17:04:11 EDT
fixed in 1.7-7 and later, to be released as errata.
Comment 4 Stephen Tweedie 2001-06-02 06:04:41 EDT
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 12:12:06 EDT
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 16:57:33 EDT
*** Bug 44323 has been marked as a duplicate of this bug. ***
Comment 7 hjl 2001-06-19 17:04:59 EDT
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 17:06:05 EDT
Created attachment 21365 [details]
A new patch
Comment 9 Alexander Larsson 2002-03-21 10:51:38 EST
*** Bug 44860 has been marked as a duplicate of this bug. ***
Comment 10 Alexander Larsson 2002-03-25 16:15:59 EST
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.