From owner-freebsd-stable Tue Nov 3 01:53:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA16990 for freebsd-stable-outgoing; Tue, 3 Nov 1998 01:53:57 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from internationalschool.co.uk (intschool.easynet.co.uk [194.72.37.214]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA16972 for ; Tue, 3 Nov 1998 01:53:52 -0800 (PST) (envelope-from stuart@internationalschool.co.uk) Received: from internationalschool.co.uk (bamboo [10.0.0.70]) by internationalschool.co.uk (8.8.8/8.8.8) with ESMTP id JAA19302; Tue, 3 Nov 1998 09:52:40 GMT Message-ID: <363ED28C.E9D2B101@internationalschool.co.uk> Date: Tue, 03 Nov 1998 09:53:17 +0000 From: Stuart Henderson Organization: http://ints.ml.org/ X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.7-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Viren R. Shah" CC: freebsd-stable@FreeBSD.ORG Subject: Re: df hangs on 2.2.6-BETA References: <199811021945.OAA19170@jabberwock.rstcorp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Viren R. Shah" wrote: > > Whenever I do a "df" on the system, the df process hangs, and can't > be killed. Has anyone seen this before? The system still does > everything else fine. Sounds like it may be an NFS mount that isn't there any more. Any process trying to access it will block and can't be killed (I think you can set a mount option in /etc/fstab or the command line to make it so if things get in this state you can kill them - see manpages - I think it's the 'intr' flag)[1]. These can be rather tricky to get rid of without rebooting...(sometimes if you recreate the NFS mount on the machine it's mounted from you can get there). If you have been using rumba and didn't use the unrumba command to unmount, learn to do so. > Any ideas? The box has been up for a while: > And, unless it is absolutely necessary, we don't want to reboot it. As you are running a beta version anyway that's pretty good uptime as it stands. Go ahead, reboot it. At least you can *schedule* it :-) It's uncontrolled reboots that are the problem. Stuart [1] the way it works *is* good behaviour in the usual case where a NFS server is rebooted, because clients accessing it will just wait for it to come back online and continue where they left off. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message