From owner-freebsd-hackers  Sun Feb  5 10:02:15 1995
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA28077 for hackers-outgoing; Sun, 5 Feb 1995 10:02:15 -0800
Received: from p5.spnet.com (elh.com [204.156.130.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA28071 for <freebsd-hackers@FreeBSD.org>; Sun, 5 Feb 1995 10:02:10 -0800
Received: from localhost (localhost [127.0.0.1]) by p5.spnet.com (8.6.9/8.6.6) with SMTP id KAA01142; Sun, 5 Feb 1995 10:01:14 GMT
Message-Id: <199502051001.KAA01142@p5.spnet.com>
X-Authentication-Warning: p5.spnet.com: Host localhost didn't use HELO protocol
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-hackers@FreeBSD.org
Subject: Re: kernel limits 
In-reply-to: Your message of "Sun, 05 Feb 1995 18:56:38 +1100."
             <199502050756.SAA12171@godzilla.zeta.org.au> 
Date: Sun, 05 Feb 1995 10:01:13 +0000
From: Ed Hudson <elh@p5.spnet.com>
Sender: hackers-owner@FreeBSD.org
Precedence: bulk


>
> CHILD_MAX is bogus.  It is only used to report a bogus limit to applications
> in <limits.h> and to initialize MAXUPRC.  MAXUPRC is only the _initial_
> value for the _current_ (soft) process limit.  The actual limit is the
> _hard_ process limit, which is initially `maxproc' but can be reduced by
> applications.  `maxproc' itself can be changed using
> `sysctl -w kern.maxproc=whatever'.  Applications that need a larger limit
> should use setrlimit() to increase their soft limit.  Systems that need
> a larger limit should use sysctl in /etc/rc.local to increase `maxproc'.

	wow, i like the sysctl command - a great 4.4 addition.
	thanks for pointing it out to me (rubbing my nose in it?).

	i guess i've worked on too many os's where the hard limit
	was close to or the same as the soft limit.  i hadn't realized
	the FBSD was so rational that i could actually handle this
	in a .cshrc (but a .profile?).

	however, let me ask again as to why the value of 40 for
	CHILD_MAX/MAXUPRC, as an initial setting of a user's maxproc,
	is still relevent in a modern workstation?

	i think that the login process of a user that spawns a
	multi-desktop window manager is sufficient to suggest a big
	increase in this value.  each xterm/rxvt is really a count of
	(at least) 2 processes, plus whatever a user might be running
	in an xterm underneath the shell...


>>	1)	bump /usr/src/sys/sys/param.h:MAXSYMLNK	from 8 to
>>		something reasonable, such as 32.
>
> This limit should probably be changeable using sysctl.

	it would be great if this were indeed changeable via sysctl.
	and would certainly satisfy my needs.  but this is overkill
	for a number that is otherwise rarely relevent.

	it looks to me like this is only used as a constant in
	an iteration count check.  i don't quite feel competent
	enough with the kernel sources yet to volunteer to implement
	this change.



	thanks for your comments.

		-elh