From owner-freebsd-current Fri Feb 24 02:35:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id CAA12917 for current-outgoing; Fri, 24 Feb 1995 02:35:31 -0800 Received: from vector.eikon.e-technik.tu-muenchen.de (vector.eikon.e-technik.tu-muenchen.de [129.187.142.36]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id CAA12409 for ; Fri, 24 Feb 1995 02:13:31 -0800 Received: (from jhs@localhost) by vector.eikon.e-technik.tu-muenchen.de (8.6.9/8.6.9) id AAA16408; Wed, 22 Feb 1995 00:39:16 +0100 Date: Wed, 22 Feb 1995 00:39:16 +0100 From: Julian Howard Stacey Message-Id: <199502212339.AAA16408@vector.eikon.e-technik.tu-muenchen.de> To: bde@zeta.org.au, davidg@Root.COM, jhs@regent.e-technik.tu-muenchen.de Subject: Re: Possible kern.maxproc fatal bug Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > Bruce Evans Re. > Probably because the proc table is not dynamically sized. Basically, you >can't change maxproc - it probably should not by managed by sysctl. But it is dynamically sized. I can't see any problems that would cause a panic. Old rlimits for RLIMIT_NPROC become bogus when maxproc is changed but this probably won't cause a panic. Well now, I guess I don't make this offer often, or lightly, but it Will crash my machine, & as a normal user, so if someone Really wanted to prove it, I could issue a temporary login late one slip connected night (TZ=GMT+1), & let that person Prove it to their satisfaction :-) Of course I'd rather not ... but if it's necessary to prove the bug ;-) Julian S (fretting & worrying, hoping no one will take him up on his offer ;-)