Date: Wed, 24 Oct 2007 15:30:02 -0700 (PDT) From: Doug Barton <dougb@FreeBSD.org> To: John Marshall <John.Marshall@riverwillow.com.au> Cc: "Brooks Davis <brooks@FreeBSD.org>; Mike Telahun Makonnen <mtm@freebsd.org>; freebsd-rc@FreeBSD.Org" <freebsd-rc@FreeBSD.org> Subject: Re: How to debug rc hangs? Message-ID: <alpine.BSF.0.9999.0710241515240.39484@qbhto.arg> In-Reply-To: <471F37CA.1080005@riverwillow.com.au> References: <471D7F68.8070308@riverwillow.com.au> <584bfc3f0710230505i29e8f19aofc4e66d0aee7b7c1@mail.gmail.com> <471DFFD0.8020701@riverwillow.com.au> <20071023155932.GA37204@lor.one-eyed-alien.net> <471E27E5.4030609@riverwillow.com.au> <alpine.BSF.0.9999.0710231038070.14145@qbhto.arg> <471F37CA.1080005@riverwillow.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
John,
Thanks for digging into this, a few comments in line.
On Wed, 24 Oct 2007, John Marshall wrote:
> It looks to me like the only reason why ypset runs so late is that there are
> no REQUIRE/BEFORE constraints requiring it to run earlier - and I think there
> should be.
Ok, fair enough.
> ---- ypset(8) ----
> NAME
> ypset -- tell ypbind(8) which YP server process to use
> ------------------
>
> The sole purpose of ypset is to get ypbind working. Anything which has a
> dependency on the NIS client (ypbind) is going to stall if ypbind is stalled
> waiting to find a NIS server. I have no NIS experience beyond this particular
> network, but my guess is that most systems wouldn't be relying on ypset to
> get ypbind functioning, so most people wouldn't hit this problem. If ypset is
> unused, who cares where it sits in the rc order? If it is used, then it
> really needs to kick in very soon after ypbind and before anything that
> requires ypbind.
I think I understand that bit, thanks.
> Having delved a bit further into this, I think that mountd was probably
> actually waiting on nfsserver, and that nfsserver has the implicit dependency
> on ypbind. So, I added ypset to the REQUIRE list in rc.d/nfsserver - and it
> works.
More good detective work! I have another idea though ...
> (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.
> ...and the diff's resulting from various experiments with your debug patch
> applied to /etc/rc (thanks!). In each case, the only thing that moves is
> ypset - and in the first two scenarios yield identical results.
That's good news, I did notice something interesting though.
> -----------------
> --- rc.late.standard 2007-10-24 08:54:59.000000000 +1000
> +++ rc.late.ypset_before_mountd 2007-10-24 08:53:59.000000000 +1000
> @@ -65,6 +65,7 @@
> /etc/rc.d/kadmind
> /etc/rc.d/keyserv
> /etc/rc.d/kpasswdd
> +/etc/rc.d/ypset
> /etc/rc.d/quota
Here it comes before quota
> -----------------
> --- rc.late.standard 2007-10-24 08:54:59.000000000 +1000
> +++ rc.late.nfsserver_requires_ypset 2007-10-24 21:06:23.000000000 +1000
> @@ -66,6 +66,7 @@
> /etc/rc.d/keyserv
> /etc/rc.d/kpasswdd
> /etc/rc.d/quota
> +/etc/rc.d/ypset
Here it comes after.
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?
If you have time, I would also be interested to know if there are any
changes if you take the current CVS code and just s/ypbind/ypset/ for all
the scripts that currently REQUIRE ypbind. I'm not convinced that is the
right answer yet, I'm just interested in what's going to happen.
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.0.9999.0710241515240.39484>