|Summary:||YPBIND not connecting to NIS server on system startup ; solution provided|
|Product:||[Retired] Red Hat Linux||Reporter:||swietanowski|
|Component:||ypbind||Assignee:||Cristian Gafton <gafton>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2000-01-27 19:21:18 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description swietanowski 1999-06-16 09:14:10 UTC
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 17:30:59 UTC
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 14:28:59 UTC
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 19:21:59 UTC
if you set ypbind to breadcast for an NIS server it will keep retrying every 30 seconds to bind to a new server.