How to debug rc hangs?

[John Marshall]

Doug Barton wrote:
> On Wed, 24 Oct 2007, John Marshall wrote:
>> (If there was some way of tying ypbind and ypset together, I think 
>> that would be a better solution.)
> 
> Well there are a couple ways of doing that. The least painful would be 
> to change any REQUIRE lines that mention ypbind to mention ypset 
> instead. ypset already has a REQUIRE for ypbind, so that would put them 
> in the right order, and closer together. Since I know next to nothing 
> about NIS though, I am hesitant to do that.

Apart from ypset, the only scripts which REQUIRE ypbind are:
- amd
- keyserv
- yppasswdd

I edited those three files and substituted "ypset" for "ypbind" in the 
REQUIRE line (which should be OK because ypset REQUIREs ypbind) and ran 
your modified rc script. Again, the only thing that moves in the rc 
order (compared to out-of-the-box 7.0-BETA1) is ypset - but it moves to 
EXACTLY the right place. I've expanded the diff context in order to show 
where this sits in relation to nfsserver, mountd and friends.

------------------
--- rc.late.standard 2007-10-24 08:54:59.000000000 +1000
+++ rc.late.subs_require_ypset  2007-10-25 10:45:28.000000000 +1000
@@ -37,40 +37,41 @@
  /etc/rc.d/NETWORKING
  /etc/rc.d/mountcritremote
  /etc/rc.d/accounting
  /etc/rc.d/ldconfig
  /etc/rc.d/devfs
  /etc/rc.d/ipmon
  /etc/rc.d/mdconfig2
  /etc/rc.d/newsyslog
  /etc/rc.d/syslogd
  /etc/rc.d/savecore
  /etc/rc.d/archdep
  /etc/rc.d/abi
  /etc/rc.d/SERVERS
  /etc/rc.d/named
  /etc/rc.d/ntpdate
  /etc/rc.d/rpcbind
  /etc/rc.d/nfsclient
  /etc/rc.d/nisdomain
  /etc/rc.d/ypserv
  /etc/rc.d/ypbind
+/etc/rc.d/ypset
  /etc/rc.d/amd
  /etc/rc.d/atm3
  /etc/rc.d/auditd
  /etc/rc.d/tmp
  /etc/rc.d/cleartmp
  /etc/rc.d/dmesg
  /etc/rc.d/ipxrouted
  /etc/rc.d/kerberos
  /etc/rc.d/kadmind
  /etc/rc.d/keyserv
  /etc/rc.d/kpasswdd
  /etc/rc.d/quota
  /etc/rc.d/nfsserver
  /etc/rc.d/mountd
  /etc/rc.d/nfsd
  /etc/rc.d/statd
  /etc/rc.d/lockd
  /etc/rc.d/pppoed
  /etc/rc.d/pwcheck
  /etc/rc.d/virecover
@@ -98,41 +99,40 @@
  /usr/local/etc/rc.d/samba
  /etc/rc.d/LOGIN
  /usr/local/etc/rc.d/squid
  /usr/local/etc/rc.d/spamass-milter
  /usr/local/etc/rc.d/sa-spamd
  /usr/local/etc/rc.d/rsyncd_ext
  /usr/local/etc/rc.d/rsyncd
  /usr/local/etc/rc.d/milter-greylist.sh
  /usr/local/etc/rc.d/mailman
  /usr/local/etc/rc.d/icecast2
  /usr/local/etc/rc.d/ices0_recent
  /usr/local/etc/rc.d/ices0_mark
  /usr/local/etc/rc.d/ices0_attr
  /usr/local/etc/rc.d/ices0_acts
  /usr/local/etc/rc.d/ices0
  /usr/local/etc/rc.d/htcacheclean
  /usr/local/etc/rc.d/cvsupd
  /usr/local/etc/rc.d/apache22
  /etc/rc.d/ypxfrd
  /etc/rc.d/ypupdated
-/etc/rc.d/ypset
  /etc/rc.d/watchdogd
  /etc/rc.d/syscons
  /etc/rc.d/sshd
  /etc/rc.d/sendmail
  /etc/rc.d/cron
  /etc/rc.d/jail
  /etc/rc.d/localpkg
  /etc/rc.d/securelevel
  /etc/rc.d/othermta
  /etc/rc.d/msgs
  /etc/rc.d/moused
  /etc/rc.d/mixer
  /etc/rc.d/kernel
  /etc/rc.d/inetd
  /etc/rc.d/idmapd
  /etc/rc.d/hostapd
  /etc/rc.d/geli2
  /etc/rc.d/ftpd
  /etc/rc.d/ftp-proxy
  /etc/rc.d/bsnmpd
------------------

> Now mountd has:
> # REQUIRE: NETWORKING nfsserver rpcbind quota
> 
> and there is a comment in quota that says:
> must be after ypbind if using NIS
> 
> So I'm thinking that adding REQUIRE: ypset to quota might be the way to 
> go. Can you try that fix instead and see if it works for you?

The absence of "ypbind" from the REQUIRE line in the quota script must 
be an oversight, given the script's ypbind requirement comment, and 
ought to be addressed. Also, as you note, the fact that mountd REQUIREs 
quota means that fixing the quota dependency will kill two birds with 
the one stone.

So, I added "ypset" to the REQUIRE line in quota and re-ran your script. 
The result was identical to that posted above.

Rebooting with the following modifications resulted in a flawless boot:
- Replace ypbind with ypset in REQUIRE lines for:
   - amd
   - keyserv
   - yppasswdd
- Add ypset to REQUIRE line for quota

These modifications make perfect sense to me but I would value the 
opinion of rc/NFS/NIS gurus before filing a PR - or is filing a PR the 
proper way to bring something like this under review?

Thank you for your helpful, friendly tuition in rc order analysis. I 
hope this might prove useful to others.

-- 
John Marshall