I agree with the BSD folks that there is no way to fairly decide which process should be killed. However I'd _much_ rather have a system come back missing a process than a halted box. The question though is how to diagnose the cause of the memory issue. If OOM doesn't give any information about process state before it starts killing then it's hard to track down the root cause. On Tue, 2005-11-29 at 15:53 +1100, Steffen Kluge wrote: > On Mon, 2005-11-28 at 21:09 +0800, John Summerfied wrote: > > I'm not sure it's useful to know that:-( In my experience (which > > includes 2.6 kernels that are supposed to do this better) the killed > > process is generally an innocent bystander. > > The process that triggered the OOM condition is probably just as > innocent. There isn't always a "cuplrit", and if there is it isn't easy > to spot. The OOM killer tries to do the most sensible thing by killing > less active processes that still yield a fair amount of released memory. > > BTW, the OpenBSD folks reckon there is no reasonable or fair way of > dealing with an OOM situation and take the easy way out: they simply > halt the whole system...
