From owner-freebsd-hackers Tue Jan 2 21:33:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA13313 for hackers-outgoing; Tue, 2 Jan 1996 21:33:10 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA13307 for ; Tue, 2 Jan 1996 21:33:06 -0800 (PST) Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id VAA02679; Tue, 2 Jan 1996 21:33:06 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.7.3/8.6.5) with SMTP id VAA00222; Tue, 2 Jan 1996 21:38:19 -0800 (PST) Message-Id: <199601030538.VAA00222@corbin.Root.COM> To: gpalmer@westhill.cdrom.com cc: dfr@render.com, hackers@freebsd.org Subject: Re: 2.1 panic: panic: nfsreq nogrps In-reply-to: Your message of "Tue, 02 Jan 96 21:18:36 PST." <8340.820646316@westhill.cdrom.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 02 Jan 1996 21:38:13 -0800 Sender: owner-hackers@freebsd.org Precedence: bulk >David Greenman wrote in message ID ><199601030518.VAA00184@corbin.Root.COM>: >> >I just got a panic dump on one of our internal servers: > >> >panic: nfsreq nogrps > >> I've already fixed this. It's caused by a setgroups(0,foo) in some program >> running with uid=0. The most noteable of these is Smail, but I'm sure there >> are others. If you update the server to 2.1-STABLE, the problem should go >> away. > >The kernel was compiled on Dec 19th (sorry, should have had that info This is the log info: --- revision 1.11.4.2 date: 1995/11/19 01:52:43; author: davidg; state: Exp; lines: +3 -2 >From rev 1.14: Disallow setgroups() with ngroups=0. There should always be one group (the effective gid). This works around a panic ("nfsreq nogrps") that occurs with NFS clients. This change is too late for 2.1-release. Obtained from: 4.4BSD-Lite2 --- >in the origional mail), and I was just looking at the program which >was running at the time, and it does nothing more complicated than The setgroups() can happen at any time and doesn't in itself cause a panic. The panic message "nfsreq nogrps" indicates that an I/O operation is being attempted on behalf of a process that has no groups in it's group list. This isn't a valid state as group[0] is always the effective gid. If the process didn't get this way because of setgroups(), then it's happening somewhere else in the kernel. I suppose one work-around kludge might be to substitute the "nobody" group (-2) for processes that otherwise belong to no groups. -DG