Como lidar com uma bomba bifurcada com vazamento de memória no Linux?

Question

Eu sei que uma bifurcação pode ser evitada limitando o número de processos de um único usuário, e o vazamento de memória não congelará meu SO para o Linux ter o OOM killer. Mas que tal uma bomba de garfo com vazamento de memória?

#include <vector>
#include <unistd.h>
#include <ctime>
#include <cstdlib>

using namespace std;

int main() {
    srand(time(NULL));
    vector<int> vec;
    do {
        try {
            for (int i=0; i<10000000; i++)
                vec.push_back(rand());
        } catch (bad_alloc e) {
        }
        fork();
    } while (1);
    return 0;
}

Meu Linux ficou congelado depois de experimentar este código. Existe alguma maneira que eu possa impedir que ela congele?
O código é testado no Archlinux, Linux 4.0.5

compile o código apenas usando este comando: g++ -o test test.cpp

Mais informações: Como o código pode consumir toda a minha memória apenas bifurcando algumas vezes, não é como uma garfo normal, e limitar o número de processos é inútil. Além disso, fork () é executado com freqüência (quando há pouca memória), de modo que o OOM-killer é muito mais lento do que os garfos. Como resultado, eu tenho que usar o Alt-SysRq-R-E-I para parar esses processos, mas não é isso que eu quero.

Esta é a primeira vez que pergunto no SuperUser. Ajude-me se minha pergunta for inadequada. E obrigado pela sua ajuda.

    

Answer 1

Não precisa ser uma bomba bifurcada com memória perdida - mesmo, por exemplo, um make -j (ou com um j fator muito alto) em um tamanho de código moderado ou qualquer processo gerando uma pilha de descendentes ( menos do que o limite razoável para um usuário ativo), cada um mastigando uma quantidade significativa de memória por si só, mas muito pequena para ser alvo do assassino da OOM (ou oferecer um alívio significativo quando pregado pelo assassino da OOM) pode ter um efeito similar .

É possível escrever um script / ferramenta de monitoração customizada (a ser executada pelo root em alta prioridade) que poderia observar tais padrões de desova do processo e, se necessário, matá-los por pgid ou userid (ie simultaneouly, não um por um como o assassino da OOM) antes de se tornarem fatais para o sistema. Funcionaria para taxas de desova / redução de recursos razoáveis , mas não tenho certeza se possível para apenas quaisquer taxas.