Description of problem: ypbind does not start in /etc/init.d/ypbind because the script assumes, there is a 15sec timeout in ypwhich which does not happen regularly. Therefore the script thinks, that a timeout happended after a few milliseconds and shut downs the starting ypbind. The result is, that ypbind will not start. This depends on the speed of the system. Version-Release number of selected component (if applicable): ypbind-1.20.4-2.fc8 How reproducible: Start Fedora 8 presumably on a "slow" CPU. I use a Athlon XP 2800. Steps to Reproduce: 1. Start FC8 2. Watch ypbind failing to start with /var/log/message "ypbind: NIS server for domain XXXXXXX is not responding." 3. Actual results: ypbind shuts down instead of starting. Expected results: ypbind should start Additional info: If the rpcinfo|grep does not find ypbind, then the expected timeout of 15 secs in rpcinfo|grep&&ypwhich will not happen, because the ypwhich is not executed. Please find attached a patch which rewrites the timeout handling to a safe way. It does not depend on a hardcoded 15sec timeout as stated in the old version. It should run correctly on slow and fast machines.
Created attachment 293082 [details] Patch to make timeout handling more robust
I keep seeing this quite often. Whenever network initialization is delayed, ypbind fails to start. Then I have to start it by hand. It would be great if someone introduced a corrected initscript to FC8. I didn't try to above mentioned patch but I think there was another (exactly same) bug report in nugzilla where the following patch was given (I tried it and it works for me): --- /tmp/ypbind 2007-07-04 13:27:26.000000000 +0200 +++ /etc/rc.d/init.d/ypbind 2007-07-04 13:30:19.000000000 +0200 @@ -81,19 +81,16 @@ # 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. - timeout=$NISTIMEOUT - while [ $timeout -gt 0 ]; do - /usr/sbin/rpcinfo -p | LC_ALL=C fgrep -q ypbind && \ - /usr/bin/ypwhich > /dev/null 2>&1 + now=`date +%s` + endtime=`expr $now + $NISTIMEOUT` + while [ $endtime -gt `date +%s` ]; do + /usr/bin/ypwhich > /dev/null 2>&1 RETVAL=$? if [ $RETVAL -eq 0 ]; then break; fi - echo -n "..." - # ypwhich has a hardcode 15sec timeout - # so subtract that from NISTIMEOUT to - # to see of we should continue to wait - timeout=`expr $timeout - 15` + echo -n "." + sleep 1 done if [ $RETVAL -eq 0 ]; then logger -t ypbind \
Yes, this patch and my patch are very similar. They follow the same idea, but do it a little different. IMHO it does not matter, which patch to apply (at least as long as one of these two is applied... :-)
ypbind-1.20.4-3.fc8 has been submitted as an update for Fedora 8
Hi, Please test it. Fix taken from Rawhide.
ypbind-1.20.4-3.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ypbind'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-1342
Yes, it works. However, your solution depends upon the behaviour of ypbind (15 sec) which may change from time to time. For that reason I prefer the attached patches of this bugreport, because they do not depend on other things. Instead they give NIS a dedicated time to come up, regardless of any hard coded timeout in ypbind itself.
ypbind-1.20.4-3.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.