Date: Tue, 6 Sep 2005 13:02:08 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Tuc at T-B-O-H <ml@t-b-o-h.net> Cc: freebsd-hackers@freebsd.org, Stanislav Sedov <stas@310.ru> Subject: Re: rc sequencing issue / mountcritremote Message-ID: <20050906200208.GD16555@odin.ac.hmc.edu> In-Reply-To: <200509031933.j83JXtfZ050463@himinbjorg.tucs-beachin-obx-house.com> References: <20050903171621.GA3927@core.310.ru> <200509031933.j83JXtfZ050463@himinbjorg.tucs-beachin-obx-house.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--6WlEvdN9Dv0WHSBl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 03, 2005 at 03:33:54PM -0400, Tuc at T-B-O-H wrote: > >=20 > > On Sat, Sep 03, 2005 at 12:20:41PM -0400, Tuc at T-B-O-H wrote: > >=20 > > > The problem I'm having is that when it attempts to remotely > > > mount the NFS filesystem I need, there are no support programs > > > running, namely (I THINK) : > > > > > > /etc/rc.d/rpcbind > > > /etc/rc.d/nfsclient > > > /etc/rc.d/mountd > > > /etc/rc.d/nfsd > > > /etc/rc.d/nfslocking > > =20 > > This is wrong, you don't need anything to mount remote NFS filesystems. > > nfsclient only sets some useful sysctls. > > See handbook for details. > >=20 > nfsclient not only does sysctls, but also runs rpc.umntall via > a dependency. I would still think the best time to do this is before > the remote filesystem is mounted. Since there are other items that need= =20 > rpcbind, it should be started first, and again I think before the=20 > filesystem. In checking more, the mountd isn't needed.=20 >=20 > The nfsd seems to take into account nfsserver, > rpcbind, mountd and a sysctl. However, the biggest one after rpcbind > I would think is nfslocking. It runs rpc.statd and rpc.lockd. I've > run into ALOT of problems with things if locking isn't running. So > isn't this also necessary before the mount? I know I use the remote > filesystem very soon after its mounted, so it would need to be > running very early on. =20 >=20 > So, even with the others not running, wouldn't I need > rpcbind and nfslocking done just before remotemountcrit? >=20 > One other thing I didn't touch too much on, is what > about the DNS resolution for the remote mount? named isn't running > until much later, so it hangs.... Isn't that something that should > be running so the resolution can happen? The apparent mismatch in ordering comes from the fact that /usr may not be assumed to exist until after mountcritremote and thus the commands you think should run before this point can not be run until later. I believe it would be better if mountcritremote only mounted critical files systems, not all of them, but we don't have the infrastructure to support that at the moment. To address you specific points, locking will start working the moment nfslocking is run so that's not a major issue. Any program that requires an essentially fully functional system should specifically require DAEMON. As to DNS, don't do that. You simply can't rely on DNS during the early part of the boot process, that's been the case forever and likely will remain so. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --6WlEvdN9Dv0WHSBl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDHfW/XY6L6fI4GtQRAhUoAKDCy8CetMvcE2OFkwslCt053tFYDQCgoyWx b4X8Ah2klEjdKVNTbXeBOnE= =x2Ya -----END PGP SIGNATURE----- --6WlEvdN9Dv0WHSBl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050906200208.GD16555>