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" <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
_______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
