Re: running very low on memory (was: Re:when mail full /tmp partition, system cracked)

From: D J Hawkey Jr (hawkeyd@visi.com)
Date: 09/07/01 

Date: Fri, 7 Sep 2001 07:42:03 -0500
From: D J Hawkey Jr <hawkeyd@visi.com>
To: Giorgos Keramidas <charon@labs.gr>

On Sep 07, at 01:35 PM, Giorgos Keramidas wrote:
>
> From: D J Hawkey Jr <hawkeyd@visi.com>
> 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

Relevant Pages

  • Re: DOS attack ?
    ... the receiver ring. ... You want to increase the "NMBCLUSTERS" kernel config variable. ... no memory for rx list -- packet dropped! ... | with "unsubscribe freebsd-security" in the body of the message ...
    (FreeBSD-Security)
  • Re: Qmail + FreeBSD 4.3
    ... Swap memory and see. ... Sig 11 more often than not is a hardware problem. ... Subject: Qmail + FreeBSD 4.3 ... with "unsubscribe freebsd-security" in the body of the message ...
    (FreeBSD-Security)
  • RE: listrl0: no memory for tx
    ... This means that your network memory buffer is not enough to your network ... with "unsubscribe freebsd-security" in the body of the message ...
    (FreeBSD-Security)
  • Re: 4.3-BETA, sshd.core found in root directory.
    ... Alex Popa wrote: ... >including bad memory on my machine), but here are the facts: ... with "unsubscribe freebsd-security" in the body of the message ...
    (FreeBSD-Security)