From owner-freebsd-security Fri Sep 7 5:24:24 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 69BA737B407 for ; Fri, 7 Sep 2001 05:24:19 -0700 (PDT) Received: from hades.hell.gr (patr530-a032.otenet.gr [212.205.215.32]) by mailsrv.otenet.gr (8.11.5/8.11.5) with ESMTP id f87CO9A27788; Fri, 7 Sep 2001 15:24:11 +0300 (EEST) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id f87AZmK04397; Fri, 7 Sep 2001 13:35:49 +0300 (EEST) (envelope-from charon@labs.gr) Date: Fri, 7 Sep 2001 13:35:48 +0300 From: Giorgos Keramidas To: D J Hawkey Jr Cc: steve@nomad.tor.lets.net, freebsd-security@FreeBSD.ORG Subject: running very low on memory (was: Re:when mail full /tmp partition, system cracked) Message-ID: <20010907133548.A3833@hades.hell.gr> References: <20010906170731.A18984@sheol.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010906170731.A18984@sheol.localdomain>; from hawkeyd@visi.com on Thu, Sep 06, 2001 at 05:07:31PM -0500 X-PGP-Fingerprint: 3A 75 52 EB F1 58 56 0D - C5 B8 21 B6 1B 5E 4A C2 X-URL: http://students.ceid.upatras.gr/~keramida/index.html Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org From: D J Hawkey Jr Subject: Re: when mail full /tmp partition, system cracked Date: Thu, Sep 06, 2001 at 05:07:31PM -0500 > In article <20010906152832.A44174_nomad.lets.net@ns.sol.net>, > steve@nomad.tor.lets.net writes: > > On Thu, Sep 06, 2001 at 10:45:47AM -0300, Fernando Schapachnik wrote: > > > > What is supposed to happen is the largest process is supposed > > to be killed if virtual memory is exhausted. There is a bug in > > 4.3-RELEASE that prevents this from happening. The kernel hangs > > before any processes get killed. > > Is "the largest process" selective, to some degree or another? That is, > will it (can it?) discern a "more valuable" process from a "lesser one"? Nope, it isn't. The 'largest' means just that. The largest. But you're missing the point. The idea is to *not* reach this state of memory being 'exchausted' by carefully setting up user limits. If you start running so low on memory (and swap), there's not much difference in killing one process or the other. -giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message