From owner-freebsd-bugs Thu Nov 11 18:30: 3 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 4798314F93 for ; Thu, 11 Nov 1999 18:30:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id SAA33006; Thu, 11 Nov 1999 18:30:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Thu, 11 Nov 1999 18:30:01 -0800 (PST) Message-Id: <199911120230.SAA33006@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: John Baldwin Subject: Re: bin/14829: rc.shutdown is handled unconsistently (Was RE: HEADS UP: new command rpc.umntall in usr.sbin) Reply-To: John Baldwin Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/14829; it has been noted by GNATS. From: John Baldwin To: freebsd-gnats-submit@freebsd.org Cc: Subject: Re: bin/14829: rc.shutdown is handled unconsistently (Was RE: HEADS UP: new command rpc.umntall in usr.sbin) Date: Thu, 11 Nov 1999 21:20:24 -0500 (EST) On 10-Nov-99 Martin Blapp wrote: > Attached it some part of RFC 1813: > > 5.2.4 Procedure 4: UMNTALL - Remove all mount entries > > SYNOPSIS > > void MOUNTPROC3_UMNTALL(void) = 4; > > DESCRIPTION > > Procedure UMNTALL removes all of the mount entries for > this client previously recorded by calls to MNT. AUTH_UNIX > authentication or better is required. > > IMPLEMENTATION > > This procedure should be used by clients when they are > recovering after a system shutdown. If the client could ^^^^^^^^^^^^^^^^^^^^^^^ To me, this means that rpc.umntall should only be called during startup and *not* during shutdown. > not successfully unmount all of its file systems before ^^^^^^^^^^^^^^^^^^^^ This also implies to me that we should attempt to unmount all NFS mounts first (with a timeout so that if they hang the unmount just gives up and returns an error). Then, running rpc.umntall at shutdown for those filesystems which could not be unmounted makes sense. So, sticking a call in rc.shutdown makes sense, and having rc.shutdown use a parameter to know when it is doing a 'shutdown' versus 'shutdown -[rph]' makes sense. And, grrr..., I guess having reboot(8), and halt(8) calling rc.shutdown makes sense. However, note that reboot and halt have special options to force really quick shutdowns, and your changes should honor those (albeit questionable) flags. I normally would vote for the current behavior of halt(8) and reboot(8), but rpc.umntall will be broken unless it is changed. > being shutdown or the client crashed because of a software > or hardware problem, there may be servers which still have > mount entries for this client. This is an easy way for the > client to inform all servers at once that it does not have > any mounted file systems. However, since this procedure > is generally implemented using broadcast RPC, it is only > of limited usefullness. > > ERRORS > > There are no MOUNT protocol errors which can be returned > from this procedure. However, RPC errors may be returned > for authentication or other RPC failures. --- John Baldwin -- http://www.cslab.vt.edu/~jobaldwi/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message