From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 6 20:02:15 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C5A816A41F for ; Tue, 6 Sep 2005 20:02:15 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3339643D46 for ; Tue, 6 Sep 2005 20:02:15 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j86K29X2015508; Tue, 6 Sep 2005 13:02:09 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j86K28op015507; Tue, 6 Sep 2005 13:02:08 -0700 Date: Tue, 6 Sep 2005 13:02:08 -0700 From: Brooks Davis To: Tuc at T-B-O-H Message-ID: <20050906200208.GD16555@odin.ac.hmc.edu> References: <20050903171621.GA3927@core.310.ru> <200509031933.j83JXtfZ050463@himinbjorg.tucs-beachin-obx-house.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6WlEvdN9Dv0WHSBl" Content-Disposition: inline In-Reply-To: <200509031933.j83JXtfZ050463@himinbjorg.tucs-beachin-obx-house.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-hackers@freebsd.org, Stanislav Sedov Subject: Re: rc sequencing issue / mountcritremote X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2005 20:02:15 -0000 --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--