Mailinglist Archive: opensuse (2912 mails)

< Previous Next >
Re: [SLE] adobe acrobat alternative
  • From: Danny Sauer <suse-linux-e.suselists@xxxxxxxxxxxxxxxxxxxx>
  • Date: Sat, 26 Feb 2005 11:15:20 -0600
  • Message-id: <200502261115.20364.suse-linux-e.suselists@xxxxxxxxxxxxxxxxxxxx>
On Saturday 26 February 2005 10:33 am, Randall R Schulz wrote:
> Danny,
>
> On Saturday 26 February 2005 08:33, Danny Sauer wrote:
> > On Friday 25 February 2005 04:16 pm, Randall R Schulz wrote:
> > [...]
> >
> > > (*) The one weakness I've experienced more than any other on my
> > > SuSE Linux system is its vulnerability to a rogue process consuming
> > > so much memory that everything else gets swapped out and it becomes
> > > impossible to even kill the errant process.
> >
> > Clearly, you need more memory. :) Most modern system will accept
> > 2GB, if not 4 or more. You should have time to kill acroread before
> > it fills up 2GB of physical memory.
>
> I have 1 GB. Brute force cannot be the right way to address this
> problem.

Maybe you have too much memory, then. The only machine I've ever had that
problem with is a machine with 128MB physical and 512MB swap (and a
particularly leaky server daemon, though I've yet to identify precisely
which one - the machine's running SuSE 5.2 and really should just be
updated, so I'm not investing time in fixing problems). :) Well, my 1.5GB
machine hasn't had that problem, either. It must be you. :)

> The upshot is that this is a genuine vulnerability that cannot be solved
> by throwing memory at the system.

Well, if you're gonna make this a serious response, how about by
implementing per-process memory limits?

man bash, search for ulimit - presuming you're using bash. The c shells
have a similar command, named the same, IIRC. Set the memory limits,
process limits, etc. It's up to the shell to enforce, but I'll bet bash
will notice the problem well before the typical user would.

--Danny, who doesn't set limits, largely because of laziness

< Previous Next >
Follow Ups