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/

Reply via email to