Date: Thu, 11 Nov 1999 18:30:01 -0800 (PST) From: John Baldwin <jobaldwi@vt.edu> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/14829: rc.shutdown is handled unconsistently (Was RE: HEADS UP: new command rpc.umntall in usr.sbin) Message-ID: <199911120230.SAA33006@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/14829; it has been noted by GNATS.
From: John Baldwin <jobaldwi@vt.edu>
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 <jobaldwi@vt.edu> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911120230.SAA33006>