Bug 3496 - YPBIND not connecting to NIS server on system startup ; solution provided
YPBIND not connecting to NIS server on system startup ; solution provided
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: ypbind (Show other bugs)
6.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-06-16 05:14 EDT by swietanowski
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-01-27 14:21:18 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 swietanowski 1999-06-16 05:14:10 EDT
RH 6.0, upgraded from Mandrake 5.3

On system startup, in the file /etc/rc.d/init.d/ypbind called with argument
'start' the ypbind daemon only connects to the servrer, which is up at the
moment the ypbind daemon is run. The delay loop added afterwards
does not cause the ypbbind daemon to retry.

Solution:
(a) force running ypbind daemon to reread it's configuration and retry
     search for master,
(b) increase the time between the retries or the number of retries, or both.

Please, find below the appropriate excerpt from my corrected file.
I expressely grant you the right to use this code section in your
distribution without any obligation on your part.
<skip>
case "$1" in
  start)
        echo -n "Binding to the NIS domain... "
        daemon ypbind
        echo
        touch /var/lock/subsys/ypbind
        # the following fixes problems with the init scripts continuing
        # even when we are really not bound yet to a server, and then things
        # that need NIS fail.
        pid=`pidofproc ypbind`
        if [ -n "$pid" ]; then
          echo -n "Listening for an NIS domain server: "
          times=0
          until ypwhich > /dev/null 2>&1 || [ "$times" = "20" ]
          do
             echo -n "." ;
             sleep 5
             kill -HUP $pid  # <--- added correction
             times=$[$times+1]
          done
          exit_code=$?
          if [ $exit_code = 0 ]
          then
            ypwhich
          else
            echo " connection failed"
            # Makes no sense to run ypbind w/o the server
            $0 stop
          fi
        fi
        exit $exit_code
        ;;
<skip>
Comment 1 Bill Nottingham 1999-08-31 13:30:59 EDT
The delay isn't for it to retry; if the server's not there, the
server's not there.

It's for waiting to make sure that it's actually bound to
a server; if the connection is timing out, telling it to
try again isn't going to help.

Or am I misunderstanding what you're saying?
Comment 2 swietanowski 1999-09-01 10:28:59 EDT
In a synchronized startup of a cluster (or any network) with some NIS
server and some clients it may be reasonable for the slave to wait.
This is the case I have in my installation.

I have a cluster wich is turned on by just one power switch. The
clients usually boot faster than the NIS server and they need to
wait the additional few seconds.

Also, even with the server running, the ypbind did not always succeed
in connecting. Adding the forced config reread for ypbind seems to
have fixed the problem for me.
Comment 3 Cristian Gafton 2000-01-27 14:21:59 EST
if you set ypbind to breadcast for an NIS server it will keep retrying every 30
seconds to bind to a new server.

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