I've observed that, when ypbind is used in broadcast mode, other scripts may be run before the ypbind daemon has received and processed the response to its broadcast request. If amd is also being started at boot time, and expects to obtain one or more mount maps through NIS, it will effectively give up on those mount maps if it can't get them on the first try. In that case, it must be stopped and started anew -- even a restart via SIGHUP won't help. The fix I adopted involves adding a loop to /etc/rc.d/init.d/ypbind, after it has invoked "daemon ypbind", which tries "ypwhich" once every second until that program returns a nonzero exit status. (The actual patch will follow by mail once I have a bug number.) I've encountered this problem on two different machines running Red Hat 5.2. A quick inspection of the ypbind script in 5.9 (Starbuck) suggests that it is vulnerable to the same thing, but I haven't demonstrated that under conditions of actual use. ------- Email Received From Dan Martinez <dfm> 04/01/99 03:59 -------
Thanks very much for the fix, it is sane and looks professional. Fixed in ypbind-3.3-16.