Thanks. Setting the NISTIMEOUT value in /etc/sysconfig/ypbind appears to be the better solution. -- Jerry Feldman <Jerry.Feldman@xxxxxxxxxxxxxxxx> Algorithmics (US), Inc Suite 2-400 275 Grove St. Newton, MA 02466 617-663-5220 617-663-5391 (fax) > -----Original Message----- > From: redhat-list-bounces@xxxxxxxxxx [mailto:redhat-list- > bounces@xxxxxxxxxx] On Behalf Of George Magklaras > Sent: Thursday, September 04, 2008 10:22 AM > To: General Red Hat Linux discussion list > Subject: Re: Server sychronization after power fail and NIS > > > > jerry.feldman@xxxxxxxxxxxxxxxx wrote: > > > I can certainly > > write a cron script to test if ypbind is running, and if not restart it, > > but I would like to be able to have the ypbind daemon wait or retry. The > > problem is one of timing: > > Sep 4 06:29:00 asystem ypbind: Setting NIS domain name ypXXX: > > succeeded > > Sep 4 06:29:01 asystem ypbind: ypbind startup succeeded > > Sep 4 06:29:24 asystem rpc.statd[20919]: Can't notify xx.xx.xx.xx, > > giving up. > > Sep 4 06:29:58 asystem ypbind: ypbind shutdown succeeded > > Sep 4 06:29:58 asystem ypbind: attempting to contact yp server failed > > > > > Have a look at your ypbind init script at /etc/init.d/ypbind. It should > have a section like the one below: > > ############################################### > # 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. > echo -n $"Listening for an NIS domain server." > for (( times = 1; times < $NISTIMEOUT; times++ )); do > /usr/sbin/rpcinfo -p | LC_ALL=C fgrep -q ypbind && ypwhich > > /dev/null 2>&1 > RETVAL=$? > if [ $RETVAL -eq 0 ]; then > break; > fi > sleep 1 > echo -n "." > done > ############################################# > > Try to increase the sleep argument (1->15) and/or the NISTIMEOUT > variable. Normally this might be caused by the time it takes for your > switch to re-learn the MAC addresses of your servers, when they power > up, which depends on various factors. But that should do the trick I > think. > > GM > -- > -- > George Magklaras > > Senior Computer Systems Engineer/UNIX Systems Administrator > EMBnet Technical Management Board > The Biotechnology Centre of Oslo, > University of Oslo > http://folk.uio.no/georgios > > > > -- > redhat-list mailing list > unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/redhat-list -------------------------------------------------------------------------- This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory. -------------------------------------------------------------------------- -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
