From owner-freebsd-stable Sun Sep 21 22:10:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA12683 for stable-outgoing; Sun, 21 Sep 1997 22:10:04 -0700 (PDT) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA12676 for ; Sun, 21 Sep 1997 22:10:01 -0700 (PDT) Received: from localhost (spork@localhost) by super-g.inch.com (8.8.7/8.8.5) with SMTP id BAA21041; Mon, 22 Sep 1997 01:28:54 -0400 (EDT) Date: Mon, 22 Sep 1997 01:28:53 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: Joerg Wunsch cc: stable@FreeBSD.ORG Subject: Re: Another NFS bogon in 2.2-stable? In-Reply-To: <19970921083931.CS53038@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Is it just me or is there another bug involving 2 FBSD machines running -stable and nfsv2 or v3? In the above situation, if machine A is exporting a directory to machine B and machine A dies unexpectedly, you cannot umount the nfs-mounted directory; the command just hangs forever. "mount" will hang forever as well. Killing off any nfs processes will not help (brutal I thought, but worth a try). Remounting can be difficult, and sometimes a reboot is required. Am I doing something terribly wrong? I'm not doing anything out of the ordinary, I let the startup script do everything, and I'm only exporting one directory. Charles On Sun, 21 Sep 1997, J Wunsch wrote: > (Please drop me a Cc of this conversation, i'm not subscribed to this > list.) > > Did anybody else notice that shutting down a 2.2-stable machine that > has NFS file systems mounted never yields a clean shutdown? My 2.2 > scratchbox always jams with a `2 2 2 2 2 giving up' display, and comes > up again with the clean flag not set in the UFS filesystems. > > If i shutdown to single-user, manually umount the NFS filesystems, and > then type `halt', all works as expected. > > The machine is not the fastest on earth (386/40), maybe this is what > uncovers this problem? > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) >