From owner-freebsd-questions Tue Mar 6 20:58:37 2001 Delivered-To: freebsd-questions@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 0FF7037B719 for ; Tue, 6 Mar 2001 20:58:36 -0800 (PST) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 362583E09; Tue, 6 Mar 2001 20:58:31 -0800 (PST) To: Kris Kennaway Cc: Walter Hop , FreeBSD Questions Subject: Re: tar just doesn't want to be KILLed In-Reply-To: <20010305042804.A80229@mollari.cthul.hu>; from kris@obsecurity.org on "Mon, 5 Mar 2001 04:28:04 -0800" Date: Tue, 06 Mar 2001 20:58:31 -0800 From: Dima Dorfman Message-Id: <20010307045831.362583E09@bazooka.unixfreak.org> Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway writes: > On Mon, Mar 05, 2001 at 02:30:50AM +0100, Walter Hop wrote: > > [btw, /mnt/dump is a dead NFS mount and tar is in the 'sbwait' state] > > Okay, NFS is the exception here. You get this behaviour if the remote > system dies and you're not mounting the NFS volume the correct way, > but I'm not enough of an NFS expert to remember which options you > should include to fix it. 'soft' or 'intr' should do it. The former will make the system recover by itself because the NFS RPC will eventually time out; the downside is that if the NFS server goes down during a write, your write will fail (I don't know if it'll return an error or fail silently; I believe it's the former). The latter will make the RPC layer respect signals, so you'll be able to kill the offending process; the downside to this is that it requires operator intervention to recover. Choose your poison. Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message