From owner-cvs-src@FreeBSD.ORG Sat Oct 25 22:08:09 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3492A16A4B3; Sat, 25 Oct 2003 22:08:09 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2AF443F3F; Sat, 25 Oct 2003 22:08:05 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id QAA11810; Sun, 26 Oct 2003 16:07:50 +1100 Date: Sun, 26 Oct 2003 16:07:49 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Alfred Perlstein In-Reply-To: <20031025233749.GW99943@elvis.mu.org> Message-ID: <20031026145418.G16944@gamplex.bde.org> References: <200310251614.h9PGE925019013@repoman.freebsd.org> <20031025233749.GW99943@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: Robert Watson cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_sig.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 05:08:09 -0000 On Sat, 25 Oct 2003, Alfred Perlstein top posted: > This is bad, it's time to add a flag to the vnode to do this > properly instead of relying upon the underlying FS to implement > the locking. How would a mere flag help fix the real complexities for nfs? > * Robert Watson [031025 09:14] wrote: > > rwatson 2003/10/25 09:14:09 PDT > > > > FreeBSD src repository > > > > Modified files: > > sys/kern kern_sig.c > > Log: > > When generate a core dump, use advisory locking in an advisory way: > > if we do acquire an advisory lock, great! We'll release it later. > > However, if we fail to acquire a lock, we perform the coredump > > anyway. Er, advisory locking means that honoring the lock is not enforced, not that it is good to not honor it. > > This problem became particularly visible with NFS after > > the introduction of rpc.lockd: if the lock manager isn't running, > > then locking calls will fail, aborting the core dump (resulting in > > a zero-byte dump file). > > > > Reported by: Yogeshwar Shenoy There is only a problem if the lock manager is supposed to be running but is not. That is a configuration error, or perhaps a transient error, so it should not be "fixed" by ignoring the failure. If ignoring nfs locks is what is wanted in all cases, then it should be configured by mounting the file system with -L (= nolockd). Maybe the lock request should hang for transient failures. Support for correct configuration of this is still mostly nonexistent in /etc/defaults/rc.conf and rc.conf(5). The default for nfs mounts is lockd, but the default for rpc_lockd_enable is "NO". Setting rpc_lockd_enable to "YES" is not sufficient to configure this. The setting of at least rc_statd_enable must also be changed. This stuff is misconfigured on all of the freebsd machines that I checked. Some run 4.9, so nfs locking is not available. beast and builder demonstrate the bug by giving empty core dumps. bento avoids the bug by dumping cores in a non-nfs directory. Bruce