Messages in this thread |  | | Date | Fri, 13 Oct 2000 03:19:44 -0400 | From | David Feuer <> | Subject | Re: [RFC] New ideas for the OOM handler |
| |
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 David_Feuer@brown.edu
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |