kernel killing processes when out of swap

[Steven Hartland]

Thanks for the feedback seems very strange that sshd was the first thing the
kernel killed off; so unless it was actually at fault ( would be very strange )
it would have been one of the smallest not largest processes.
The box has runs several 200M+ process and more 100M+ where
as sshd is usually 6M.

So this leads me to the questions:
1. Any know issues ssh which could make it eat memory?
2. Is there possibly a bug with the "large process detection"?

N.B. It seems more likely that #2 is case as the next processes to be killed
where some small perl monitoring scripts we run only after that did it kill
of one of the large 200M+ processes.

    Regards
    Steve
----- Original Message ----- 
From: "ALeine" <aleine at austrosearch.net>
> 
> This procedure is not random, it indeed looks for the largest process and
> then kills it. It keeps repeating this procedure until the memory starvation
> problem is solved. You obviously are not running X on that machine, otherwise
> you would see that X would get killed before sshd. When you're out of swap,
> you're also out of luck if sshd is among the largest processes on your
> machine. Having a flag to tag processes as vital to prevent them from getting
> killed (or to give them lower next-to-be-killed priority so that all non-vital
> processes get killed first) when you run out of swap would be a useful feature,
> what do you guys think?



================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to postmaster at multiplay.co.uk.