Come "ibernare" un processo in Linux archiviando la sua memoria su disco e ripristinandolo in seguito?

È possibile "ibernare" un processo in Linux? Proprio come "ibernazione" nel laptop, vorrei scrivere tutta la memoria utilizzata da un processo su disco, liberando la RAM. E poi in seguito, posso 'riprendere il processo', cioè leggere tutti i dati dalla memoria e rimetterli nella RAM e posso continuare con il mio processo?

Ho usato per mantenere CryoPID , che è un programma che fa esattamente quello di cui stai parlando. Scrive il contenuto dello spazio degli indirizzi di un programma, VDSO, i riferimenti ai descrittori di file e gli stati in un file che può essere successivamente ricostruito. CryoPID è iniziato quando non c'erano hook utilizzabili in Linux stesso e ha funzionato interamente dallo spazio utente (in realtà, funziona ancora, a seconda delle impostazioni di distribuzione / kernel / sicurezza).

I problemi erano (in effetti) socket, segnali RT in sospeso, numerosi problemi X11, l'implementazione getpid () della cache glibc tra molti altri. La randomizzazione (specialmente VDSO) si è rivelata insormontabile per i pochi di noi che ci lavoravano dopo che Bernard se ne era andato. Tuttavia, è stato divertente ed è diventato l'argomento di diverse tesi di laurea.

Se stai solo contemplando un programma che possa salvare il suo stato di esecuzione e riavviarlo direttamente in quello stato, è molto ... molto ... più facile salvare le informazioni dall'interno del programma stesso, forse quando si serve un segnale.

Vorrei inserire un aggiornamento di stato qui, a partire dal 2014.

La risposta accettata suggerisce CryoPID come strumento per eseguire Checkpoint / Restore, ma ho trovato il progetto non gestito e impossibile da compilare con i kernel recenti. Ora, ho trovato due progetti gestiti attivamente che forniscono la funzione di checkpoint dell'applicazione.

Il primo, quello che suggerisco perché ho più fortuna a eseguirlo, è CRIU che esegue il checkpoint / ripristino principalmente nello spazio utente e richiede che l'opzione del kernel CONFIG_CHECKPOINT_RESTORE sia abilitata per funzionare.

Checkpoint / Restore In Userspace, o CRIU (pronunciato kree-oo, IPA: / krɪʊ /, Russian: криу), è uno strumento software per il sistema operativo Linux. Utilizzando questo strumento, è possibile bloccare un'applicazione in esecuzione (o parte di essa) e posizionarla su un disco rigido come raccolta di file. È quindi possibile utilizzare i file per ripristinare ed eseguire l'applicazione dal punto in cui è stata bloccata. La caratteristica distintiva del progetto CRIU è che è implementato principalmente nello spazio utente.

Quest'ultimo è DMTCP ; citando dalla loro pagina principale:

DMTCP (Distributed MultiThreaded Checkpointing) è uno strumento per controllare in modo trasparente lo stato di più applicazioni simultanee, comprese le applicazioni multi-thread e distribuite. Funziona direttamente sull'eseguibile binario dell'utente, senza alcun modulo del kernel Linux o altre modifiche al kernel.

C'è anche una bella pagina di Wikipedia sull'argomento: Application_checkpointing

Le risposte menzionate ctrl-zparlano davvero di fermare il processo con un segnale, in questo caso SIGTSTP. Puoi emettere un segnale di stop con kill:

kill -STOP <pid>

Ciò sospenderà l'esecuzione del processo. Non libererà immediatamente la memoria da esso utilizzata, ma poiché la memoria è richiesta per altri processi, la memoria utilizzata dal processo interrotto verrà gradualmente sostituita.

Quando vuoi riattivarlo, usa

kill -CONT <pid>

Le soluzioni più complicate, come CryoPID, sono davvero necessarie solo se si desidera che il processo interrotto sia in grado di sopravvivere a un arresto / riavvio del sistema - non sembra che tu ne abbia bisogno.

Il problema è ripristinare i flussi - file e socket - che il programma ha aperto.

Quando l'intero sistema operativo si iberna, i file locali e simili possono ovviamente essere ripristinati. Le connessioni di rete no, ma il codice che accede a Internet è in genere più controllo degli errori e tale e sopravvive alle condizioni di errore (o dovrebbe farlo).

Se eseguissi l'ibernazione per programma (senza il supporto dell'applicazione), come gestiresti i file aperti? Cosa succede se un altro processo accede a quei file nel frattempo? eccetera?

Mantenere lo stato quando il programma non è caricato sarà difficile.

La semplice sospensione dei thread e lo scambio su disco avrebbe più o meno lo stesso effetto?

Oppure esegui il programma in una macchina virtuale e lascia che la VM gestisca la sospensione.

Il kernel Linux ha ora parzialmente implementato i futuri checkpoint / riavvio: https://ckpt.wiki.kernel.org/ , lo stato è qui .

Alcune informazioni utili si trovano nella lwn (rete settimanale di Linux): http://lwn.net/Articles/375855/ http://lwn.net/Articles/412749/ ......

Quindi la risposta è sì"

La risposta breve è "sì, ma non sempre affidabile". Controlla CryoPID:

http://cryopid.berlios.de/

I file aperti saranno infatti il ​​problema più comune. CryoPID afferma esplicitamente:

I file aperti e gli offset vengono ripristinati. I file temporanei che sono stati scollegati e non sono accessibili sul filesystem vengono sempre salvati nell'immagine. Altri file che non esistono al ripristino non sono ancora stati ripristinati. È previsto il supporto per il salvataggio dei contenuti dei file per tali situazioni.

Gli stessi problemi interesseranno anche le connessioni TCP, sebbene CryoPID supporti tcpcp per la ripresa della connessione.

La risposta breve è "sì". Potresti iniziare guardando questo per alcune idee: ricostruzione eseguibile ELF da un'immagine principale ( http://vx.netlux.org/lib/vsc03.html )

Ho esteso Cryopid producendo un pacchetto chiamato Cryopid2 disponibile da SourceForge. Questo può migrare un processo così come ibernarlo (insieme a tutti i file e socket aperti - i dati nei socket / pipe vengono risucchiati nel processo in ibernazione e rigettati in questi quando il processo viene riavviato).

Il motivo per cui non sono stato attivo con questo progetto è che non sono uno sviluppatore di kernel: sia questo (e / o il cryopid originale) hanno bisogno di qualcuno che possa farli funzionare con i kernel più recenti (ad esempio Linux 3.x) .

Il metodo Cryopid funziona ed è probabilmente la migliore soluzione per l'ibernazione / migrazione dei processi generici in Linux che ho incontrato.

Come altri hanno notato, è difficile per il sistema operativo fornire questa funzionalità, perché l'applicazione deve avere un controllo degli errori integrato per gestire i flussi interrotti.

Tuttavia, in una nota a margine, alcuni linguaggi di programmazione e strumenti che utilizzano macchine virtuali supportano esplicitamente questa funzionalità, come il linguaggio di programmazione Self .

Ctrl-Z aumenta le possibilità che le pagine del processo vengano scambiate, ma non libera completamente le risorse del processo. Il problema con la liberazione completa delle risorse di un processo è che cose come gli handle di file, i socket sono risorse del kernel che il processo può usare, ma non sa come persistere da solo. Quindi Ctrl-Z è il massimo.

Ci sono state alcune ricerche sul checkpoint / ripristino per Linux nei giorni 2.2 e 2.4, ma non sono mai riuscite a superare il prototipo. È possibile (con le avvertenze descritte nelle altre risposte) per alcuni valori di possibile - se puoi scrivere un modulo del kernel per farlo, è possibile. Ma per il valore comune di possibile (posso farlo dalla shell su una distribuzione Linux commerciale), non è ancora possibile.

Questa è una sorta di obiettivo finale del sistema operativo in cluster. Mathew Dillon si impegna molto per implementare qualcosa di simile nel suo progetto Dragonfly BSD .

aggiungendo un'altra soluzione alternativa: puoi usare virtualbox. esegui le tue applicazioni in una normale macchina virtuale e semplicemente "salva lo stato della macchina" quando vuoi. So che questa non è una risposta, ma ho pensato che potesse essere utile quando non ci sono opzioni reali.

se per qualsiasi motivo non ti piace virtualbox, vmware e Qemu sono altrettanto buoni.

C'è ctrl+zin Linux, ma non sono sicuro che offra le funzionalità che hai specificato. Sospetto che tu abbia fatto questa domanda poiché non è così