From owner-freebsd-security Fri Sep 7 5:42:15 2001 Delivered-To: freebsd-security@freebsd.org Received: from breg.mc.mpls.visi.com (breg.mc.mpls.visi.com [208.42.156.101]) by hub.freebsd.org (Postfix) with ESMTP id D6F6637B403 for ; Fri, 7 Sep 2001 05:42:05 -0700 (PDT) Received: from sheol.localdomain (hawkeyd-fw.dsl.visi.com [208.42.101.193]) by breg.mc.mpls.visi.com (Postfix) with ESMTP id 0BFF62D06CE; Fri, 7 Sep 2001 07:42:05 -0500 (CDT) Received: (from hawkeyd@localhost) by sheol.localdomain (8.11.1/8.11.1) id f87Cg3w22421; Fri, 7 Sep 2001 07:42:03 -0500 (CDT) (envelope-from hawkeyd) Date: Fri, 7 Sep 2001 07:42:03 -0500 From: D J Hawkey Jr To: Giorgos Keramidas Cc: steve@nomad.tor.lets.net, freebsd-security@FreeBSD.ORG Subject: Re: running very low on memory (was: Re:when mail full /tmp partition, system cracked) Message-ID: <20010907074203.A22380@sheol.localdomain> Reply-To: hawkeyd@visi.com References: <20010906170731.A18984@sheol.localdomain> <20010907133548.A3833@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010907133548.A3833@hades.hell.gr>; from charon@labs.gr on Fri, Sep 07, 2001 at 01:35:48PM +0300 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 On Sep 07, at 01:35 PM, Giorgos Keramidas wrote: > > 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. Agreed. But... > If you start running so low on memory (and swap), there's not much > difference in killing one process or the other. ...should it happen, and the choice was between a [larger] named and a [smaller] lpd or ntpd, I'd rather either of the latter be killed (just as an example). Actually, in my mind, rather than this tact at all, I'd opt for simply not spawning the task that brought on this condition to begin with (or is that what happens with properly tuned user limits?). > -giorgos This thread is getting a bit off-topic for this mailing list, no? Let's take it "off line" if we wish to continue. SeeYa, Dave -- Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message