Есть-ли жизнь после OOM?

1 совсем запретить - нет, но пояснить системе очередность убивания можно через /proc/<pid>/oom_score_adj + Documentation/filesystems/proc.txt

2 имхо - нет

3 init ?

1. Уже ответили - это именно оно. 3. supervisord

vel По поводу инита по подробнее можно?

blind_oracle А где гарантия, что OOM-killer не убьет supervisord ?

OOM не может убить init, значит, нужно настроить свой инит, чтобы он либо перезапускал саму программу, либо тот же supervisord

Судя по документации при oom_score_adj -1000 процесс должен быть исключен из алгоритма поиска жертвы для oom_killer'а.

Думаю на это стоит рассчитывать.

Как еще одна перезапускалка - monit. Там можно даже предупреждать такие ситуации типа если память использована на 90% делать рестарт процессу.

Хм... надо будет посмотреть в эту сторону.

В подтверждение про -1000:

http://lxr.free-electrons.com/source/mm/oom_kill.c#L182

По поводу 2. Я не совсем шарю в теме, но может есть вариант со вспомогательным демоном, который следит за тем что система приближается к активации OOM-killer и пока ещё есть ресурсы рассылает менее жёсткие сигналы, получив которые наиболее критичные и первые кандидаты под горячую руку OOM-killer-а могут проделать свою «предсметрную» обработку?

Кстати идея интересная, только не демоном а тем же OOM, например ввести два параметра а не один, по превышению первого посылаем сигнал на завершение, по второму киляем, т.е. небольшая дельта. Но это так мысли вслух.

OOM killer умеет запускать произвольный скрит то-ли после убийства процесса, то-ли даже вместо него. Этим скриптом можно заново запускать критический софт например.

Ещё помнится были какие-то разговоры про ограничение килера cgroup-ами, что-бы он убивал процессы только в той группе процесс из которой нехватило памяти, но это было из серии то-ли «ав от бы запилить», то-ли «а вот мы запилили, но в апстрим не закоммитили».