From nobody@FreeBSD.ORG Thu Nov 11 14:03:54 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 8FC5114EEF; Thu, 11 Nov 1999 14:03:54 -0800 (PST)
Message-Id: <19991111220354.8FC5114EEF@hub.freebsd.org>
Date: Thu, 11 Nov 1999 14:03:54 -0800 (PST)
From: mb@imp.ch
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: rc.shutdown is handled unconsistently by reboot(8), shutdown -r now etc.
X-Send-Pr-Version: www-1.0

>Number:         14829
>Category:       bin
>Synopsis:       rc.shutdown is handled unconsistently by reboot(8), shutdown -r now etc.
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Nov 11 14:10:01 PST 1999
>Closed-Date:    Mon Jan 21 13:56:45 PST 2002
>Last-Modified:  Mon Jan 21 13:57:07 PST 2002
>Originator:     Martin Blapp
>Release:        CURRENT
>Organization:
Improware AG, Pratteln
>Environment:
>Description:
- 'init(8) -6', 'shutdown(8) -r now' do execute rc.shutdown.
- 'CTRL ALT DELETE', 'reboot(8)' don't execute it.

In my opinion it's wrong to think that rc.shutdown has only
something to do with shutdown(8). If someone depends on terminating
all services properly, it is a good idea to always do proper
shutdowns. The advice 'use shutdown(8)' if you like proper shutdowns
is a bad idea. Many people (including me) are used to shutdown the
system in different ways and they don't like to do it suddenly in
a different manner. 

I wrote and sent this in because my little program (rpc.umntall) does
depend on proper shutdowns. It get's executed in /etc/rc.shutdown ...
so you know why I was angry about people saying 'use shutdown, not
reboot'. If we don't handle this case properly, /var/db/mountdtab will
never be handled properly.
>How-To-Repeat:

>Fix:
In all cases it would be a good idea to do a kill(1, SIGINT),
so init starts rc.shutdown before it exits. This leads to _always_
proper shutdowns _and_ reboots. If we support the SYSV init emulation,
we should also handle it properly. 

>Release-Note:
>Audit-Trail:

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/
 
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Mon Jan 21 13:36:52 PST 2002 
State-Changed-Why:  

What was the conclusion here - can this be closed? As far as I know, 
any shutdown mechanism that signals init(8) will invoke rc.shutdown. 
The halt and reboot programs are supposed to do a quick shutdown 
and work even if init is stuck, so it seems reasonable that they 
skip the rc.shutdown step. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=14829 
State-Changed-From-To: feedback->closed 
State-Changed-By: iedowse 
State-Changed-When: Mon Jan 21 13:56:45 PST 2002 
State-Changed-Why:  

Submitter says this can be closed. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=14829 
>Unformatted:
