Dopo "OOM Killer", c'è un "Resurrector"?

Question

Capisco che su Linux ci sia una funzionalità del kernel chiamata "OOM Killer". Quando la condizione OOM (fuori memoria) si interrompe, esiste un "Resocessore di processo"?

Capisco che questa funzionalità sarebbe difficile da implementare per tutti i tipi di motivi, ma c'è qualcosa che si avvicini ad essa?

Edit: Esempio: il "Resurrector" avrebbe un blocco di memoria garantita per memorizzare un insieme limitato di informazioni processo (es riga di comando, ambiente, ecc) (cioè non un codice processo intero & dati!). Una volta che la condizione di OOM è stata cancellata, il "Resurrector" potrebbe passare attraverso l'elenco e "resuscitare" alcuni processi.

Da quello che ho raccolto fino ad ora, non sembra esserci funzionalità simile a quello che sto chiedendo.

Answer 1

No. Una volta che un processo viene ucciso da OOM Killer, è morto. Puoi riavviarlo (se le risorse lo permettono), e se è qualcosa che è gestito dal sistema (tramite inittab, forse), potrebbe riavviarsi in quel modo.

Modifica: come esperimento mentale, pensa a cosa significherebbe una risurrezione di un processo. Anche se si potesse memorizzare l'intero stato del processo, non si vorrebbe farlo perché il processo potrebbe essere interrotto dalla REASON per la condizione di esaurimento della memoria.

Quindi il meglio che si potrebbe avere sarebbe di memorizzare il suo stato di avvio (riga di comando, ecc.). Ma non va bene, perché ancora una volta, questo potrebbe essere il motivo per cui il sistema ha esaurito la memoria in primo luogo!

Inoltre, se si resuscita un processo in questo modo, non si sa cosa potrebbe andare storto. Cosa succede se il processo controlla l'hardware? Cosa succede se i controlli di processo non devono essere eseguiti più di una volta? E se fosse collegato a una tty che non c'è più (perché lo sshd era uno dei processi uccisi)?

C'è una quantità ENORME di contesto attorno a un processo di cui il sistema non può essere a conoscenza. L'unica cosa sensata è la cosa che fa il kernel: uccidere il sucker e andare avanti.

Suppongo che tu possa immaginare una strategia di sospensione da disco a disco, ma dato che abbiamo esaurito la memoria (incluso lo swap), ciò significa o prenotare un po 'di spazio su disco o decidere di allocare spazio su disco a questo al volo. Ognuna delle quali strategia potrebbe non essere in grado di gestire la dimensione del processo in questione.

In breve: No, non puoi tornare dal killer di OOM. È un assassino, devi solo occupartene.

Answer 2

Ovviamente non c'è. Altrimenti, dove può essere memorizzato un processo ucciso se non c'è più memoria per memorizzarlo? :-)

Il fatto è che OOM killer entra in gioco solo quando all la memoria disponibile è esaurita, sia la RAM che la memoria di scambio su disco. Se un "resurrector di processo" potrebbe "resuscitare" un processo dopo che la condizione si è calmata, avrebbe dovuto essere in grado di immagazzinarlo da qualche parte nel momento in cui "l'assassino" ha inizio. Ma poiché il killer inizia solo quando c'è la memoria non disponibile nella memoria, è impossibile.

Ovviamente si può dire "salva su disco", ma bene, la memoria di scambio è un disco.Se si desidera limitare il consumo di memoria del processo, utilizzare la funzionalità ulimit e tracciare manualmente l'utilizzo di mem tramite il programma ps o il file system /proc. "OOM killer" è una misura di panico e non dovrebbe essere molto piacevole ai processi.

Esempio di ciò che si può fare con ulimit (e, forse, senza, ma non può sperimentare con OOM uccisione sul mio sistema ATM)

#!/bin/bash 
save_something=$ENV_VARIABLE 
(ulimit -Sv 1000000; 
    perl -e 'print "Taking all RAM!!!\n"; while (1) { $a[$i++] = $i; }' 
) 
echo "killed, resetting" 
(ulimit -Sv 1000000; 
    export ENV_VARIABLE="$save_something" 
    perl -e 'print "Taking all RAM!!!\n"; while (1) { $a[$i++] = $i; }' 
)