Long-running processes are not always important. If I'm running an RC5
cracker or similar program, I want that killed right after the fork
bomb. While it's generally bad to interrupt simulations etc., it is
perfectly fine to do so if they are properly designed so they save their
state as they go along. If I were writing a really long simulation, I'd
make sure it was interruptible, and that there were provisions for
automatically restarting it when it died.
Note: On long-running, unsupervised systems, it is sometimes better to
reboot than to do an OOM kill, unless the system is set up to be able to
automatically restart critical programs that die. For instance, if a mail
server gets OOM because of a mem leak in sendmail, it's better to crash and
reboot than to kill sendmail, unless it's auto-restarted.
--
This message has been brought to you by the letter alpha and the number pi.
David Feuer
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
