After "OOM Killer", is there a "Resurrector"?

I understand that on Linux there is a kernel functionality referred to as "OOM Killer". When the OOM (Out-Of-Memory) condition subsides, is there such a thing as a "Process Resurrector" ?

I understand this functionality would be difficult to implement for all sorts of reason, but is there something that gets close to it?

Edit: Example: the "Resurrector"开发者_如何学编程 would have a block of memory guaranteed to it for storing a limited set of process information (e.g. command-line, environment etc.) (i.e. not a whole process code & data !). Once the OOM condition is cleared, the "Resurrector" could go through the list and "resurrect" some processes.

From what I gather up to now, there doesn't seem to be functionality akin to what I am asking.

---

No. Once a process is killed by the OOM Killer, it's dead. You can restart it (resources permitting), and if it's something that's managed by the system (via inittab, perhaps), it might get restarted that way.

Edit: As a thought experiment, think about what a resurrection of a process would mean. Even if you could store the entire process state, you wouldn't want to because the process killed might be the REASON for the out-of-memory condition.

So the best you could possibly due would be to store it's startup state (command line, etc). But that's no good either, because again, that may be WHY the system ran out of memory in the first place!

Furthermore, if you resurrected a process in this way, there's no telling what could go wrong. What if the process controls hardware? What if the process controls shouldn't be run more than once? What if it was connected to a tty that isn't there anymore (because the sshd was one of the processes killed)?

There's an ENORMOUS amount of context around a process that the system can't possibly be aware of. The ONLY sensible thing is the thing that the kernel does: kill the sucker and go on.

I suppose you can imagine a hibernate-the-process-to-disk strategy, but given that we're out of memory (including swap), that means either pre-reserving some disk space or deciding to allocate disk space to this on the fly. Either of which strategy may not be capable of dealing with the size of the process in question.

In short: No, you don't get to come back from the OOM killer. It's a killer, you just have to deal with it.

---

Of course there is no. Otherwise, where can a killed process be stored if there's no more memory to store it? :-)

The thing is that OOM killer only comes into play when all available memory is exhausted, both RAM and on-disk swap memory. If a "process resurrector" could "resurrect" a process after the condition subsides, it should have been capable to store it somewhere at the time when "the killer" starts. But since killer only starts when there's no memory available, that is impossible.

Of course you may say "save to disk", but well, swap memory is a disk. If you want to limit memory consumption of your process, use ulimit functionality and track your mem usage manually via ps program or /proc filesystem. "OOM killer" is a panic measure and should not be very nice to processes.

Example of what you can do with ulimit (and, perhaps, without, but I can't experiment with OOM killing on my system atm)

#!/bin/bash
save_something=$ENV_VARIABLE
( ulimit -Sv 1000000; 
   perl -e 'print "Taking all RAM!!!\n"; while (1) { $a[$i++] = $i; }'
)
echo "killed, resetting"
( ulimit -Sv 1000000;
   export ENV_VARIABLE="$save_something"
   perl -e 'print "Taking all RAM!!!\n"; while (1) { $a[$i++] = $i; }'
)