From nobody@FreeBSD.org  Thu May 17 06:25:01 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id B4C2C37B423
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 17 May 2001 06:25:00 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f4HDP0p62556;
	Thu, 17 May 2001 06:25:00 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200105171325.f4HDP0p62556@freefall.freebsd.org>
Date: Thu, 17 May 2001 06:25:00 -0700 (PDT)
From: B.Candler@pobox.com
To: freebsd-gnats-submit@FreeBSD.org
Subject: rc.network hangs at rpc.umntall if stale NFS mounts exist in /var/db/mounttab
X-Send-Pr-Version: www-1.0

>Number:         27408
>Category:       conf
>Synopsis:       rc.network hangs at rpc.umntall if stale NFS mounts exist in /var/db/mounttab
>Confidential:   no
>Severity:       critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu May 17 06:30:01 PDT 2001
>Closed-Date:    Fri Aug 09 12:33:28 PDT 2002
>Last-Modified:  Fri Aug 09 12:33:28 PDT 2002
>Originator:     Brian Candler
>Release:        FreeBSD 4.2-RELEASE
>Organization:
>Environment:
>Description:
FreeBSD-4.2 preserves NFS state across reboots in /var/db. I had a
classful of machines which had temporarily mounted an NFS server - there
was no entry in /etc/fstab. However once these machines had been powered
down, moved, renumbered and rebooted (and the NFS servers gone), I found
they hung during bootup.

The problem was traced to the following in /etc/rc.network:

        if [ -f /var/db/mounttab ]; then
                rpc.umntall -k
        fi

Each of the workstations was then in a badly broken state, which even
a further reboot could not repair. To fix them required:
- boot into single-user mode
- fsck -y /var
- mount /var
- rm /var/db/mounttab
- fsck -y <all other partitions>
on all machines.

>How-To-Repeat:
Mount an NFS server just using 'mount' at the command line (no entry
in /etc/fstab).
Power off both the client and the NFS server.
Power up the client. Watch it hang.

>Fix:
Not sure. Perhaps sensible (short) timeouts. Perhaps rpc.umntall should
remove mounttab entries _before_ attempting to contact the servers -
then at least a second reboot would clear the problem.

RFC1813 says of the UMNTALL call:
     "since this procedure
      is generally implemented using broadcast RPC, it is only
      of limited usefullness."

I know very little about NFS, but personally I don't think this sort
of state should be maintained across a reboot at all.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Sun Jan 13 08:05:41 PST 2002 
State-Changed-Why:  

There were a number of bugs in rpc.umntall that have been fixed 
recently, including a bug that prevented you from simply hitting 
^C to let the boot process continue, and old entries weren't expired 
aas they should be. There are short timeouts set, but RPC calls 
require portmap lookups, and these seem to wait up to 60 seconds 
for a reply by default, so your machines probably would have 
booted after a delay of a few minutes. 

Is the corrected entry expiration and the ability to interrupt 
rpc.umntall an acceptable solution to this? 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27408 
State-Changed-From-To: feedback->closed 
State-Changed-By: schweikh 
State-Changed-When: Fri Aug 9 12:33:13 PDT 2002 
State-Changed-Why:  
Feedback timeout. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=27408 
>Unformatted:
