And if one of your daemons has a slow memory leak then this happens:
You go OOM after a while (hours, days) - a user program is killed.
Buth the leaky dameon is running, so after a shorter time you go OOM
again.
Another user program is killed. This goes on for a while, it becomes
hard
to log in to fix things because the freshly logged in administrator
has a very new process and is the first to go!
After a while, all user programs are gone and daemons die one by one
until the offending one goes. Or perhaps the offending damon
don't leak anymore - it might be sshd but there is not enough memory
to log in so it don't get to leak any more.
>
> Alternatively, suppose we get a very large pid-space, and at the end of
> booting there's something like
>
> echo "5000" > /proc/sys/minimum-pid-from-here-on
>
> Then, you could do:
>
> echo "5000" > proc/sys/oom_lowest_pid_to_try_killing_first
Again, a bad daemon (pid < 5000) will slowly take out everything else,
with login impossible in the meantime.
> in other words, protect a part of pid-space against oom-killing.
Any way you protect a bunch of processes might fail if the bad one
is among them. Also, the OOM killer will have to fall back
to the standard heuristic whenever there is only protected
processes left.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/