rc sequencing issue / mountcritremote

[Brooks Davis]

On Sat, Sep 03, 2005 at 03:33:54PM -0400, Tuc at T-B-O-H wrote:
> > 
> > On Sat, Sep 03, 2005 at 12:20:41PM -0400, Tuc at T-B-O-H wrote:
> > 
> > >       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
> >  
> > This is wrong, you don't need anything to mount remote NFS filesystems.
> > nfsclient only sets some useful sysctls.
> > See handbook for details.
> > 
> 	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 
> rpcbind, it should be started first, and again I think before the 
> filesystem. In checking more, the mountd isn't needed. 
> 
> 	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.  
> 
> 	So, even with the others not running, wouldn't I need
> rpcbind and nfslocking done just before remotemountcrit?
> 
> 	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

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20050906/6b561fe7/attachment.bin