From owner-freebsd-hackers  Mon Nov 20 18:39:55 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id SAA12050
          for hackers-outgoing; Mon, 20 Nov 1995 18:39:55 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA12023
          for <hackers@FreeBSD.ORG>; Mon, 20 Nov 1995 18:39:47 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id NAA23764; Tue, 21 Nov 1995 13:34:59 +1100
Date: Tue, 21 Nov 1995 13:34:59 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511210234.NAA23764@godzilla.zeta.org.au>
To: bde@zeta.org.au, taob@io.org
Subject: Re: panic: free vnode isn't
Cc: hackers@FreeBSD.ORG
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

>    So how can increasing this break anything?  If an application
>limits itself to the assumption that a user can own 40 processes at a
>time, having the limit set to 256 shouldn't hurt.  In other words,

The 41th process would fail to fit in a table with space for 40.

>does it matter whether the default CHILD_MAX is 256, or that I type
>"unlimit" first to raise it to 256?

The kernel option CHILD_MAX doesn't change CHILD_MAX.  It changes
MAXUPRC.  To change the default CHILD_MAX, you would have to change
it in <sys/syslimits.h> and recompile all binaries that depend on it,
possibly including BSDI, ibcs2 and Linux ones.

Changing MAXUPRC has the same effect as typing `ulimit -u 256' in
sh before starting _every_ process.

Bruce