From owner-freebsd-hackers Wed Sep 22 11:41:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 516851527A for ; Wed, 22 Sep 1999 11:41:19 -0700 (PDT) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id LAA21534; Wed, 22 Sep 1999 11:57:44 -0700 (PDT) Date: Wed, 22 Sep 1999 11:57:44 -0700 (PDT) From: Alfred Perlstein To: Matthew Dillon Cc: Nate Williams , Chuck Robey , "Daniel C. Sobral" , Ivan , freebsd-hackers@FreeBSD.ORG Subject: Re: Out of swap handling and X lockups in 3.2R In-Reply-To: <199909221738.KAA16257@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 22 Sep 1999, Matthew Dillon wrote: > How about this - add an 'importance' resource. The lower the number, > the more likely the process will be killed if the system runs out of > resources. We would also make fork automatically decrement the number > by one in the child. > > The default would be 1000. The sysadmin could then use login.conf to > lower the hard limit for particular users or user classes, and of course > set a specific limit for particular root-run processes (though, in general, > the daemons will be protected because their children will be more likely > to be killed then they will). > > The system would use the importance resource to modify its search for > processes to kill - perhaps use it as a divisor. Or the system could use > it absolutely then kill the biggest process of the N processes sitting > at the lowest importance level. > > This also solves the sysad-cant-login problem and the user-is-naughty > problem. I knew it would be Matt to come up with something like this, it sounds great. Maybe a limit to how many kills a process can score, meaning that if one process seems to be killing a lot of programs the system may come down and kill it? This along with sleeping would allow someone to log in, (with a high importance) and probably su and still be able to manage to save the box. maybe? :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message