Re: [2.4.18] Security: Process-Killer if machine get's out of memory

[Andreas Hartmann <andihartmann@freenet.de>]

Alan Cox wrote:
>>Advantage of combining consumption-speed and memory usage per process 
>>would be, that processes could be filtered, which are obviously broken. 
>>If the behaviour of the process is correct, than the machine hasn't 
>>enough memory. But this is a problem, which cannot be handled by the kernel.
> 
> 
> With 2.4.19pre3-ac3+ you don't need a heuristic. Do
> 
> 	echo "2" >/proc/sys/vm/overcommit_memory
> 
> The system will then fail allocations before they can cause an OOM status.
> It might be interesting to add "except root" modes to this.
> 
> Alan

If I would ad the option "except root", I would have the same problem, 
because rsync must run as root to do a full backup :-(.

If I understand this feature right, always this process gets a problem, 
which want's to have memory even if there is no more free. It could be 
the wrong process too.
But if a process gets wild like rsync in this situation, it's very 
likely that rsync is the first which doesn't get no more memory. But 
what's afterwards if it didn't get any more memory?
If the process, which wants to have so much memory, isn't stopped (or 
doesn't stop itself), the memory situation isn't getting better. Other 
processes, which are working right, will probably fail while the broken 
process eats up the new free mem again.

I think that a broken process like rsync should be killed in order to 
prevent other processes to be damaged indirectly.

Regards,
Andreas Hartmann